RFC942 日本語訳
0942 Transport protocols for Department of Defense data networks.National Research Council. February 1985. (Format: TXT=217284 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group National Research Council
Request for Comments: 942
February 1985
コメントを求めるワーキンググループ調査評議会の要求をネットワークでつないでください: 942 1985年2月
TRANSPORT PROTOCOLS FOR
DEPARTMENT OF DEFENSE
DATA NETWORKS
国防総省データ網のためのトランスポート・プロトコル
STATUS OF THIS MEMO
このメモの状態
This RFC is distributed for information only. This RFC does not establish any policy for the DARPA research community or the DDN operational community. Distribution of this memo is unlimited.
このRFCは情報だけのために分配されます。 このRFCはDARPA研究団体かDDNの操作上の共同体にどんな方針も確立しません。 このメモの分配は無制限です。
This RFC reproduces the National Research Council report resulting from a study of the DOD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4).
このRFCはISOインターネットプロトコル(ISO-IP)とTransportプロトコルレベル4(TP-4)との比較における、DODインターネットプロトコル(IP)と通信制御プロトコル(TCP)の研究から生じる調査評議会のレポートを複製します。
Transport Protocols for
Department of Defense
Data Networks
国防総省データ網のためのトランスポート・プロトコル
Report to the Department of Defense
and the National Bureau of Standards
国防総省と規格基準局に報告してください。
Committee on Computer-Computer Communication Protocols
コンピュータコンピュータ通信プロトコルの委員会
Board on Telecommunications and Computer Applications Commission on
Engineering and Technical Systems
National Research Council
工学のテレコミュニケーションとコンピュータアプリケーション委員会と技術システム調査評議会で入ってください。
National Academy Press
Washington, D.C. February 1985
国家のアカデミープレスワシントンDC1985年2月
National Research Council [Page i] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページi]RFC942 1985年2月のReport Transport
NOTICE
通知
The project that is the subject of this report was approved by the Governing Board on the National Research Council, whose members are drawn from the councils of the National Academy of Sciences, the National Academy of Engineering, and the Institute of Medicine. The members of the committee responsible for the report were chosen for their special competences and with regard for appropriate balance.
このレポートの対象であるプロジェクトは調査評議会のメンバーが米国科学アカデミーの協議会、EngineeringのNational Academy、およびMedicineのInstituteから得られるGoverning Boardによって承認されました。 レポートに責任がある委員会のメンバーは彼らの特別な力量と適切なバランスへの尊敬で選ばれました。
This report has been reviewed by a group other than the authors, according to procedures approved by a Report Review Committee consisting of members of the National Academy of Sciences, the National Academy of Engineering, and the Institute of Medicine.
このレポートは作者以外のグループによって再検討されました、米国科学アカデミー、EngineeringのNational Academy、およびMedicineのInstituteのメンバーから成るReport Review Committeeによって承認された手順によると。
The National Research Council was established by the National Academy of Sciences in 1916 to associate the broad community of science and technology with the Academy's purposes of furthering knowledge and of advising the federal government. The Council operates in accordance with general policies determined by the Academy under the authority of its congressional charter of 1863, which establishes the Academy as a private, nonprofit, self-governing membership corporation. The Council has become the principal operating agency of both the National Academy of Sciences and the National Academy of Engineering in the conduct of their services to the government, the public, and the scientific and engineering communities. It is administered jointly by both Academies and the Institute of Medicine. The National Academy of Engineering and the Institute of Medicine were established in 1964 and 1970, respectively, under the charter of the National Academy of Sciences.
調査評議会は、1916年にAcademyの知識を促進して、連邦政府にアドバイスする目的に科学技術の広い共同体を関連づけるために米国科学アカデミーによって設立されました。 個人的で、非営利的で、自治の会員制法人とAcademyを書き立てる1863年の議会特許の権威の下におけるAcademyで決定している全般的執行方針によると、Councilは作動します。 Councilは政府、公衆、および科学的で設計している共同体に対する彼らのサービスの行為で米国科学アカデミーとEngineeringのNational Academyの両方の主要な予算運営機関になりました。 それはAcademiesとMedicineのInstituteの両方によって共同で管理されます。 EngineeringのNational AcademyとMedicineのInstituteは1964年と1970年に米国科学アカデミーの特許の下でそれぞれ設立されました。
This is a report of work supported by Contract No. DCA-83-C-0051 between the U.S. Defense Communications Agency and the National Academy of Sciences, underwritten jointly by the Department of Defense and the National Bureau of Standards.
これはContract No.で後押しされている仕事のレポートです。 国防総省と規格基準局によって共同で署名された米国Defense Communications Agencyと米国科学アカデミーの間のDCA83C0051。
Copies of this publication are available from:
この公表のコピーは以下から利用可能です。
Board on Telecommunications and Computer Applications Commission on Engineering and Technical Systems National Research Council 2101 Constitution Avenue, N.W. Washington, D.C. 20418
テレコミュニケーションと工学と技術システムの上で国家のコンピュータアプリケーション委員会でResearch Council2101Constitutionアベニュー、北西ワシントンDC20418に入ってください。
National Research Council [Page ii] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページii]RFC942 1985年2月のReport Transport
BOARD ON TELECOMMUNICATIONS -- COMPUTER APPLICATIONS
COMMITTEE ON COMPUTER-COMPUTER COMMUNICATION PROTOCOLS
テレコミュニケーションでの板--コンピュータコンピュータ通信プロトコルのコンピュータアプリケーション委員会
Chairman
議長
C. CHAPIN CUTLER, Professor of Applied Physics, Stanford University, Stanford, California
C.チェーピン刃物屋、応用物理学の教授、スタンフォード大学、スタンフォード、カリフォルニア
Members
メンバー
HERBERT D. BENINGTON, Technical Director, System Development Corporation, McLean, Virginia
ハーバートD.BENINGTON、技術部長システム開発社、マクリーン、ヴァージニア
DONALD L. BOYD, Director, Honeywell Corporate Computer Sciences Center, Honeywell Corporate Technology Center, Bloomington, Minnesota
ドナルド・L.ボイド、ハネウェルの法人のコンピューターサイエンシズセンター、ハネウェルの法人の技術センター、ブルーミントン、ミネソタの指導官
DAVID J. FARBER, Professor of Electrical Engineering and Professor of Computer Science, Department of Electrical Engineering, University of Delaware, Newark, Delaware
デヴィッド・J.ファーバー、電気工学、デラウエア大学、ニューアーク、デラウェアの部の電気工学の教授とコンピュータサイエンスの教授
LAWRENCE H. LANDWEBER, Professor, Computer Sciences Department, University of Wisconsin, Madison, Wisconsin
ローレンスH.LANDWEBER、教授、コンピューターサイエンシズ部、ウィスコンシン大学、マディソン、ウィスコンシン
ANTHONY G. LAUCK, Manager, Distributed Systems Architecture and Advanced Development, Digital Equipment Corporation, Tewksbury, Massachusetts
アンソニーG.LAUCKとマネージャと分散システム構造と高度な開発、ディジタルイクイップメント社、テュークスベリー、マサチューセッツ
KEITH A. LUCKE, General Manager of Control Data Technical Standards, Control Data Corporation, Minneapolis, Minnesota
キース・A.リュッケ、制御データ規格のコントロール・データ社、ミネアポリス、ミネソタの総支配人
MISCHA SCHWARTZ, Professor of Electrical Engineering and Computer Science, Columbia University, New York, New York
MISCHAのシュワルツと電気工学の教授とコンピュータサイエンス、コロンビア大学、ニューヨーク、ニューヨーク
ROBERT F. STEEN, Director of Architecture, Communication Products Division IBM Corporation, Research Triangle Park, North Carolina
ロバート・F.ステーン、構造のコミュニケーション製品事業部IBM社の指導官は三角形公園、ノースカロライナについて研究します。
CARL A. SUNSHINE, Principal Engineer, Sytek, Incorporated, Los Angeles Operation, Culver City, California
日光(主要な技術者、Sytek)が取り入れたカールA.、ロサンゼルスの操作、カルバーシティー、カリフォルニア
DANIEL J. FINK, (Ex-officio), President, D.J. Fink Associates, Inc., Arlington, Virginia
ダニエルJ.密告者、(元のofficio)、社長、D.J.密告者はInc.、アーリントン、ヴァージニアを関連づけます。
JAMES L. FLANAGAN, (CETS LIAISON MEMBER), Head, Acoustics Research Department, AT&T Bell Laboratories, Murray Hill, New Jersey
フラナガン、(CETS連絡担当会員)が上に立つジェームスL.、音響学調査研究部、AT&Tベル研究所、マリー・ヒル、ニュージャージー
Staff
スタッフ
RICHARD B. MARSTEN, Executive Director JEROME D. ROSENBERG, Senior Staff Officer and Study Director LOIS A. LEAK, Administrative Secretary
MARSTEN、事務局長のジェローム・D.ローゼンバーグ、上級技術スペシャリスト、および試験責任者のロイスA.が漏らすリチャードB.、管理長官
National Research Council [Page iii] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページiii]RFC942 1985年2月のReport Transport
National Research Council [Page iv] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページiv]RFC942 1985年2月のReport Transport
COMMISSION ON ENGINEERING AND TECHNICAL SYSTEMS
BOARD ON TELECOMMUNICATIONS -- COMPUTER APPLICATIONS
工学のコミッションとテレコミュニケーションでの技術システム板--コンピュータアプリケーション
Chairman
議長
DANIEL J. FINK, President, D.J. Fink Associates, Inc., Arlington, Virginia
ダニエルJ.密告者、社長、D.J.密告者はInc.、アーリントン、ヴァージニアを関連づけます。
Past Chairman
元の議長
BROCKWAY MCMILLAN, Vice President (Retired), Bell Laboratories, Sedgwick, Maine
ブロックウェーMCMILLAN、副社長(退職した)、ベル研究所、セジウィック、メイン
Members
メンバー
ARTHUR G. ANDERSON, Vice President (Retired), IBM Corporation, San Jose, California
アーサー・G.アンダーソン、副社長(退職した)、IBM社、サンノゼ、カリフォルニア
DANIEL BELL, Henry Ford II Professor of Social Sciences, Department of Sociology, Harvard University, Cambridge, Massachusetts
ダニエル・ベル、社会的な科学の社会学、ハーバード大学、ケンブリッジ、マサチューセッツの部のヘンリー・フォードII教授
HERBERT D. BENINGTON, Technical Director, System Development Corporation, McLean, Virginia
ハーバートD.BENINGTON、技術部長システム開発社、マクリーン、ヴァージニア
ELWYN R. BERLEKAMP, Professor of Mathematics, Department of Mathematics, University of California, Berkeley, California
ELWYN R.BERLEKAMP、数学の教授、数学、カリフォルニア大学バークレイ校カリフォルニアの部
ANTHONY J. DEMARIA, Assistant Director of Research for Electronics and Electro-Optics Technology, United Technologies Research Center, East Hartford, Connecticut
アンソニーJ.DEMARIAとエレクトロニクスのための研究の助監督と電気光学技術、ユナイテッド・テクノロジーズリサーチセンター、イーストハートフォード、コネチカット
GERALD P. DINNEEN, Vice President, Science and Technology, Honeywell Incorporated, Minneapolis, Minnesota
DINNEENと副社長と科学と技術、ハネウェルが取り入れたジェラードP.、ミネアポリス、ミネソタ
GEORGE GERBNER, Professor and Dean, The Annenberg School of Communications, University of Pennsylvania, Philadelphia, Pennsylvania
ジョージGERBNERと教授とディーン、コミュニケーション、ペンシルバニア大学、フィラデルフィア、ペンシルバニアのアネンバーグ学校
ANNE P. JONES, Partner, Sutherland, Asbill and Brennan, Washington, D.C.
アン・P.ジョーンズ、パートナー(サザーランド、Asbill、およびブレナン)ワシントンDC
ADRIAN M. MCDONOUGH, Professor of Management and Decision Sciences (Retired), The Wharton School, University of Pennsylvania, Havertown, Pennsylvania
エードリアン・M.マクドナフと管理の教授と決定科学(退職した)、ウォートン学校、ペンシルバニア大学、Havertown、ペンシルバニア
WILBUR L. PRITCHARD, President, Satellite Systems Engineering, Inc., Bethesda, Maryland
ウィルバー・L.プリチャード、社長、衛星システム工学Inc.、ベセスダ、メリーランド
MICHAEL B. PURSLEY, Professor of Electrical Engineering, University of Illinois, Urbana, Illinois
マイケルB.PURSLEY、電気工学のイリノイ、アーバナ(イリノイ)の大学の教授
IVAN SELIN, Chairman of the Board, American Management Systems, Inc., Arlington, Virginia
イワンSELIN、評議委員会委員長、アメリカの管理システムInc.、アーリントン、ヴァージニア
National Research Council [Page v] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページv]RFC942 1985年2月のReport Transport
MISCHA SCHWARTZ, Professor of Electrical Engineering and Computer Science, Columbia University, New York, New York
MISCHAのシュワルツと電気工学の教授とコンピュータサイエンス、コロンビア大学、ニューヨーク、ニューヨーク
ERIC E. SUMNER, Vice President, Operations System and Network Planning, AT&T Bell Laboratories, Holmdel, New Jersey
エリック・E.サムナーと副社長と操作システムとネットワーク計画、AT&Tベル研究所、Holmdel、ニュージャージー
KEITH W. UNCAPHER, Executive Director, USC-Information Sciences Institute Associate Dean, School of Engineering, University of Southern California, Marina del Rey, California
KEITH W. UNCAPHER、事務局長のUSC-情報Sciences Institute Associateディーン、工学部、南カリフォルニア大学、マリナデルレイ、カリフォルニア
JAMES L. FLANAGAN, (CETS LIAISON MEMBER), Head, Acoustics Research Department, AT&T Bell Laboratories, Murray Hill, New Jersey
フラナガン、(CETS連絡担当会員)が上に立つジェームスL.、音響学調査研究部、AT&Tベル研究所、マリー・ヒル、ニュージャージー
Staff
スタッフ
Richard B. Marsten, Executive Director Jerome D. Rosenberg, Senior Staff Officer Karen Laughlin, Administrative Coordinator Carmen A. Ruby, Administrative Assistant Lois A. Leak, Administrative Secretary
リチャードB.Marsten、事務局長のジェローム・D.ローゼンバーグ、上級技術スペシャリストカレン・ラフリン、管理コーディネータのカルメンA.のルビー色の、そして、管理のアシスタントのロイスA.は漏れます、管理長官
National Research Council [Page vi] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページvi]RFC942 1985年2月のReport Transport
CONTENTS
コンテンツ
PREFACE ............................................................ ix
PREFACE… ix
EXECUTIVE SUMMARY .................................................. xi
EXECUTIVE SUMMARY… ξ
I Introduction .................................................. 1
I序論… 1
II Review of NBS and DOD Objectives .............................. 3
NBSとDOD目的のIIレビュー… 3
III Comparison of DOD and ISO Protocols .......................... 13
DODとISOプロトコルのIII比較… 13
IV Status of DOD and ISO Protocol
Implementations and Specifications .......................... 25
DOD、ISOプロトコル実現、および仕様のIV状態… 25
V Markets ...................................................... 31
Vは売り出されます… 31
VI Development of Standard Commercial versus
Special Commercial Products .................................. 39
一般的なコマーシャルの対特別な商品VI開発… 39
VII Responsiveness of International Standards
Process to Change ............................................ 43
変える世界規格の過程のVIIの反応性… 43
VIII Options for DOD and NBS ...................................... 45
DODとNBSのためのVIIIオプション… 45
IX Cost Comparison of Options .................................. 47
IXはオプションの比較かかりました… 47
X Evaluation of Options ........................................ 53
オプションのX評価… 53
XI Recommendations .............................................. 61
ξ推薦… 61
National Research Council [Page vii] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページvii]RFC942 1985年2月のReport Transport
National Research Council [Page viii] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページviii]RFC942 1985年2月のReport Transport
PREFACE
序文
This is the final report of the National Research Council Committee on Computer-Computer Communication Protocols. The committee was established in May l983 at the request of the Department of Defense (DOD) and the National Bureau of Standards (NBS), Department of Commerce, to develop recommendations and guidelines for resolving differences between the two agencies on a data communications transport protocol standard.
これはコンピュータコンピュータCommunicationプロトコルの調査評議会Committeeに関する最終報告書です。 委員会は、国防総省(DOD)、および規格基準局(NBS)、商務省の依頼でデータ通信トランスポート・プロトコル規格の2つの政府機関の違いを決議するための推薦とガイドラインを開発するために5月のl983に設立されました。
Computer-based information and transaction-processing systems are basic tools in modern industry and government. Over the past several years there has been a growing demand to transfer and exchange digitized data in these systems quickly and accurately. This demand for data transfer and exchange has been both among the terminals and computers within an organization and among those in different organizations.
コンピュータベースの情報とトランザクション処理システムは近代産業と政府で基本的なツールです。 過去数年間、移すという高まる需要があります、そして、交換はすぐに、正確にこれらのシステムのデータをデジタル化しました。 組織の中の端末とコンピュータの中と、そして、異なった組織におけるそれらの中にデータ転送と交換のこの要求はありました。
Rapid electronic transport of digitized data requires electronic communication links that tie the elements together. These links are established, organized, and maintained by means of a layered series of procedures performing the many functions inherent in the communications process. The successful movement of digitized data depends upon the participants using identical or compatible procedures, or protocols.
デジタル化しているデータの急速な電子輸送は要素を結びつける電子通信リンクを必要とします。 これらのリンクは、コミュニケーションの過程に固有の多くの機能を実行する層にされたシリーズの手順によって設立されて、組織化されて、維持されます。 デジタル化しているデータのうまくいっている運動は、同じであるかコンパチブル手順、またはプロトコルを用いることで関係者に頼っています。
The DOD and NBS have each developed and promulgated a transport protocol as standard. The two protocols, however, are dissimilar and incompatible. The committee was called to resolve the differences between these protocols.
DODとNBSはそれぞれ標準の同じくらいトランスポート・プロトコルを開発して、公表しました。 しかしながら、2つのプロトコルが、異なって両立しないです。 委員会は、これらのプロトコルの違いを決議するために召集されました。
The committee held its first meeting in August l983 at the National Research Council in Washington, D.C. Following this two-day meeting the committee held five more two-day meetings, a three-day meeting, and a one-week workshop.
委員会は委員会と会合すると5回の2日間以上の会合と、3日間の会合と、1週間のワークショップが開かれたこの2日にワシントンDC Followingで調査評議会で8月のl983で最初の会合を開きました。
The committee was briefed by personnel from both agencies. In addition, the committee heard from Jon Postel, University of Southern California's Information Sciences Institute; Dave Oran, Digital Equipment Corporation; Vinton Cerf, MCI; David Wood, The Mitre Corporation; Clair Miller, Honeywell, and Robert Follett, IBM, representing the Computer and Business Equipment Manufacturer's Association; and John Newman, Ultimate Corporation. In most cases the briefings were followed by discussion.
委員会は人員によって両方の政府機関から事情を知らせられました。 さらに、委員会はジョン・ポステル、南カリフォルニア大学情報Sciences Instituteから連絡をいただきました。 デーヴ・オラン、ディジタルイクイップメント社。 ビントン・サーフ、MCI。 デヴィッドWood、斜め継ぎ社。 コンピュータとBusiness Equipment ManufacturerのAssociationを表すクレアミラー、ハネウェルとロバート・フォレット、IBM。 ジョン・ニューマン、究極の社。 多くの場合、議論は状況説明のあとに続きました。
The committee wishes to thank Philip Selvaggi of the Department of Defense and Robert Blanc of the NBS, Institute of Computer Sciences and
そして委員会は国防総省のフィリップSelvaggiとNBSのロバート・ブランに感謝したがっています、コンピューターサイエンシズのInstitute。
National Research Council [Page ix] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページix]RFC942 1985年2月のReport Transport
Technology, for their cooperation as their agency's liaison representatives to the committee. The committee appreciates the contributions and support of Richard B. Marsten, Executive Director of the Board on Telecommunications -- Computer Applications (BOTCAP), and Jerome D. Rosenberg, BOTCAP Senior Staff Officer and the committee Study Director. We also wish to thank Lois A. Leak for her expert administrative and secretarial support.
それらの政府機関の委員会の連絡代表としての彼らの協力のための技術。 委員会はTelecommunicationsにおけるリチャードB.Marsten、Boardの事務局長の貢献とご支援に感謝します--コンピュータApplications(BOTCAP)、およびジェローム・D.ローゼンバーグ(BOTCAPシニアStaff Officerと委員会のStudyディレクター)。 また、彼女の専門の管理の、そして、秘書のサポートについてロイスA.Leakに感謝申し上げます。
National Research Council [Page x] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページx]RFC942 1985年2月のReport Transport
EXECUTIVE SUMMARY
要約
Computer communication networks have become a very important part of military and commercial operations. Indeed, the nation is becoming dependent upon their efficiency and reliability, and the recent proliferation of networks and their widespread use have emphasized the importance of developing uniform conventions, or protocols, for communication between computer systems. The Department of Defense (DOD) and the National Bureau of Standards (NBS) have been actively engaged in activities related to protocol standardization. This report is concerned primarily with recommendations on protocol standardization within the Department of Defense.
コンピュータ通信ネットワークは軍事の、そして、商業の操作の非常に重要な部分になりました。 本当に、国はそれらの効率と信頼性に依存するようになっています、そして、ネットワークの最近の増殖と彼らの普及使用は一定のコンベンション、またはプロトコルを発展させる重要性を強調しました、コンピュータ・システムのコミュニケーションのために。活発に国防総省(DOD)と規格基準局(NBS)にプロトコル標準化に関連する活動に従事していました。 このレポートは主として国防総省の中のプロトコル標準化の推薦に関係があります。
Department of Defense's Transmission Protocol
国防総省のトランスミッションプロトコル
The DOD's Defense Advanced Research Projects Agency (DARPA) has been conducting and supporting research on computer networks for over fifteen years (1). These efforts led to the development of modern packet-switched network design concepts. Transmission between computers is generally accomplished by packet switching using strict protocols for the control and exchange of messages. The Advanced Research Projects Agency network (ARPANET), implemented in the early 1970s, provided a testing ground for research on communications protocols. In 1978, after four years of development, the DOD promulgated versions of its Transmission Control Protocol (TCP) and an Internet Protocol (IP) and mandated their use as standards within the DOD. TCP is now widely used and accepted. These protocols meet the unique operational and functional requirements of the DOD, and any changes in the protocols are viewed with some trepidation by members of the department. DOD representatives have stated that standardizing TCP greatly increased the momentum within the DOD toward establishing interoperability between networks within the DOD.
DODの国防高等研究計画庁(DARPA)は、15年以上(1)のためのコンピュータネットワークの研究を行って、サポートしています。 これらの取り組みは現代のパケット交換網設計思想の開発につながりました。 一般に、コンピュータの間のトランスミッションは、メッセージのコントロールと交換に厳しいプロトコルを使用しながら、パケット交換で実行されます。 1970年代前半に実装されたAdvanced Research Projects Agencyネットワーク(アルパネット)は通信規約の調査のための試験場を供給しました。 1978年に、DODは4年間の開発の後に、通信制御プロトコル(TCP)とインターネットプロトコル(IP)のバージョンについて公表して、規格としてDODの中で彼らの使用を強制しました。 TCPを現在、広く使用して、受け入れます。 これらのプロトコルはDODのユニークな操作上的、そして、機能的な必要条件を満たします、そして、プロトコルにおけるどんな変化も何らかの恐怖をもって部のメンバーによって見られます。 DOD代表は、TCPを標準化するとDODの中のネットワークの間の相互運用性を確立することに向かって勢いがDODの中で大いに増強されたと述べました。
International Standards Organization's Transport Protocol
世界規格組織のトランスポート・プロトコル
The NBS Institute for Computer Sciences and Technology (ICST), in cooperation with the DOD, many industrial firms, and the International Standards Organization (ISO), has developed a new international standard
DODと提携したコンピューターサイエンシズとTechnology(ICST)のためのNBS Institute(多くの企業、および国際Standards Organization(ISO))は新しい世界規格を開発しました。
----- (1) The Advanced Research Projects Agency (ARPA) was reorganized and became the Defense Advanced Research Projects Agency (DARPA) in 1973.
----- (1) Advanced Research Projects Agency(ARPA)は再編成されて、1973年に国防高等研究計画庁(DARPA)になりました。
National Research Council [Page xi] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページξ]RFC942 1985年2月のReport Transport
Transport Protocol (TP-4) and a new Internetwork Protocol (2). These protocols will soon be available as commercial products. Although in part derived from TCP, the new protocols are not compatible with TCP (3). The U.S. standards organizations are supporting TP-4 in international operations, and the Department of Commerce is proposing TP-4 as a Federal Information Processing Standard (FIPS) for use by all federal agencies.
プロトコル(TP-4)と新しいInternetworkプロトコル(2)を輸送してください。 これらのプロトコルはすぐ、商品として利用可能になるでしょう。 TCPから一部派生しますが、新しいプロトコルはTCP(3)と互換性がありません。 米国規格組織は国際経営活動でTP-4をサポートしています、そして、商務省はすべての連邦機関による使用のために連邦情報処理基準(FIPS)としてTP-4を提案しています。
DOD OPERATIONAL AND TECHNICAL NEEDS
DODの操作上的、そして、技術的な必要性
The DOD has unique needs that could be affected by the Transport and Internet Protocol layers. Although all data networks must have some of these capabilities, the DOD's needs for operational readiness, mobilization, and war-fighting capabilities are extreme. These needs include the following:
DODには、Transportで影響を受けることができたユニークな必要性とインターネットプロトコル層があります。 すべてのデータ網には、これらの能力のいくつかがなければなりませんが、DODの操作上の準備、動員、および戦争で戦う能力の必要性は極端です。 これらの必要性は以下を含んでいます:
Survivability--Some networks must function, albeit at reduced performance, after many nodes and links have been destroyed.
生存性--ネットワークの中にはそれにしても、多くのノードとリンクが破壊された後に減少している性能で機能するものもなければなりません。
Security--Traffic patterns and data must be selectively protected through encryption, access control, auditing, and routing.
セキュリティ--暗号化、アクセスコントロール、監査、およびルーティングで選択的にトラフィック・パターンとデータを保護しなければなりません。
Precedence--Systems should adjust the quality of service on the basis of priority of use; this includes a capability to preempt services in cases of very high priority.
先行--システムは使用の優先権に基づいてサービスの質を調整するはずです。 これは非常に高い優先度に関するケースにサービスを先取りする能力を含んでいます。
Robustness--The system must not fail or suffer much loss of capability because of unpredicted situations, unexpected loads, or misuse. An international crisis is the strongest test of robustness, since the system must operate immediately and with virtually full performance when an international situation flares up unexpectedly.
丈夫さ--システムは、非予測された状況、予期していなかった負荷、または誤用のために能力の多くの損失を失敗してはいけませんし、また受けてはいけません。 国際的な危機は丈夫さの最も強いテストです、国際情勢が不意に燃え上がるとシステムがすぐにと実際には完全な性能で作動しなければならないので。
Availability--Elements of the system needed for operational readiness or fighting must be continuously available.
有用性--操作上の準備か戦いに必要であるシステムのElementsは絶え間なく手があいていなければなりません。
Interoperability--Different elements of the Department must be able to "talk" to one another, often in unpredicted ways between parties that had not planned to interoperate.
相互運用性--部の異なった要素はお互いに「話すことができなければなりません」、しばしば共同利用するのを計画していなかったパーティーの間の非予測された方法で。
----- (2) The ISO Transport Protocol and ISO Internetwork Protocol became Draft International Standards in September 1983 and April 1984, respectively. Commercial vendors normally consider Draft International Standards to be ready for implementation.
----- (2) ISO TransportプロトコルとISO Internetworkプロトコルは1983年9月、1984年4月にそれぞれDraftの国際Standardsになりました。 通常、商業ベンダーは、Draftの国際Standardsが実装ための準備をしていると考えます。
(3) Except where noted, the abbreviation TCP generally refers to both the DOD's Transmission Control Protocol and its Internet Protocol. Similarly, the abbreviation TP-4 refers to both the ISO Transport Protocol class 4 and its Internetwork Protocol. (Transport Protocol classes 0 to 3 are used for special purposes not related to those of this study.)
(3) 一般に、有名であるところを除いて、略語TCPはDODの通信制御プロトコルとそのインターネットプロトコルの両方を示します。 同様に、略語TP-4はISO Transportプロトコルクラス4とそのInternetworkプロトコルの両方を示します。 (輸送プロトコルクラス0〜3はこの研究のものに関連しない特別な目的に使用されます。)
National Research Council [Page xii] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページxii]RFC942 1985年2月のReport Transport
These operational needs reflect themselves into five technical or managerial needs:
これらの操作上の必要性は自分たちで技術的であるか経営者の必要性を5に反映します:
1. Functional and operational specifications (that is, will the
protocol designs meet the operational needs?);
2. Maximum interoperability;
3. Minimum procurement, development, and support costs;
4. Ease of transition to new protocols; and
5. Manageability and responsiveness to changing DOD requirements.
1. 機能的で操作上の仕様(すなわち、プロトコルデザインは操作上の需要を満たすでしょうか?、)。 2. 最大限のインターオペラビリティ。 3. 最小の調達、開発、およびサポートコスト。 4. 新しいプロトコルへの変遷の容易さ。 そして、5。 DOD要件を変えることへの管理可能性と反応性。
These are the criteria against which DOD options for using the ISO transport and internet protocols should be evaluated.
これらはISO輸送とインターネットプロトコルを使用するためのDODオプションが評価されるべきである評価基準です。
Interoperability is a very important DOD need. Ideally, DOD networks would permit operators at any terminal to access or be accessed by applications in any computer. This would provide more network power for users, integration of independently developed systems, better use of resources, and increased survivability. To increase interoperability, the Office of the Secretary of Defense has mandated the use of TCP for the Defense Communication System's Defense Data Network (DDN), unless waivers are granted. In addition, the Defense Communication Agency (DCA) is establishing standards for three higher-level "utility" protocols for file transfer, terminal access, and electronic mail. Partly as a result of these actions, it has become clear that there is growing momentum toward accepting interoperability and a recognition that it is an important operational need.
相互運用性は非常に重要なDODの必要性です。 理想的に、DODネットワークは、アクセスするどんな端末でもオペレータを可能にするか、またはアプリケーションでどんなコンピュータでもアクセスされるでしょう。 これはユーザ、独自に開発されたシステムの統合、リソースの、より良い使用、および増強された生存性により多くのネットワーク権限を提供するでしょう。 相互運用性を増強するために、国防長官オフィスはTCPのDefense Communication SystemのDefense Data Network(DDN)の使用を強制しました、権利放棄が承諾されない場合。 さらに、防衛通信委員会(DCA)はファイル転送、端末のアクセス、および電子メールのための3つのよりハイレベルの「ユーティリティ」プロトコルのために基準を定めています。 一部これらの動作の結果、それが重要な操作上の必要性であることは増加している勢いが相互運用性と認識を受け入れるのに向かっているのが明確になりました。
It is very important, however, to recognize that functional interoperability is only achieved with full generality when two communication nodes can interoperate at all protocol levels. For the DOD the relevant levels are as follows:
しかしながら、2つのコミュニケーションノードがすべてのプロトコルレベルで共同利用できるときだけ、機能的な相互運用性が完全な一般性で達成されると認めるのは非常に重要です。 DODに関しては、関連レベルは以下の通りです:
1. Internet, using IP;
2. Transport, using TCP;
3. Utility, using file, terminal, or mail protocols; and
4. Specific applications that use the above protocols for their
particular purpose.
1. インターネット、使用IP。 2. TCPを使用する輸送。 3. ユーティリティ、ファイルを使用するか、端末、またはメールプロトコル。 そして、4。 それらの特定の目的に上のプロトコルを使用する特定のアプリケーション。
Accordingly, if a network is developed using one transport protocol, it would generally not be able to interoperate functionally with other networks using the same transport protocol unless both networks were also using the higher-level utility and application protocols. In evaluating whether or not to convert to TP-4 and in developing a transition plan, the following factors must be considered:
それに従って、ネットワークが1つのトランスポート・プロトコルを使用することで開発されているなら、一般に、また、両方のネットワークが、よりハイレベルのユーティリティとアプリケーション・プロトコルを使用していなかったなら他のネットワークが同じトランスポート・プロトコルを使用していて、機能上共同利用できないでしょう。 TP-4に変えるかどうか評価して、変遷プランを開発する際に、以下の要素を考えなければなりません:
The DOD contains numerous communities of interest whose principal need is to interoperate within their own members, independently. Such communities generally have a specific, well-defined mission.
DODはそれら自身のメンバーの中に独自に共同利用する主体がことでなければならない興味がある多数の共同体を含みます。 一般に、そのような共同体には、特定の、そして、明確な任務があります。
National Research Council [Page xiii] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページxiii]RFC942 1985年2月のReport Transport
The DOD Intelligence Information System (DODIIS) and the World Wide Military Command and Control System (WWMCCS) are examples. Interoperability is needed primarily between the higher layer applications programs initially unique to each community of interest.
DOD Intelligence情報システム(DODIIS)、World Wide Military Command、およびControl System(WWMCCS)は例です。 相互運用性が主として初めは各利益共同体にユニークなより高い層のアプリケーションプログラムの間で必要です。
There are many different kinds of operations needed between communities of interest. Examples of such operations are headquarters' need for access to several subordinate communities and the communities' need for some minimum functional interoperability with each other (such as mail exchange).
興味がある共同体の間で必要である多くの異種の操作があります。 そのような操作に関する例は、本部のいくつかの下位の共同体へのアクセスの必要性と共同体の互い(メール交換などの)がある何らかの最小の機能的な相互運用性の必要性です。
The need for functional interoperability can arise, unexpectedly and urgently, at a time of crisis or when improved management opportunities are discovered. Widespread standardization of TP-4 and higher-level protocols can readily help to achieve these needs. Often, special development of additional applications that cost time and money will be necessary.
機能的な相互運用性の必要性は起こることができます、不意で、緊急で、危機かそれとも経営改善の機会がいつ発見されるかとき一度に。 TP-4と上位レベル・プロトコルの広範囲の標準化は、これらの必要性を達成するのを容易に助けることができます。 しばしば、時間とお金がかかる追加アプリケーションの特別な開発は必要になるでしょう。
The DOD needs functional interoperability with many important external agencies that are committed to ISO standards: The North Atlantic Treaty Organization (NATO), some intelligence and security agencies, and other parts of the federal government.
DODはISO規格に心がける多くの重要な外部の政府機関がある機能的な相互運用性を必要とします: 連邦政府の北大西洋条約機構(NATO)、何らかの知性、警備機関、および他の部分。
The same objectives that have prompted the use of standardized protocols at higher-level headquarters will lead to their use by tactical groups in the field.
よりハイレベルの本部で標準化されたプロトコルの使用をうながしたのと同じ目的はその分野の戦術のグループによる彼らの使用につながるでしょう。
SOME COMPARISONS
いくつかの比較
A detailed comparison of the DOD Transmission Control Protocol and the ISO Transport Protocol indicates they are functionally equivalent and provide essentially similar services. Because it is clear that a great deal of care and experience in protocol development have gone into generating the specifications for TP-4, the committee is confident that TP-4 will meet military requirements.
DOD通信制御プロトコルとISO Transportプロトコルの詳細な比較は、彼らが機能上同等であり、本質的には同様のサービスを提供するのを示します。 プロトコル開発の大きな注意と経験にTP-4のための仕様を生成するために入ったのが、明確であるので、委員会はTP-4が軍事の必要条件を満たすと確信しています。
Although there are differences between the two protocols, they do not compromise DOD requirements. And, although in several areas, including the data transfer interface, flow control, connection establishment, and out-of-band, services are provided in different ways by the two protocols, neither seems intrinsically superior. Thus, while existing applications may need to be modified somewhat if moved from TCP to TP-4, new applications can be written to use either protocol with a similar level of effort.
2つのプロトコルの間には、違いがありますが、それらはDODに要件に感染しません。 そして、2つのプロトコルで異なった方法でデータ転送インタフェース、フロー制御、コネクション確立を含むいくつかの領域とバンドの外にサービスを提供しますが、どちらも本質的に優れているように見えません。 したがって、いくらかTCPからTP-4まで動かされるなら既存のアプリケーションが、変更される必要があるかもしれない間、同じ水準の取り組みがあるどちらのプロトコルも使用するために新しいアプリケーションを書くことができます。
The TCP and TP-4 protocols are sufficiently equivalent in their security-related properties in that there are no significant technical points favoring the use of one over the other.
どんなかなりのテクニカルポイントもないので、TCPとTP-4プロトコルはもう片方より1つの使用を好みながら、彼らのセキュリティ関連の所有地で十分同等です。
While TCP currently has the edge in maturity of implementation, TP-4 is gaining rapidly due to the worldwide support for and acceptance of the
TCPが実装の円熟のときに現在強味を持っている間、TP-4が世界的なサポートのため急速に獲得している、承認
National Research Council [Page xiv] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページxiv]RFC942 1985年2月のReport Transport
Open System Interconnection (OSI) international standards. Experimental TCP implementations were completed in 1974 at Stanford University and BBN Communications Corporation. Between 1974 and 1982 a large number of implementations were produced. The Defense Advanced Research Projects Agency (ARPA) network switched to a complete use of TCP in January 1983. Operations have been satisfactory and its use is growing. A number of TCP implementations are also in commercial use in various private networks.
System Interconnection(OSI)世界規格を開いてください。 実験的なTCP実装は1974年にスタンフォード大学とBBN Communications社で完成しました。 実装の1974年から1982の多くが生産されました。 国防高等研究計画庁(ARPA)ネットワークは1983年1月のTCPの完全な使用に切り替わりました。 操作は満足できています、そして、使用は成長しています。 様々な私設のネットワークには多くのTCP実装が商業用途でもあります。
In contrast, TP-4 has not yet been implemented in any large operational system. It has been tested experimentally, however, and has received endorsement by many commercial vendors worldwide. In addition, substantial portions of TP-4 have been demonstrated at the National Computer Conference in July 1984.
対照的に、TP-4はどんな大きい基幹系システムでもまだ実装されていません。 それは、しかしながら、実験的にテストされて、世界中で多くの商業ベンダーによる裏書きを受けました。 さらに、TP-4のかなりの部分が1984年7月にNationalコンピュータコンファレンスで示されました。
The Internet Protocol (IP) part of the standards is not believed to be a problem. The ISO IP is not as far along as TP-4, but it is much less complex. The ISO IP, based very strongly on the DOD IP, became a draft international standard in April 1984.
規格のインターネットプロトコル(IP)一部が問題であることは信じられていません。 しかし、TP-4、それがあまりそれほど複雑でないようにISO IPはずっと遠くはありません。 非常に強くDOD IPに基づくISO IPは1984年4月に草稿世界規格になりました。
The rapidity of the progress in ISO and the results achieved over the past two years have surprised even the supporters of international standards. The reasons for this progress are twofold: strong market demands stemming from the growing integration of communications and data processing and the progress in networking technology over the past years as the result of ARPA and commercial developments.
ISOでの進歩の急速と過去2年間獲得された結果は世界規格の支持者さえ驚かせました。 この進歩の理由は二つです: 強気市況は過去の年月にわたってARPAと商業開発の結果としてコミュニケーション、データ処理、および進歩の増加している統合からネットワーク・テクノロジーでステミングを要求します。
Although the DOD networks have been a model upon which the ISO transport standards have been built, the rest of the world is adopting TP-4. Because the DOD represents a small fraction of the market and because the United States supports the ISO standard, it is not realistic to hope that TP-4 can be altered to conform with TCP. This raises the question as to what action should be taken by the DOD with respect to the ISO standard.
DODネットワークはISO輸送規格が築き上げられたモデルですが、他の国々はTP-4を採用しています。 DODが市場のわずかな部分を代表して、合衆国がISO規格をサポートするので、TCPに従うためにTP-4を変更できることを望んでいるのは現実的ではありません。 どんな行動がISO規格に関してDODによって取られるはずであるかに関してこれは疑問を引き起こします。
SOME ECONOMIC CONSIDERATIONS
いくつかの経済上の考慮
The DOD has a large and growing commitment in operational TCP networks, and this will increase by 50 to 100 percent in the next eighteen months. This rate of investment will probably continue for the next five years for new systems and the upgrading of current ones. The current Military Network (MILNET) and Movement Information Network (MINET) systems are expanding and will shortly be combined. The Strategic Air Command Digital Information Network (SACDIN) and DODIIS are undergoing major upgrading. When these changes are completed, there are plans to upgrade the WWMCCS Intercomputer Network (WIN) and to add separate SECRET and TOP SECRET networks. There are plans to combine these six networks in the late 1980s, and they will become interoperable and multilevel secure using an advanced technology now under development. If these plans are implemented on schedule, a delay of several years in moving to TP-4 would mean that the DOD networks in the late 1980s would be virtually all TCP-based. Subsequent conversion to international standards would be very expensive
DODは操作上のTCPネットワークで大きくて増加している委任を持っています、そして、これは次の18カ月で50〜100パーセント増加するでしょう。 この投資率は新しいシステムのための次の5年と現在のもののアップグレードのためにたぶん続くでしょう。 現在のMilitary Network(MILNET)とMovement情報Network(MINET)システムは、広がっていて、まもなく、結合されるでしょう。 戦略空軍Digital情報Network(SACDIN)とDODIISは主要なアップグレードを受けています。 これらの変化が終了しているとき、WWMCCS Intercomputer Network(WIN)をアップグレードさせて、別々のSECRETとTOP SECRETネットワークを加える計画があります。 1980年代後半にこれらの6つのネットワークを合併する計画があります、そして、それらは、現在開発中の先進技術を使用することで共同利用できて多レベル安全になるでしょう。 これらのプランがスケジュール通りに実装されるなら、TP-4に移行することにおける数年の遅れは、ほとんどすべてがTCPベースであるなら1980年代後半のDODネットワークがそうすることを意味するでしょう。 世界規格へのその後の変換は非常に高価でしょう。
National Research Council [Page xv] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページxv]RFC942 1985年2月のReport Transport
if hastily attempted in order to maintain established DOD interoperability and gain interoperability with a large body of users.
急いで確立したDOD相互運用性を維持して、ユーザの大きいボディーで相互運用性を獲得するために試みられるなら。
As the Department of Defense policy recognizes, there are significant advantages in using commercial vendor products if they meet the department's operational needs. The major advantages are as follows:
国防総省方針が認めるように、彼らが部の操作上の需要を満たすなら商業メーカー製品を使用するのにおいて重要な利点があります。 主要な利点は以下の通りです:
Costs to the DOD for development, production, and maintenance are significantly lower because (1) vendors spread the cost over a much larger user base, (2) commercial vendors are generally more efficient in their operations, and (3) vendors look for ways to improve their product to meet competition.
(1) ベンダーがはるかに大きいユーザベースにわたって費用を広げて、(2) 彼らの操作で一般に、商業ベンダーが、より効率的であり、(3) ベンダーが競合に応じるためにそれらの製品を改良する方法を探すので、開発、生産、およびメインテナンスのためのDODへのコストはかなり低いです。
The department generally gets more effective products because vendors integrate the protocol functions into their entire software and hardware product line. Thus the DOD may be able eventually to use commercial software products that are built on top of, and thereby take advantage of, the transport protocols.
ベンダーがそれらの全体のソフトウェアとハードウェア製品ラインとプロトコル機能を統合するので、一般に、部は、より効果的な製品を手に入れます。 したがって、DODは、結局、トランスポート・プロトコルについて組立の商用ソフトウェア製品を使用して、その結果、利点を活用するためにできるかもしれません。
By depending on industry to manage the development and maintenance of products, the department can use its scarce management and technical resources on activities unique to its mission.
製品の開発とメインテナンスを管理するために産業に頼ることによって、部は任務にユニークな活動に関するその不十分な管理と技術的な資源を使用できます。
Because the costs of transport and internet protocol development and maintenance are so intertwined with other factors, it is impossible to give a precise estimate of the savings that would be achieved by using commercial products. Savings will vary in individual cases. The marginal savings should range from 30 to 80 percent.
輸送のコストとインターネットプロトコル開発とメインテナンスが他の要素で非常にからみ合うので、商品を使用することによって達成される貯蓄の正確な見積りを与えるのは不可能です。 貯蓄は個々の場合に異なるでしょう。 限界貯蓄は30〜80パーセントに及ぶべきです。
RECOMMENDATIONS
推薦
The ISO protocols are now well specified but will not generally be commercially available for many months. Nevertheless, this committee believes that the principles on which they are based are well-established, and the protocols can be made to satisfy fully DOD's needs. The committee recommends that the DOD move toward adoption of TP-4 as costandard with TCP and toward exclusive use of TP-4.
ISOプロトコルは、現在、よく指定されますが、一般に、商業的に何カ月も利用可能にならないでしょう。 それにもかかわらず、この委員会は、彼らが基づいている原則が安定していて、プロトコルにDODの需要を完全に満たさせることができると信じています。 委員会は、DODがcostandardとしてTCPとTP-4の専用に向かってTP-4の採用に近づくことを勧めます。
Transition to the use of the ISO standards, however, must be managed in a manner that will maintain DOD's operational capabilities and minimize risks. The timing of the transition is, therefore, a major concern.
しかしながら、DODの運用能力を維持して、危険を最小にする方法でISO規格の使用への変遷を管理しなければなりません。 したがって、変遷のタイミングは主要な関心事です。
Descriptions of two options that take this requirement into account follow. A majority of the committee recommends the first option, while a minority favors the second. A third option--to defer action--is also described but not recommended.
この要件を考慮に入れる2つのオプションの記述は続きます。 委員会の大部分が第1の選択を推薦しますが、少数が2番目を支持します。 3番目のオプション--動作--また、説明されますが、推薦されないのを延期するために。
Option 1
オプション1
The first option is for the DOD to immediately modify its current transport policy statement to specify TP-4 as a costandard along with TCP. In addition, the DOD would develop a military specification for
第1の選択はDODがすぐにTCPに伴うcostandardとしてTP-4を指定するように現在の輸送施政方針を変更することです。 さらに、DODは軍事の仕様を開発するでしょう。
National Research Council [Page xvi] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページxvi]RFC942 1985年2月のReport Transport
TP-4 that would also cover DOD requirements for discretionary options allowed under the NBS protocol specifications. Requests for proposals (RFPs) for new networks or major upgrades of existing networks would specify TP-4 as the preferred protocol. Contracts for TP-4 systems would be awarded only to contractors providing commercial products, except for unique cases.
また、任意のオプションのためのDOD要件をカバーするTP-4がNBSの下にプロトコル仕様を許容しました。 既存のネットワークの新しいネットワークか大きな更新のための提案(RFPs)を求める要求は都合のよいプロトコルとしてTP-4を指定するでしょう。 ユニークなケース以外の商品を供給する契約者だけがTP-4システムのための契約を獲得するでしょう。
Existing networks that use TCP and new networks firmly committed to the use of TCP-based systems could continue to acquire implementations of TCP. The DOD should carefully review each case, however, to see whether it would be advantageous to delay or modify some of these acquisitions in order to use commercial TP-4 products. For each community of users it should be decided when it is operationally or economically most advantageous to replace its current or planned systems in order to conform to ISO standards without excessively compromising continued operations.
TCPを使用する既存のネットワークとしっかりTCPベースのシステムの使用に心がける新しいネットワークは、TCPの実装を取得し続けることができました。 しかしながら、DODは、商業TP-4製品を使用するために遅らせるか、またはこれらのいくつかの獲得を変更するのが有利であるかどうか確認するために慎重に各ケースについて再審理するはずです。 現在の、または、計画されたシステムを置き換えるのが操作上か経済的に最も有利であるときに、ユーザの各共同体において、それは、継続運転に過度に感染しないでISO規格に従うために定まっているべきです。
United States government test facilities would be developed to enable validation of TP-4 products (4). The Department of Defense would either require that products be validated using these test facilities or that they be certified by the vendor. The test facilities could also be used to isolate multivendor protocol compatibility problems. The existing NBS validation tools should be used as the base for the DOD test facilities.
合衆国政府テスト機能は、TP-4製品(4)の合法化を可能にするために見いだされるでしょう。 国防総省は、製品がこれらのテスト機能を使用することで有効にされるか、またはそれらがベンダーによって公認されるのを必要とするでしょう。 また、「マルチ-ベンダー」プロトコル互換性の問題を隔離するのにテスト機能を使用できました。既存のNBS合法化ツールはDODテスト機能にベースとして使用されるべきです。
Because under this option networks based on both TCP and TP-4 would coexist for some time, several capabilities that facilitate interoperability among networks would need to be developed. The Department of Defense generally will not find them commercially available. Examples are gateways among networks or specialized hosts that provide services such as electronic mail. The department would need to initiate or modify development programs to provide these capabilities, and a test and demonstration network would be required.
TCPとTP-4の両方に基づくネットワークはしばらくこのオプションで共存しているでしょう、したがって、ネットワークの中で相互運用性を容易にするいくつかの能力が開発される必要があるでしょう。 一般に、国防総省は、それらが商業的に利用可能であることがわからないでしょう。 例は電子メールなどのサービスを提供するネットワークか専門化しているホストの中のゲートウェイです。 部は、これらの能力を提供するように開発プログラムを開始するか、または変更する必要があるでしょう、そして、テストとデモンストレーションネットワークが必要でしょう。
Option 2
オプション2
Under Option 2 the Department of Defense would immediately announce its intention to adopt TP-4 as a transport protocol costandard with TCP after a satisfactory demonstration of its suitability for use in military networks. A final commitment would be deferred until the demonstration has been evaluated and TP-4 is commercially available.
Option2の下では、国防総省はすぐに、ミリタリー・ネットワークにおける使用への適合の満足できるデモンストレーションの後にTCPと共に輸送プロトコルcostandardとしてTP-4を採用するという意志を発表するでしょう。 デモンストレーションが評価されて、TP-4が商業的に利用可能になるまで、最終的な委任は延期されるでしょう。
The demonstration should take at most eighteen months and should involve development of TP-4 implementations and their installation. This option differs from Option 1 primarily in postponing the adoption of a TP-4 standard and, consequently, the issuance of RFPs based on TP-4 until successful completion of a demonstration. The department,
デモンストレーションは、高々18カ月かかるべきであり、TP-4実装の開発と彼らのインストールにかかわるべきです。 このオプションは主としてデモンストレーションの無事終了までTP-4に基づく、TP-4規格の採用とその結果RFPsの発行を延期するのにおいてOption1と異なっています。 部
----- (4) Validation means a systematic and thorough state-of-the-art testing of the products to assure that all technical specifications are being achieved.
----- (4) 合法化は、製品の系統的で徹底的な最先端のテストが、すべての技術仕様書が達成することにされるのであることを保証することを意味します。
National Research Council [Page xvii] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページxvii]RFC942 1985年2月のReport Transport
however, should proceed with those provisions of Option 1 that may be completed in parallel with the demonstration. Early issuance of a TP-4 military specification, development of validation procedures, and implementation of means for interoperability would be particularly important in this regard.
しかしながら、デモンストレーションと平行して完成するかもしれないOption1に関するそれらの条項を続けるべきです。 TP-4の軍事の仕様の早めの発行、合法化手順の開発、および相互運用性のための手段の実装は特にこの点で重要でしょう。
Option 3
オプション3
Under the third option the DOD would continue using TCP as the accepted transport standard and defer any decision on the use of TP-4 indefinitely. The department would be expected to stay well informed on the development and use of the new protocol in the commercial and international arena and, with the National Bureau of Standards, work on means to transfer data between the two protocol systems. Testing and evaluation of TP-4 standards by NBS would continue. The DOD might eventually accommodate both protocol systems in an evolutionary conversion to TP-4.
3番目のオプションで、DODは受け入れられた輸送規格としてTCPを使用し続けて、TP-4の使用のときにどんな決定も無期限に延期するでしょう。 部は、商業的、そして、国際的なアリーナに新しいプロトコルの開発と使用のときに通じた状態で滞在して、規格基準局と共に2台のプロトコルシステムの間にデータを移す手段に働くと予想されるでしょう。NBSによるTP-4規格のテストと評価は続くでしょう。 DODは結局、進化論の変換で両方のプロトコルシステムをTP-4に収容するかもしれません。
Comparison of Options
オプションの比較
The committee believes that all three options equally satisfy the functional objectives of the DOD, including matters of security. It believes the two protocols are sufficiently similar and no significant differences in performance are to be expected if the chosen protocol implementation is of equal quality and is optimized for the given environment.
委員会は、すべての3つのオプションが等しくセキュリティの問題を含むDODの機能目的を満たすと信じています。 性能のどんな著しい違いもそれが、2つのプロトコルが十分同様であると信じて、選ばれたプロトコル実装が等しい品質があって、与えられた環境のために最適化されるなら予想されないことです。
The primary motivation for recommending Option 1 is to obtain the benefits of standard commercial products in the communication protocol area at an early date. Benefits include smaller development, procurement, and support costs; more timely updates; and a wider product availability. By immediately committing to TP-4 as a costandard for new systems, Option 1 minimizes the number of systems that have to be converted eventually from TCP. The ability to manage the transition is better than with Option 2 since the number of systems changed would be smaller and the time duration of mixed TCP and TP-4 operation would be shorter. Interoperability with external systems (NATO, government, commercial), which presumably will also use TP-4, would be brought about more quickly. Option 1 involves greater risk, however, since it commits to a new approach without as complete a demonstration of its viability.
Option1を推薦することに関するプライマリ動機は期日前半の通信プロトコル領域の標準の商品の利益を得ることです。 利益は、よりわずかな開発、調達、およびサポートコストを含んでいます。 よりタイムリーなアップデート。 そして、より広い製品の入手可能性。 すぐに新しいシステムのためのcostandardとしてTP-4に公約することによって、Option1は結局TCPから変換されなければならないシステムの数を最小にします。 変えられたシステムの数は、より少ないでしょう、そして、混ぜられたTCPとTP-4操作の時間持続時間は、より短いでしょう、したがって、変遷を管理する能力がOption2より良いです。 外的システム(NATO、政府、コマーシャル)がある相互運用性はおよそよりすばやくもたらされているでしょう。(おそらく、また、外的システムはTP-4を使用するでしょう)。 しかしながら、オプション1は、生存力の同じくらい完全なデモンストレーションなしで新しいアプローチに公約するので、より高い危険にかかわります。
As with Option 1, a primary benefit of following Option 2 would be obtaining the use of standard commercial products. Unit procurement costs probably would be lower than with Option 1 because the commercial market for TP-4 will have expanded somewhat by the time DOD would begin to buy TP-4 products. Risk is smaller, compared to Option 1, because testing and demonstration of the suitability for military use will have preceded the commitment to the ISO protocols. Transition and support costs would be higher than for Option 1, however, because more networks and systems would already have been implemented with TCP. Also this is perhaps the most difficult option to manage since the largest number of system conversions and the
Option1なら、Option2に続く主要便益は標準の商品の使用を得ているでしょう。 DODがいくらか製品をTP-4に買い始めるだろうという時までにTP-4の商業市場が広がってしまうだろうので、調達がかかる単位はたぶんOption1より低いでしょう。 リスクは、より低いです、Option1と比べて、適合のテストとデモンストレーションが軍用にISOプロトコルの委任に先行してしまうだろうので。 より多くのネットワークとシステムはTCPと共に既に導入されたでしょう、しかしながら、したがって、変遷とサポートコストはOption1より高いでしょう。 そしてまた、システム変換の最多数以来これが恐らく管理するのが最も難しいオプションである。
National Research Council [Page xviii] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページxviii]RFC942 1985年2月のReport Transport
longest interval of mixed TCP and TP-4 operations would occur. In addition, interoperability with external networks through standardization would be delayed.
混ぜられたTCPとTP-4操作の最長間隔は起こるでしょう。 さらに、標準化による外部のネットワークがある相互運用性は遅れるでしょう。
The principal benefit of exercising Option 3 would be the elimination of transition cost and the risk of faulty system behavior and delay. It would allow the most rapid achievement of full internal interoperability among DOD systems. Manageability should be good because only one set of protocols would be in use (one with which the DOD already has much experience), and because the DOD would be in complete control of system evolution. Procurement costs for TCP systems would remain high compared with standard ISO protocol products, however, and availability of implementations for new systems and releases would remain limited. External interoperability with non-DOD systems would be limited and inefficient.
Option3を運動させる主要な利益は、変遷費用の除去と不完全なシステムの振舞いと遅れのリスクでしょう。 それはDODシステムの中に完全な内部の相互運用性の最も急速な実績を許容するでしょう。1セットのプロトコルだけが使用中でしょう、そして、(DODには多くの経験が既にあるもの)DODはシステム展開の完全なコントロール中でしょう、したがって、管理可能性が良いはずです。 しかしながら、TCPシステムのための調達コストは標準のISOプロトコル製品と比べて高いままで残っているでしょう、そして、新しいシステムとリリースのための実装の有用性は制限されたままで残っているでしょう。 非DODシステムがある外部の相互運用性は、限られていて効率が悪いでしょう。
In summary, Option 1 provides the most rapid path toward the use of commercial products and interoperability with external systems. Option 2 reduces the risk but involves somewhat greater delay and expense. Option 3 involves the least risk and provides the quickest route to interoperability within the Defense Department at the least short-term cost. These are, however, accompanied by penalties of incompatibility with NATO and other external systems and higher life-cycle costs.
概要では、Option1は外的システムで商品と相互運用性の使用に向かって最も急速な経路を提供します。オプション2は、危険を減少させますが、いくらか大きい遅れと費用を伴います。 オプション3は、国防総省の中で最も短期的でない費用で最少の危険にかかわって、最も迅速なルートを相互運用性に提供します。 しかしながら、これらはNATOがある不一致、他の外的システム、および、より高いライフサイクルコストの刑罰によって伴われます。
National Research Council [Page xix] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページxix]RFC942 1985年2月のReport Transport
National Research Council [Page xx] RFC 942 February 1985 Report Transport on Protocols
プロトコルの調査評議会[ページxx]RFC942 1985年2月のReport Transport
I. INTRODUCTION
I.序論
For the past two decades industry and government have experienced an increasing need to share software programs, transfer data, and exchange information among computers. As a result, computer-to-computer data communications networks and, therefore, communication formats and procedures, or protocols, have proliferated. The need to interconnect these networks is obvious, but the problems in establishing agreements among users on the protocols have heightened.
過去20年間の間、産業と政府はコンピュータの中でソフトウェアプログラム、転送データ、および交換情報を共有する増加する必要性を経験しました。 その結果、したがって、コンピュータからコンピュータのデータへの通信網とコミュニケーション形式と手順か、プロトコルが増殖しました。 これらのネットワークとインタコネクトする必要性は明白ですが、プロトコルでユーザの中で協定を確立することにおける問題は高められました。
The Department of Defense (DOD) has been conducting research and development on protocols and communication standards for more than fifteen years. In December 1978 the DOD promulgated versions of the Defense Advanced Research Projects Agency's (DARPA) Transmission Control Protocol (TCP) and Internet Protocol (IP) as standards within DOD. With the participation of major manufacturers and systems houses, the DOD has implemented successfully over twenty different applications of these standards in DOD operational data communications networks.
国防総省(DOD)は15年間以上プロトコルとコミュニケーション規格で研究開発を行っています。 1978年12月に、DODは規格としてDODの中で国防高等研究計画庁(DARPA)の通信制御プロトコル(TCP)とインターネットプロトコル(IP)のバージョンについて公表しました。 大手メーカーとシステム家の参加で、DODは首尾よくDODのこれらの規格の20以上の異なったアプリケーションに操作上のデータ通信網を実装しました。
The Institute for Computer Sciences and Technology (ICST) of the National Bureau of Standards (NBS) is the government agency responsible for developing network protocols and interface standards to meet the needs of federal agencies. The Institute has been actively helping national and international voluntary standards organizations develop sets of protocol standards that can be incorporated into commercial products.
規格基準局(NBS)のコンピューターサイエンシズとTechnology(ICST)のためのInstituteは展開しているネットワーク・プロトコルとインターフェース規格が連邦機関の需要を満たすのにおいて責任がある政府機関です。 Instituteは、国家的、そして、国際的な自主基準組織が商品に組み入れることができるプロトコル標準のセットを発展させるのを活発に助けています。
Working with both industry and government agencies, the ICST has developed protocol requirements based, in terms of functions and services, on the DOD's TCP. These requirements were submitted to the International Standards Organization (ISO) and resulted in the development of a transport protocol (TP-4) that has the announced support of twenty computer manufacturers.
産業と政府機関の両方で働いていて、ICSTは開発されたプロトコル要件を基づかせています、機能とサービスで、DODのTCPで。 これらの要件は、国際Standards Organization(ISO)に提出して、20のコンピュータメーカーの発表されたサポートを持っているトランスポート・プロトコル(TP-4)の開発をもたらしました。
Although the ISO's TP-4 is based on the DOD's TCP, the two protocols are not compatible. Thus manufacturers who wish to serve DOD, while remaining able to capture a significant share of the worldwide market, have to field two product lines that are incompatible but perform the same function. The Institute for Computer Sciences and Technology would like to have a single set of protocol standards that serves both the DOD, other government agencies, and commercial vendors.
ISOのTP-4はDODのTCPに基づいていますが、2つのプロトコルは互換性がありません。 したがって、世界的な市場のかなり重要な貢献を得たことができるままで残っている間にDODに役立ちたがっているメーカーは、2つの両立しない製品ラインをさばきますが、同じ機能を実行しなければなりません。 コンピューターサイエンシズとTechnologyのためのInstituteは両方にDODに役立つ1セットのプロトコル標準、他の政府機関、および商業ベンダーが欲しいです。
It would be to the advantage of the DOD to use the same standards as the rest of the world. The dilemma, however, is understandable: The DOD
DODが他の国々と同じ規格を使用する利点にはそれがあるでしょう。 しかしながら、ジレンマは理解できます: DOD
National Research Council [Page 1] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[1ページ]RFC942 1985年2月のレポート輸送
has well satisfied its requirements by its own tried and proven protocols, the agency has invested heavily in systems operating successfully with TCP, and the Armed Forces is increasingly adopting the protocol. Thus, although DOD's policy is to use commercial standards whenever suitable, it is hesitant about converting to the ISO TP-4 protocols. In addition, the DOD is not certain whether the ISO TP-4 completely satisfies military requirements.
試みられたそれ自身のもので上手に要件を満たして、プロトコルであると立証されて、政府機関は大いにTCPと共に首尾よく作動するシステムを投資しました、そして、軍隊はますますプロトコルを採用しています。 したがって、DODの方針が適当であるときはいつも、商業規格を使用することですが、それはISO TP-4プロトコルに変えることに関してためらっています。 さらに、DODはISO TP-4が軍事の要件を完全に満たすかどうかを確信していません。
In 1983 both DOD and the ICST agreed that an objective study of the situation was needed. Each requested assistance from the National Research Council. The National Research Council, through its Board on Telecommunications and Computer Applications (BOTCAP), appointed a special Committee on Computer-Computer Communication Protocols to study the issues and develop recommendations and guidelines for ways to resolve the differences in a mutually beneficial manner.
1983年に、DODとICSTの両方が、状況の客観的な研究が必要であったのに同意しました。 それぞれが調査評議会から援助を要請しました。 Councilが互いに有利な方法の違いを決議する方法のために問題を研究して、推薦とガイドラインを開発するためにコンピュータコンピュータCommunicationプロトコルでTelecommunicationsとコンピュータApplications(BOTCAP)の上のBoardを通して特別なCommitteeを任命したNational Research。
The six items composing the committee's scope of work are as follows:
委員会の業務範囲を構成する6つの項目は以下の通りです:
1. Review the technical aspects of the DOD transmission control and
ICST transport protocols.
1. DOD転送管理とICSTトランスポート・プロトコルの技術的側面について調査してください。
2. Review the status of the implementation of these protocols.
2. これらのプロトコルの実装の状態について調査してください。
3. Review the industrial and government markets for these protocols.
3. これらのプロトコルの産業と政府市場を再検討してください。
4. Analyze the technical and political implications of the DOD and
ICST views on the protocols.
4. プロトコルに関するDODとICST意見の技術的で政治上の含意を分析してください。
5. Report on time and cost implications to the DOD, other federal
entities, and manufacturers of the DOD and ICST positions.
5. 含意をDOD、他の連邦の実体、およびDODとICST位置のメーカーに定刻に報告して、費やさせてください。
6. Recommend courses of action toward resolving the differences
between the DOD and ICST on these protocol standards.
6. DODとICSTの違いを決議することに向かってこれらのプロトコル標準で動作の方針を推薦してください。
The committee devoted considerable effort to reviewing the objectives and goals of the DOD and NBS that relate to data communications, the technical aspects of the two protocols, the status of their implementation in operating networks, and the market conditions pertaining to their use. This process included hearing government and industry presentations and reviewing pertinent literature. The results of this part of the study are presented in Sections II through VII. Concurrent with this research and analysis, the committee developed ten possible options that offered plausible resolutions of the problem. These ranged from maintaining the status quo to an immediate switchover from one protocol to the other. From these ten initial options three were determined to hold the greatest potential for resolving the problem.
委員会は目的、データ通信に関連するDODとNBSの目標、2つのプロトコルの技術的側面、操作ネットワークにおけるそれらの実装の状態、および彼らの使用に関係する市況を再検討するのにかなりの取り組みをささげました。 このプロセスは、政府と産業プレゼンテーションを聞いて、適切な文学を批評するのを含んでいました。 研究のこの部分の結果はVIIを通してセクションIIに提示されます。 この研究と分析で同時発生であり、委員会は問題のもっともらしい解決を提供した10の可能なオプションを開発しました。 これらは現状を維持するのから即座の転換まで1つのプロトコルからもう片方まで及びました。 これらの10の初期のオプションによって、3は問題を解決する最大級の可能性を保持することを決定しています。
Section VIII describes the three options, Section IX provides a cost comparison, and Section X provides an overall evaluation of the three options. Section XI presents the committee's basic and detailed recommendations for how best the DOD might approach the differences between its protocol and the ISO protocol.
セクションVIIIは3つのオプションについて説明します、そして、セクションIXは原価比較を提供します、そして、セクションXは3つのオプションの総括的評価を提供します。 セクションXIはDODがどうプロトコルとISOプロトコルの違いに最もよく、アプローチできるように委員会の基本的で詳細な推薦を提示するか。
National Research Council [Page 2] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[2ページ]RFC942 1985年2月のレポート輸送
II. REVIEW OF NBS AND DOD OBJECTIVES
II。 NBSとDOD目的のレビュー
The National Bureau of Standards and the Department of Defense are such disparate organizations that the committee felt it needed to begin its study with a definition of the roles and expectations of each with regard to the protocol issues in question. The following provides a review of each organization's objectives (5).
規格基準局と国防総省が非常に異種の組織であるので、委員会は、それが、役割の定義とそれぞれへの期待で問題のプロトコル問題に関して研究を始める必要だったと感じました。 以下は各組織の目的(5)のレビューを提供します。
NBS OBJECTIVES
NBS目的
The National Bureau of Standards has three primary goals in computer networking:
規格基準局には、コンピュータのネットワーク化における3つのプライマリ目標があります:
1. To develop networking and protocol standards that meet U.S.
government and industry requirements and that will be implemented
in off-the-shelf, commercial products.
1. 米国政府、産業必要条件、およびそれを満たすネットワークとプロトコル標準を開発するのはすぐ入手できて、商業の製品の中に実装されるでしょう。
2. To develop testing methodologies to support development and
implementation of computer network protocols.
2. コンピュータ・ネットワーク・プロトコルの開発と実装をサポートするためにテスト方法論を開発するために。
3. To assist government and industry users in the application of
advanced networking technologies and computer and communications
equipment manufacturers in the implementation of standard
protocols.
3. 標準プロトコルの実装で高度なネットワーク・テクノロジー、コンピュータ、および通信装置メーカーのアプリケーションに政府と産業のユーザを助けるために。
Development of Networking and Protocol Standards
ネットワークとプロトコル標準の開発
The Bureau accomplishes the first objective through close coordination and cooperation with U.S. computer manufacturers and communications system developers. Technical specifications are developed cooperatively with U.S. industry and other government agencies and provided as proposals to voluntary standards organizations.
事務局は米国のコンピュータメーカーと通信網開発者との綿密な調整と協力で最初の目的を達成します。 技術仕様書を米国産業と他の政府機関と共に協力して開発して、提案として自主基準組織に提供します。
Because the Department of Defense is potentially the largest government client of these standards, DOD requirements are carefully factored into these proposals. In addition, protocols for computer-to-computer communications developed within the DOD research community are used as an
国防総省が潜在的にこれらの規格の最も大きい政府のクライアントであるので、これらの提案は慎重にDOD要件の要因として考慮されます。 さらに、コンピュータ間通信のためのプロトコルは研究団体が使用されているDOD中で展開しました。
----- (5) The objectives were reviewed by representatives of NBS and DOD, respectively.
----- (5) 目的はNBSとDODの代表によってそれぞれ見直されました。
National Research Council [Page 3] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[3ページ]RFC942 1985年2月のレポート輸送
exact statement of DOD functional needs for a particular protocol and form a basis for the functions, features, and services of NBS-proposed standards.
特定のプロトコルのDODの機能的な必要性の声明を強要してください、そして、NBS-提案された標準の機能、特徴、およびサービスの基礎を形成してください。
To further the development of commercial products that implement standards, the NBS gives priority to the needs of U.S. computer manufacturers who wish to market their products nationally and internationally, not just to the U.S. government. The NBS participates, therefore, in national and international voluntary standards organizations toward the development of an international consensus based on United States needs. Specifications, formal description techniques, testing methodologies, and test results developed by the NBS are used to further the international standardization process.
規格を実装する商品の開発を促進するために、NBSは米国政府だけではなく、彼らの製品を全国的に、そして国際的に売り出したがっている米国のコンピュータメーカーの必要性を最優先させます。 したがって、NBSは合衆国の必要性に基づく国際合意の開発に向かった国家的、そして、国際的な自主基準組織に参加します。 仕様、形式的記述のテクニック、方法論をテストして、およびNBSによって見いだされた試験の成績は、国際標準化プロセスを促進するのに使用されます。
Development of Testing Methodologies
テスト方法論の開発
The National Bureau of Standards has laboratory activities where prototypes of draft protocol standards are implemented and tested in a variety of communications environments supporting different applications on different kinds and sizes of computers. Communications environments include, for example, global networks, local networks, and office system networks. Applications may, for example, include file transfer or message processing. The primary purposes are to advance the state of the art in measurement methodologies for advanced computer networking technologies and determine protocol implementation correctness and performance.
草稿プロトコル標準のプロトタイプがさまざまなコミュニケーション環境で実装されて、テストされるところに規格基準局は、コンピュータの異種とサイズで異なったアプリケーションをサポートしながら、実験室活動を持っています。 コミュニケーション環境は例えば、グローバルなネットワーク、企業内情報通信網、およびオフィス・システムネットワークを含んでいます。 例えば、アプリケーションはファイル転送かメッセージ処理を含むかもしれません。 プライマリ目的は、高度なコンピュータネットワーク・テクノロジーのために測定方法論における到達技術水準を進めて、プロトコル実装の正当性と性能を決定することです。
The NBS views testing as a cooperative research effort and works with other agencies, private-sector companies, and other countries in the development of methodologies. At this time, this cooperation involves five network laboratories in other countries and over twenty computer manufacturers.
NBSは方法論の開発に共同研究取り組みであるとテストをみなして、他の政府機関、民間部門会社、および他国と共に取り組みます。 このとき、この協力は他国における5つのネットワーク実験室と20以上のコンピュータメーカーにかかわります。
The testing methodologies developed at the NBS are well documented, and the testing tools themselves are developed with the objective of portability in mind. They are made available to many organizations engaged in protocol development and implementations.
NBSで開発されたテスト方法論はよく記録されます、そして、テストツール自体は念頭で移植性の目的で開発されます。 プロトコル開発と実装に従事している多くの組織がそれらを入手します。
Assisting Users and Manufacturers
ユーザとメーカーを補助します。
The NBS works directly with government agencies to help them use evolving network technologies effectively and apply international and government networking standards properly. When large amounts of assistance are required, the NBS provides it under contract.
NBSは直接それらが有効に発展ネットワーク技術を使用するのを助けて、国際的に申し込む政府機関と政府ネットワーク規格で適切に働いています。 多量の支援が必要であるときに、NBSは契約の下にそれを提供します。
Assistance to industry is provided through cooperative research efforts and by the availability of NBS testing tools, industry wide workshops, and cooperative demonstration projects. At this time, the NBS is working directly with over twenty computer manufacturers in the implementation of network protocol standards.
産業に対する支援は共同研究取り組み、NBSテストツールの有用性、産業の広いワークショップ、および協力的なデモンストレーションプロジェクトによって提供されます。 このとき、NBSは直接20以上のコンピュータメーカーと共にネットワークプロトコル標準の実装で働いています。
National Research Council [Page 4] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[4ページ]RFC942 1985年2月のレポート輸送
Consistent with overall goals, NBS standards developments, research in testing methodologies, and technical assistance are characterized by direct industry and government cooperation and mutual support.
全体的な目的と一致しています、NBS規格開発、テスト方法論における研究、および技術支援はダイレクト産業、政府協力、および相互援助で特徴付けられます。
DOD OBJECTIVES
DOD目的
The DOD has unique needs that could be affected by the Transport and Internet Protocol layers. Although all data networks must have some of these capabilities, the DOD's needs for operational readiness, mobilization, and war-fighting capabilities are extreme. These needs include the following:
DODには、Transportで影響を受けることができたユニークな必要性とインターネットプロトコル層があります。 すべてのデータ網には、これらの能力のいくつかがなければなりませんが、DODの操作上の準備、動員、および戦争で戦う能力の必要性は極端です。 これらの必要性は以下を含んでいます:
Survivability--Some networks must function, albeit at reduced performance, after many nodes and links have been destroyed.
生存性--ネットワークの中にはそれにしても、多くのノードとリンクが破壊された後に減少している性能で機能するものもなければなりません。
Security--Traffic patterns and data must be selectively protected through encryption, access control, auditing, and routing.
セキュリティ--暗号化、アクセスコントロール、監査、およびルーティングで選択的にトラフィック・パターンとデータを保護しなければなりません。
Precedence--Systems should adjust the quality ot service on the basis of priority of use; this includes a capability to preempt services in cases of very high priority.
先行--システムは使用の優先権に基づいて上質のotサービスを調整するはずです。 これは非常に高い優先度に関するケースにサービスを先取りする能力を含んでいます。
Robustness--The system must not fail or suffer much loss of capability because of unpredicted situations, unexpected loads, or misuse. An international crisis is the strongest test of robustness, since the system must operate immediately and with virtually full performance when an international situation flares up unexpectedly.
丈夫さ--システムは、非予測された状況、予期していなかった負荷、または誤用のために能力の多くの損失を失敗してはいけませんし、また受けてはいけません。 国際的な危機は丈夫さの最も強いテストです、国際情勢が不意に燃え上がるとシステムがすぐにと実際には完全な性能で作動しなければならないので。
Availability--Elements of the system needed for operational readiness or fighting must be continuously available.
有用性--操作上の準備か戦いに必要であるシステムのElementsは絶え間なく手があいていなければなりません。
Interoperability--Different elements of the Department must be able to "talk" to one another, often in unpredicted ways between parties that had not planned to interoperate.
相互運用性--部の異なった要素はお互いに「話すことができなければなりません」、しばしば共同利用するのを計画していなかったパーティーの間の非予測された方法で。
These operational needs reflect themselves into five technical or managerial needs:
これらの操作上の必要性は自分たちで技術的であるか経営者の必要性を5に反映します:
1. Functional and operational specifications (that is, will the
protocol designs meet the operational needs?);
1. 機能的で操作上の仕様(すなわち、プロトコルデザインは操作上の需要を満たすでしょうか?、)。
2. Maximum interoperability;
2. 最大限のインターオペラビリティ。
3. Minimum procurement, development, and support costs;
3. 最小の調達、開発、およびサポートコスト。
4. Ease of transition to new protocols; and
4. 新しいプロトコルへの変遷の容易さ。 そして
5. Manageability and responsiveness to changing DOD requirements.
5. DOD要件を変えることへの管理可能性と反応性。
These are the criteria against which DOD options for using the ISO transport and internet protocols should be evaluated.
これらはISO輸送とインターネットプロトコルを使用するためのDODオプションが評価されるべきである評価基準です。
National Research Council [Page 5] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[5ページ]RFC942 1985年2月のレポート輸送
Performance and Functionality
パフォーマンスと機能性
The performance and functionality of the protocols must provide for the many unique operational needs of the DOD. The following paragraphs discuss in some detail both these needs and the ways they can impact protocol design.
プロトコルの性能と機能性はDODの多くのユニークな操作上の必要性に備えなければなりません。 以下のパラグラフは何らかの詳細にこれらの必要性とプロトコルデザインに影響を与えることができる方法の両方について議論します。
Survivability includes protecting assets, hiding them, and duplicating them for redundancy. It also includes endurance--the assurance that those assets that do survive can continue to perform in a battle environment for as long as needed (generally months rather than hours); restoral--the ability to restore some of the damaged assets to operating status; and reconstitution--the ability to integrate fragmented assets into a surviving and enduring network.
それらを隠して、冗長のためにそれらをコピーして、生存性は、資産を保護するのを含んでいます。 また、それは辛抱を含んでいます--存続するそれらの資産が、必要である間、戦い環境で働き続けることができるという保証(一般に何時間ものむしろ何カ月か) restoral--破損している資産のいくつかを操作状態に回復する能力。 そして、再構成--生き残っていて永続的なネットワークと断片化している資産を統合する能力。
The DOD feels that an important reason for adopting international and commercial standards is that under cases of very widespread damage to its own communications networks, it would be able to support DOD functions by using those civil communications that survive. This would require interoperability up to the network layer, but neither TCP nor TP-4 would be needed. The committee has not considered the extent to which such increased interoperability would increase survivability through better restoral and reconstitution.
DODは、国際的で商業の規格を採用する重要な理由がそれ自身の通信網への非常に広範囲の損害の場合の下ではDODに存続するそれらの民間コミュニケーションを使用することによって機能をサポートできるだろうということであると感じます。 これは相互運用性をネットワーク層まで必要とするでしょうが、TCPもTP-4も必要でないでしょう。 委員会は、そのようなものが相互運用性を増強した範囲が、より良いrestoralと再構成を通して生存性を増強すると考えていません。
Availability is an indication of how reliable the system and its components are and how quickly they can be repaired after a failure. Availability is also a function of how badly the system has been damaged. The DDN objective for system availability in peacetime varies according to whether subscribers have access to l or 2 nodes of the DDN. For subscribers having access to only one node of the DDN, the objective is that the system be available 99.3 percent of the time, that is, the system will be unavailable for no more than 60 hours per year. For subscribers having access to 2 nodes, the objective is that the system be available 99.99 percent of the time, that is, the system will be unavailable for no more than one hour per year.
有用性はシステムとそのコンポーネントがどれくらい高信頼であるか、そして、失敗の後にどれくらいすぐにそれらは修理できるかしるしです。 また、有用性はシステムがどれくらいひどく破損したかに関する機能です。 加入者がDDNのlか2つのノードに近づく手段を持っているかどうかに従って、平時のシステム稼働率のためのDDN目的は異なります。 DDNの1つのノードだけに近づく手段を持っている加入者にとって目的がシステムが99.3パーセントの割合で利用可能であるということである、すなわち、システムは1年あたり60時間未満を入手できなくなるでしょう。 2つのノードに近づく手段を持っている加入者にとって目的がシステムが99.99パーセントの割合で利用可能であるということである、すなわち、システムは1年あたり1時間未満を入手できなくなるでしょう。
Robustness is a measure of how well the system will operate successfully in face of the unexpected. Robustness attempts to avoid or minimize system degradation because of user errors, operator errors, unusual load patterns, inadequate interface specifications, and so forth. A well designed and tested system will limit the damage caused by incorrect or unspecified inputs to affect only the performance of the specific function that is requested. Since protocols are very complex and can be in very many "states", robustness is an important consideration in evaluating and implementing protocols.
丈夫さはシステムが予期していなさの表面でどれくらいよく首尾よく作動するかに関する測定です。 丈夫さは、ユーザ誤り、オペレータエラー、珍しい負荷パターン、不十分なインターフェース仕様などのためにシステム退行を避けるか、または最小にするのを試みます。 よく設計されて、テストされたシステムは、要求されている具体的な機能の性能だけに影響するように不正確であるか不特定の入力でもたらされた損害を制限するでしょう。 プロトコルは非常に複雑であり、非常に多くの「州」にあることができるので、丈夫さはプロトコルを評価して、実装することにおいて重要な考慮すべき事柄です。
Security attempts to limit the unauthorized user from gaining both the information communicated in the system and the patterns of traffic throughout the system. Security also attempts to prevent spoofing of the system: an agent attempting to appear as a legitimate user, insert false traffic, or deny services to users by repeatedly seeking system services.
セキュリティは、システムで伝えられた情報とトラフィックのパターンの両方をシステムに獲得するので権限のないユーザを制限するのを試みます。 また、セキュリティは、システムをだますのを防ぐのを試みます: エージェントが、正統のユーザとして現れるのを試みて、誤ったトラフィックを挿入するか、または繰り返してシステムサービスを求めることによって、ユーザに対するサービスを否定してください。
National Research Council [Page 6] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[6ページ]RFC942 1985年2月のレポート輸送
Finally, Security is also concerned with making sure that electronic measures cannot seriously degrade the system, confuse its performance, or cause loss of security in other ways.
また、最終的に、電子測定が他の方法で真剣にシステムを下げるか、性能を混乱させるか、またはセキュリティの損失をもたらすことができないことを確実にするのにSecurityを心配させます。
Encryption of communication links is a relatively straightforward element of security. It is widely used, fairly well understood, constantly undergoing improvement, and becoming less expensive. On the other hand, computer network security is a much newer field and considerably more complex. The ability of computer network protocols to provide security is a very critical issue. In the past decade much has been learned about vulnerability of computer operating systems, development of trusted systems, different levels of protection, means of proving that security has been achieved, and ways to achieve multilevel systems or a compartmented mode. This is a dynamic field, however, and new experience and analysis will probably place new requirements on network protocols.
通信リンクの暗号化はセキュリティの比較的簡単な要素です。 公正によく理解されて、絶えず改良を受けて、より高価でなくなって、それは広く使用されます。 他方では、コンピュータネットワークセキュリティは、はるかに新しい分野であってかなり複雑です。 コンピュータ・ネットワーク・プロトコルがセキュリティを提供する能力は非常に重大な問題です。 過去の10年間で、多くがコンピュータオペレーティングシステムの脆弱性、信じられたシステムの開発、異なったレベルの保護、セキュリティが達成されたと立証する手段、および多レベルシステムかcompartmentedモードを達成する方法に関して学習されました。 しかしながら、これはダイナミックな分野です、そして、新しい経験と分析はたぶん新しい要件をネットワーク・プロトコルに置くでしょう。
Crisis-performance needs are a form of global robustness. The nature of a national security crisis is that it is fraught with the unexpected. Unusual patterns of communication traffic emerge. Previously unstressed capabilities become critical to national leaders. Individuals and organizations that had not been communicating must suddenly have close, secure, and reliable communications. Many users need information that they are not sure exists, and if it does, they do not know where it is or how to get it. The development of widely deployed, interoperable computer networks can provide important new capabilities for a crisis, particularly if there is some investment in preplanning, including the higher-level protocols that facilitate interoperability. Presidential directives call for this. This will become a major factor in DOD's need for interoperability with other federal computer networks. The DOD, as one of the most affected parties, has good reason to be concerned that its network protocols will stand the tests of a crisis.
危機性能の必要性はグローバルな丈夫さのフォームです。 国家安全保障危機の本質はそれが予期していなさについて悲惨であるということです。 コミュニケーショントラフィックの異常パターンは現れます。 以前、強調されていない能力は国家のリーダーにとって重要になります。 伝えていなかった個人と組織は突然近くて、安全で、信頼できるコミュニケーションを持たなければなりません。 多くのユーザが彼らが存在するのを確信していない情報を必要とします、そして、そうするなら、彼らはそれがどこにあるか、そして、またはどうそれを得るかを知りません。 広く配布していて、共同利用できるコンピュータネットワークの開発は重要な新しい能力を危機に提供できます、特に前計画への何らかの投資があれば、相互運用性を容易にする上位レベル・プロトコルを含んでいて。 大統領の指令はこれを求めます。 これは他の連邦のコンピュータネットワークでDODの相互運用性の必要性で重要な要因になるでしょう。 DODには、最も影響を受けるパーティーのひとりとして、ネットワーク・プロトコルが危機のテストに耐えることを心配させるべき十分な理由があります。
In addition, there are performance and functionality features that are measures of the capability of the network when it is not damaged or stressed by unexpected situations. Performance includes quantifiable measures such as time delays, transmission integrity, data rates and efficiency, throughput, numbers of users, and other features well understood in computer networks. Equally important is the extent of functionality: What jobs will the network do for the user?
さらに、それが予期せぬ状況によって破損もしませんし、圧力を加えられもしないとき、ネットワークの能力の測定である性能と機能性機能があります。 パフォーマンスは時間遅れなどの定量化可能な測定を含んでいます、とトランスミッション保全、データ信号速度、効率、スループット、ユーザの数、および他の特徴はコンピュータネットワークでよく理解していました。 等しく重要であるのは、機能性の範囲です: ネットワークはユーザのためにどんな仕事をするでしょうか?
The DDN has established some performance objectives such as end-to-end delays for high-precedence and routine traffic, the probability of undetected errors, and the probability of misdelivered packets. Such objectives are important to engineer a system soundly. The DOD must place greater emphasis on more complex performance issues such as the efficiency with which protocols process and communicate data.
DDNは高い先行と通常のトラフィックのための終わりから終わりへの遅れなどのいくつかのパフォーマンス目標、非検出された誤りの確率、およびmisdeliveredパケットの確率を確立しました。 そのような目的は、健全にシステムを設計するために重要です。 DODはプロトコルとデータを処理して、伝える効率などの、より複雑な性能問題への、より大きい強調を置かなければなりません。
The DOD has stated a need for an effective and robust system for precedence and preemption. Precedence refers to the ability of the system to adaptively allocate network resources so that the network performance is related to the importance of the function being
DODは先行と先取りの有効で強健なシステムの必要性を述べました。 先行はネットワーク性能が機能の重要性に関連するようにありながら適応型にネットワーク資源を割り当てるシステムの能力について言及します。
National Research Council [Page 7] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[7ページ]RFC942 1985年2月のレポート輸送
performed. Preemption refers to the ability of the system to remove users (at least temporarily) until the needs of the high-priority user are satisfied. The ARPANET environment in which the protocols were developed did not emphasize these capabilities, and the current MILNET does not function as effectively in this regard as DOD voice networks.
実行にされる。 先取りは高優先度ユーザの需要が満たされるまでシステムがユーザ(少なくとも一時)を外す能力について言及します。 プロトコルが開発されたアルパネット環境はこれらの能力を強調しませんでした、そして、DODがネットワークを声に出すとき、現在のMILNETは同じくらい有効にこの点で機能しません。
The DOD has also stated a need for connectionless communications and a broadcast mode. In the majority of network protocols, when two of more parties communicate, virtual circuits are established between the communicating parties. (For reliability, additional virtual circuits may be established to provide an in place backup.) DOD needs a connectionless mode where the message can be transmitted to one or more parties without the virtual circuit in order to enhance survivability; provide a broadcast capability (one sender to many receivers); and handle imagery, sensor data, and speech traffic quickly and efficiently.
また、DODはコネクションレスなコミュニケーションと放送モードの必要性を述べました。 より多くの2人のパーティーが交信するとき、ネットワーク・プロトコルの大部分に、仮想の回路は交信パーティーの間で確立されます。 (信頼性において、追加仮想の回路が提供するために確立されるかもしれない、適所にある、バックアップ)。 DODは生存性を高めるために仮想の回路なしで1回以上のパーティーにメッセージを送ることができるコネクションレスなモードを必要とします。 放送能力(多くの受信機への1人の送付者)を提供してください。 そして、すぐに、効率的にイメージ、センサデータ、およびスピーチトラフィックを扱ってください。
If intermediate nodes are destroyed or become otherwise unavailable, there is still a chance that the data can be sent via alternate paths. The broadcast capability is particularly important in tactical situations where many parties must be informed almost simultaneously and where the available assets may be disappearing and appearing dynamically. The Department of Defense requires an internetting capability whereby different autonomous networks of users can communicate with each other.
中間的ノードが破壊されるか、またはそうでなければ、入手できなくなるなら、代替パスを通してデータを送ることができるという見込みがまだあります。 放送能力は利用可能資産が多くのパーティーがほとんど同時に、知識があるに違いなくて、見えなくなって、ダイナミックに現れることであるかもしれない戦況で特に重要です。 国防総省はユーザの異なった自治のネットワークが互いにコミュニケートできるinternetting能力を必要とします。
Interoperability
相互運用性
Presidential and DOD directives place a high priority on interoperability, which is related to the internetworking previously discussed.
大統領とDOD指示は高い優先度を相互運用性に置きます。相互運用性は以前に議論したインターネットワーキングに関連します。
Interoperability is primarily important at two levels: network access and applications. To achieve interoperability at the level of network access,users of backbone communications nets must utilize the same lower-level protocols that are utilized by the network. Generally these protocols are layers 1, 2, and 3, up to and including part of the IP layer. In other words, interoperability for network access does not depend on either implementation of the transport layer (TP-4 or TCP) or of all of the internet (IP) layer. The primary advantages of network access interoperability are twofold:
相互運用性は2つのレベルで主として重要です: アクセスとアプリケーションをネットワークでつないでください。 ネットワークアクセスのレベルで相互運用性を達成するために、バックボーンコミュニケーションネットのユーザはネットワークによって利用されるのと同じ低レベルプロトコルを利用しなければなりません。 一般にこれらのプロトコルはIP層の一部を含めた層1、2、および3です。 言い換えれば、ネットワークアクセスのための相互運用性はトランスポート層(TP-4かTCP)かインターネット(IP)層のすべてのどちらの実装にもよりません。 ネットワークアクセス相互運用性のプライマリ利点は二つです:
1. Significant economies of scale are possible since the various
users can share the resources of the backbone network including
hardware, software, and development and support costs.
1. 様々なユーザがハードウェア、ソフトウェア、および開発を含むバックボーンネットワークに関するリソースを共有して、コストをサポートすることができるので、重要な規模の経済は可能です。
2. Network survivability for all users can be increased
significantly since the network has high redundancy and, as the
threat increases, the redundancy can also be increased.
2. ネットワークには高い冗長があるので、すべてのユーザのためのネットワークの生存性をかなり増強できます、そして、また、脅威が増加するのに従って、冗長を増強できます。
Interoperability at the applications layer allows compatible users at different nodes to talk to each other, that is, to share their data,
アプリケーション層の相互運用性で、異なったノードのコンパチブルユーザはすなわち、互い、シェアとそれらのデータについて話すことができます。
National Research Council [Page 8] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[8ページ]RFC942 1985年2月のレポート輸送
support each other, and thereby coordinate and strengthen the management of forces and other assets. Interoperability at the applications layer can be achieved through the use of specialized software that performs those functions of higher-layer protocols (such as TCP or TP-4, file transfer, and virtual terminal) that are needed by the particular application. If some of the higher-layer transport and utility protocols have been developed for particular hosts or work stations, their use greatly reduces development, integration, and support costs, although with a potential sacrifice of performance. Interoperability at the applications level, that is, full functional interoperability, is important to specialized communities of users such as the logistics, command and control, or research and development communities. As these different communities utilize the DDN, they have the advantages of shared network resources. Within each community there is full functional interoperability but generally there is much less need for one community to have functional interoperability with members of another community.
互いをサポートしてください、その結果、力と他の資産の経営を調整して、強化してください。 特定用途で必要である上位層プロトコル(TCPやTP-4や、ファイル転送や、仮想端末などの)のそれらの機能を実行する専門化しているソフトウェアの使用でアプリケーション層の相互運用性を達成できます。 特定のホストかワークステーションのために、より高い層の輸送とユーティリティプロトコルのいくつかを開発してあるなら、彼らの使用は開発、統合、およびサポートコストを大いに削減します、性能の潜在的犠牲をもって。 アプリケーションレベルにおける相互運用性(すなわち、完全な機能的な相互運用性)はロジスティクス、指揮統制、または研究開発共同体などのユーザの専門化している共同体に重要です。 これらの異なった共同体がDDNを利用するとき、それらには、共用回線網リソースの利点があります。 中では、まして、完全な機能的な相互運用性であるのにもかかわらずの、一般に、ある各共同体が1つの共同体が別の共同体のメンバーがいる機能的な相互運用性を必要とします。
The implementation of TCP or TP-4 within network users, but without the implementation of higher-level protocols and application interoperability, is not generally an immediate step in increasing interoperability. It does have these immediate advantages:
TCPかTP-4の実装は中でユーザをネットワークでつなぎますが、上位レベル・プロトコルとアプリケーション相互運用性の実装がなければ、一般に増加における緊急の措置は相互運用性ではありませんか? それには、これらの即座の利点があります:
It represents an important step in investing in longer-term interoperability.
それは、より長い期間相互運用性に投資する際に重要なステップを表します。
It generally represents an economical near-term investment on which communities of interest can build their own applications.
一般に、それは興味がある共同体がそれら自身のアプリケーションを組立てることができる経済的な短期間投資を表します。
It facilitates the development of devices for general network use such as Terminal Access Controllers (TACs).
それはTerminal Access Controllers(TACs)などの一般的なネットワーク使用のためのデバイスの開発を容易にします。
Interoperability at the applications level will become increasingly important among the following communities: Worldwide Military Command and Control Systems, including systems of subordinate commands; Department of Defense Intelligence Information Systems; U.S. tactical force headquarters (fixed and mobile); NATO force headquarters; other U.S. intelligence agencies; the State Department; and the Federal Bureau of Investigation and other security agencies.
アプリケーションレベルにおける相互運用性は以下の共同体でますます重要になるでしょう: 下位のコマンドのシステムを含む世界的なMilitary Commandと制御システム部会。 国防総省知性情報システム。 米国の戦術の力の本部(固定されてモバイルの)。 NATO力の本部。 他の米国諜報機関代理店。 国務省。 連邦捜査局と他の警備機関。
Although interoperability of applications within the DOD has the highest priority, it is clear that government wide and international interoperability will be an objective with increasing priority. The NATO situation is especially important (6).
DODの中のアプリケーションの相互運用性には、最優先がありますが、その政府の広くて国際的な相互運用性が増加する優先権で目的になるのは、明確です。 NATO状況は特に重要な(6)です。
----- (6) Europe has been a major force in the development of ISO standards. Consistent with this is a NATO commitment to adopt ISO standards so long as they meet military requirements.
----- (6) ヨーロッパはISO規格の開発で主要な力です。 これと一致しているのは、彼らが軍事の必要条件を満たす限り、ISO規格を採用するNATO委任です。
National Research Council [Page 9] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[9ページ]RFC942 1985年2月のレポート輸送
In a somewhat longer time period, DOD will want applications interoperability with many commercial information services. As interoperable computer networks become more common, processing and data services will burgeon in the marketplace. These will include specialized data bases and analytic capabilities that all large organizations will need in order to be up-to-date and competitive.
いくらか長い期間に、DODは多くの商用情報サービスがあるアプリケーション相互運用性が欲しくなるでしょう。 共同利用できるコンピュータネットワークが、より一般的になるとき、処理とデータサービスは市場で急速に成長するでしょう。 これらはすべての大きな組織が最新であって、競争力があるようになるように必要とする専門化しているデータベースと分析的な能力を含むでしょう。
With regard to interoperability at the network level, DOD will want to be able to utilize commercially available networks for both survivability and operational effectiveness and economy. In the case of a major war in Europe, for example, the United States would want to be able to use surviving PTTs (Postal, Telegraphy, and Telephony Ministries) for restoral and reconstitution. During peacetime there will be cases where special DOD needs can be best satisfied with commercially available capabilities.
ネットワークレベルにおける相互運用性に関して、DODは生存性と操作上の有効性と経済の両方に商業的に利用可能なネットワークを利用できるようになりたくなるでしょう。 例えば、ヨーロッパの主要な戦争の場合では、合衆国が生き残っているPTTを使用できるようになりたがっているだろう、(郵便である、Telegraphy、Telephony Ministries) restoralと再構成のために。 平時の間、ケースが商業的に利用可能な能力に特別なDOD需要を特に満たすことができるところにあるでしょう。
As technology continues to provide less expensive, smaller, and more reliable data processing equipment, computer networks will become increasingly prevalent at lower levels of the tactical forces--land, air, and sea. It will be important that these tactical networks be capable of interoperability with each other (for example, air support of ground forces) and with headquarters. It is likely that the tactical network will need a network architecture and protocols that are different from the ARPA-\and ISO-derived protocols. If so, the developments will place requirements on the higher-level DOD protocols.
技術が、それほど高価でなくて、より小さくて、より信頼できるデータ処理装置を提供し続けているのに従って、コンピュータネットワークはますます戦術の力の下のレベルで一般的になるでしょう--陸、空気、および海。 これらの戦術のネットワークは互い(例えば、陸軍のサポートを放送する)と本部で相互運用性ができるのは、重要でしょう。 そして、ARPA-\、それが戦術のネットワークがネットワークアーキテクチャと異なったプロトコルが必要でありそうである、ISOによって派生させられたプロトコル。 そうだとすれば、開発は、よりハイレベルのDODプロトコルに要件を置くでしょう。
If the DOD chooses to move from TCP to TP-4, this can be done in phases for different communities of interest and subnetworks. In this way if there is difficulty in converting one subnet, the rest of the network need not be degraded. Also the different subnets will be able to make the transition at the most suitable time in terms of cost, risk, and the need to interoperate with other subnets. As a result if DOD uses TP-4 for some new nets or major upgrade of existing nets, this will generally not reduce interoperability in the near term unless interoperability of applications is needed between two communities. In this case specific interoperability needs may be satisfied with specialized gateways for mail or data exchange.
DODが、TCPからTP-4まで移行するのを選ぶなら、興味がある異なった共同体とサブネットワークのためにフェーズでこれができます。 このように、1つのサブネットを変換することにおける苦労があれば、ネットワークの残りは下がる必要はありません。 また、異なったサブネットは大部分の変遷を費用に関する適当な時間、リスク、および他のサブネットで共同利用する必要性にすることができるでしょう。 その結果、DODがいくつかの新しいネットにTP-4を使用するか、または存在する大きな更新が網状になって、近いうちにアプリケーションの相互運用性は2つの共同体の間で必要でない場合、一般に、これが相互運用性を減少させないでしょう。 この場合、特定の相互運用性需要はメールかデータ交換のための専門化しているゲートウェイに満たされるかもしれません。
The DOD points out that it desires all networks to be interoperable since it is not possible to predict when one community will need to communicate with another or use the resources of the other. As previously indicated, however, unexpected needs for full functional interoperability can only be met when appropriate higher-layer software is developed.
DODは、1つの共同体が、いつ別のものとコミュニケートするか、またはもう片方に関するリソースを使用する必要であるかを予測するのが可能でなくて、すべてのネットワークが共同利用できることを望んでいると指摘します。 しかしながら、以前に示されるように、適切なより高い層のソフトウェアが開発されているときだけ、完全な機能的な相互運用性の予期していなかった需要を満たすことができます。
Minimize Costs
コストを最小にしてください。
The Department of Defense seeks to minimize costs of development, procurement, transition (if it decides to move to ISO protocols), and support. Generally the objective is to limit life-cycle costs, that is, the total costs over a 5-to-8-year period with future costs suitably discounted (10 to 20 percent per year).
国防総省は開発、調達、変遷(ISOプロトコルに移行すると決めるなら)、およびサポートのコストを最小にしようとします。 一般に目的はライフサイクルコスト(すなわち、将来のコストが適当に割り引かれている5〜8年間の期間(1年あたり10〜20パーセント)にわたる総コスト)を制限することです。
National Research Council [Page 10] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[10ページ]RFC942 1985年2月のレポート輸送
The Department of Defense has already made a heavy investment in protocols, and the investment has paid off in the success of current protocols operational in many networks. On the other hand, the DOD acknowledges the potential advantages of using the ISO protocols if made available as commercially supported products. Development costs for these protocols can be small since their development cost is amortized by the commercial vendor over a larger market. Support costs for these protocols (including minor modifications, integration into other products, documentation, and training) are also significantly reduced because of vendor-supplied services. These cost factors are further discussed in Section IX in terms of the three options presented in Section VIII.
国防総省は既にプロトコルへの重い投資をしました、そして、投資は多くのネットワークにおける操作上の現在のプロトコルの成功でうまく行きました。 他方では、DODは製品であると商業的にサポートされるように利用可能に作られるならISOプロトコルを使用する潜在的利点を承認します。 それらの開発費が、より大きい市場にわたって商業ベンダーによって清算されるので、これらのプロトコルのための開発コストはわずかである場合があります。 また、これらのプロトコル(小さい方の変更、他の製品、ドキュメンテーション、およびトレーニングへの統合を含んでいる)のためのサポートコストはベンダーによって供給されたサービスのためにかなり削減されます。 セクションIXでセクションVIIIに提示された3つのオプションでこれらのコスト要因についてさらに議論します。
Ease of Transition and Manageability
変遷と管理可能性の容易さ
Networks must be manageable and capable of growth and improvement. The Department of Defense generally makes the fastest progress in developing complex information systems if it evolves these capabilities while working in concert with the users and the acquiring agencies. In this light, the following factors are important:
ネットワークは、成長と改良が処理しやすくて、できなければなりません。 一般に、国防総省はユーザと協力して働いている間、これらの能力を発展するなら複雑な情報システムを開発するのにおいて最も速い進歩と取得代理店を作ります。 この光の中では、以下の要素は重要です:
Minimal interruption of current service--For most DOD networks it is essential that they operate continuously. If there is to be transition to new protocol services (whether based on current DOD versions or ISO), it is important that these transitions be planned, designed, and pretested so that the transition will be nondisruptive.
当期の勤務の最小量の中断--ほとんどのDODネットワークにおいて、絶え間なく作動するのは不可欠です。 新しいプロトコルサービスへの変遷があれば(現在のDODバージョンかISOに基づいているか否かに関係なく)、これらの変遷が変遷がnondisruptiveになるように計画されて、設計されていて、プレテストされるのは、重要です。
Verifiability--It is essential to have a testing capability where new protocol implementations can be thoroughly tested to ensure that they will interoperate, have full functionality specified, do not contain errors, are robust, and meet quantitative performance needs. The National Bureau of Standards has established such a capability, and it is being used to verify a number of TP-4 implementations, including those demonstrated at the National Computer Conference in July 1984. An IP-testing capability is being added. The Department of Defense is planning a similar protocol test facility for TCP, but work is just getting underway. If the DOD plans to migrate promptly to TP-4, there is a question whether this investment is warranted.
検証可能性--テスト能力を持っているのは彼らが共同利用するのを確実にして、完全な機能性を指定させて、誤りを含まないで、強健であり、量的な性能需要を満たすために新しいプロトコル実装を徹底的にテストできるところで不可欠です。 規格基準局はそのような能力を確立しました、そして、それは多くのTP-4実装について確かめるのに使用されています、1984年7月にNationalコンピュータコンファレンスで示されたものを含んでいて。 IP-テスト能力は加えられています。 国防総省はTCPのために同様のプロトコルテスト機能を設計していますが、仕事はただ始まることです。 DODが、即座にTP-4にわたるのを計画しているなら、この投資が保証されるかどうかという質問があります。
Compatibility with higher protocols--As the transport and lower-protocol layers evolve, it is essential that they maintain full compatibility with higher-layer protocols. This is particularly important for the DOD because it will increasingly have inter-operability at the applications level.
より高いプロトコルとの互換性--輸送と低級プロトコル層が発展するので、彼らが上位層プロトコルとの完全な互換性を維持するのは、不可欠です。 ますますアプリケーションレベルで相互運用性を持つので、DODには、これは特に重要です。
Responsiveness to evolving DOD needs--Current DOD needs will change or new needs may arise. It is very likely, for example, that subtle performance problems may be discovered in a protocol that are unique to the strenuous DOD-operating environment and that could have serious operational consequences. If the DOD is using commercial protocols products based upon international standards, the DOD will need two commitments when critical deficiencies are discovered. It will need a commitment from the manufacturer that critical problems
DODが必要とする発展への反応性--DODが必要とする電流が変化するだろうか、または新たな必要性は起こるかもしれません。 例えば、微妙な性能問題は精力的なDOD-操作環境にユニークであり、重大な操作上の結果を持つことができたプロトコルで非常に発見されそうです。 重要な欠乏が発見されるとき、DODが世界規格に基づく商業プロトコル製品を使用していると、DODは2つの委任を必要とするでしょう。 それはメーカーからの必要性a委任にその重大問題を望んでいます。
National Research Council [Page 11] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[11ページ]RFC942 1985年2月のレポート輸送
will be promptly fixed and a commitment from the NBS that it will move quickly to change federal standards and seek changes in international standards.
即座に修理されて、それが連邦の規格を変えて、探すためにすばやく動かすNBSからの委任は世界規格で変化します。
Minimal risks--The DOD needs are so large and important, it cannot afford to take otherwise avoidable risks.
最小量のリスク--DODの必要性がとても大きくて、重要である、それにはそうでなければ、回避可能な危険を冒す余裕がありません。
Maintenance of manageability--The DDN is new and is using a new approach after the cancellation of AUTODIN II (7). There are pressing operational needs and many impatient users. If the DOD delays in moving to ISO protocols and later decides to do so, the costs and disruption will be large. On the other hand, moving now to ISO will be less disruptive.
管理可能性のメインテナンス--DDNは新しく、AUTODIN II(7)のキャンセルの後に新しいアプローチを使用しています。 操作上の必要性を押して、多くのせっかちなユーザがいます。 DODが、ISOプロトコルに移行する際に延着して、後でそうすると決めると、コストと分裂は大きくなるでしょう。 他方では、現在ISOに移行するのはそれほど破壊的でないでしょう。
----- (7) AUTODIN II was a program to develop a data communications system for the DOD. The program envisioned relatively few large packet switches. It was cancelled in 1982 in favor of ARPANET-derived designs because of considerations of security, architecture, survivability, and cost.
----- (7) AUTODIN IIはDODのためにデータ通信システムを開発するプログラムでした。 プログラムは比較的わずかな大きいパケット交換機しか思い描きませんでした。 それは1982年にセキュリティ、アーキテクチャ、生存性、および費用の問題によるアルパネットで派生しているデザインを支持して取り消されました。
National Research Council [Page 12] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[12ページ]RFC942 1985年2月のレポート輸送
III. COMPARISON OF DOD AND ISO PROTOCOLS
III。 DODとISOプロトコルの比較
This section presents a general description of the major functional differences between the ISO and DOD protocol sets at the transport and network layers and then discusses particular aspects of the protocols: performance, security, and risk.
このセクションは、ISOとDODの間の主要な機能的な違いの概説に輸送とネットワーク層におけるプロトコルセットを寄贈して、次に、プロトコルの特定の局面について論じます: 性能、セキュリティ、およびリスク。
COMPARISON OF DOD AND ISO TRANSPORT LAYERS
DODとISOトランスポート層の比較
Differences between the Defense Department's TCP protocol and the International Standards Organization's TP-4 protocol are described in terms of items visible to users of the protocol. Internal differences in mechanism that have no effect on the service seen by the user are not considered. A second much simpler protocol, the User Datagram Protocol (UDP), providing datagram or connectionless service at the transport layer is also briefly considered.
国防総省のTCPプロトコルと国際Standards OrganizationのTP-4プロトコルの違いはプロトコルのユーザにとって、目に見える項目で説明されます。 ユーザによって見られたサービスのときに効き目がないメカニズムの内部の違いは考えられません。 2番目のはるかに簡単なプロトコル、ユーザー・データグラム・プロトコル(UDP)、また、トランスポート層でデータグラムかコネクションレス型サービスを提供するのは簡潔に考えられます。
In summary, the services provided by TCP and TP-4 are functionally quite similar. Several functions, however, including data transfer interface, flow control, connection establishment binding, and out-of-band signals are provided in significantly different ways by the two protocols. Neither seems intrinsically superior, but some effort would be required to convert a higher-level protocol using TCP to make use of TP-4. The exact amount of work needed will vary with the nature of the higher-level protocol implementations and the operating systems in which they are embedded. A programmer experienced with the higher-level protocols would require about six months to design, implement, and test modifications of the three major DOD higher-level protocols (file transfer, mail, and Telnet) to work with TP-4.
概要では、TCPとTP-4によって提供されたサービスは機能上全く同様です。 しかしながら、データ転送を含むいくつかの機能が連結します、フロー制御、コネクション確立結合、そして、バンドの外に、2つのプロトコルはかなり異なった方法で信号を提供します。 どちらも本質的に優れているように見えませんが、何らかの取り組みが、TP-4を利用するのにTCPを使用することで上位レベル・プロトコルを変換するのに必要でしょう。 必要である仕事の正確な量は上位レベル・プロトコル実装とそれらが埋め込まれているオペレーティングシステムの本質で異なるでしょう。 上位レベル・プロトコルで経験されたプログラマは、TP-4と共に扱う3つの主要なDOD上位レベル・プロトコル(ファイル転送、メール、およびTelnet)の変更を設計して、実装して、テストするためにおよそ6カ月を必要とするでしょう。
There are several areas in which the openness and lack of experience with the TP-4 specification leave questions about just what functionality is provided and whether incompatibilities are allowed. These areas include connection-establishment binding, flow control, addressing, and provision of expedited network service. The best way to resolve these questions seems to be to implement and test TP-4 in a military environment and to further specify desired procedures where there is unwanted latitude allowed by the standard (see the recommendations section XI).
TP-4仕様がある風通しの良さと経験の欠如がまさしくどんな機能性を提供するか、そして、非互換性を許容するかどうかに関する質問を残すいくつかの領域があります。 これらの領域は速められたネットワーク・サービスのコネクション確立結合、フロー制御、アドレシング、および支給を含んでいます。 これらの質問を決議する最も良い方法は軍事環境でTP-4を実装して、テストして、さらに、規格によって許容された求められていない緯度がある(推薦部のXIを見てください)必要な手順を指定することになっているように思えます。
There is one area in which the NBS-proposed Federal Information Processing Standard (FIPS) differs from the ISO specification: The FIPS provides a graceful closing service as in TCP, while the ISO does not.
NBSによって提案された連邦情報処理基準(FIPS)がISO仕様と異なっている1つの領域があります: FIPSはTCPのように優雅な終わりのサービスを提供しますが、ISOはそうしません。
National Research Council [Page 13] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[13ページ]RFC942 1985年2月のレポート輸送
Data Transfer Interface
データ転送インタフェース
TCP is stream oriented. It does not deliver any End of Transmission (EOT), but accepts a "push" on the send side which has an effect much like an EOT causes data being buffered to be sent.
TCPはストリーム指向しています。 それが、Transmission(EOT)の少しのEndも提供しませんが、「プッシュ」がオンであると受け入れる、EOTがバッファリングされるデータを送らせるように効果を持っている側を送ってください。
TP-4 is block oriented and does deliver EOT indications. By indicating EOT, a sending user should be able to accomplish the same effect as "push" in TCP in most reasonable TP-4 implementations.
TP-4はブロック指向していて、指摘をEOTに提供します。 EOTを示すことによって、送付ユーザはTCPでほとんどの妥当なTP-4実装で「プッシュ」と同じ効果を達成できるべきです。
The impact of this is uncertain. Neither type of interface is inherently better than the other. Some applications will find it more convenient to have a stream-type interface (for example, interactive terminal handling), while others might prefer a block mode (for example, file transfer). It should be possible for TP-4 to approximate the stream mode by forwarding data without an EOT from the sending user and delivering data to the receiving user before an EOT is received. Some work would have to be done on applications using one type of protocol to modify them to use the other.
この影響は不確実です。 どちらのタイプのインタフェースは本来もう片方より良いです。 いくつかのアプリケーションが、ストリーム型インタフェース(例えば、会話型端末装置取り扱い)を持っているのが、より便利であることがわかるでしょう、他のものはブロックモード(例えば、ファイル転送)を好むかもしれませんが。 送付ユーザからEOTなしでデータを転送して、EOTが受け取られている前に受信ユーザにデータを提供することによってTP-4がストリームモードに近似するのは、可能であるべきです。 アプリケーションのときにもう片方を使用するようにそれらを変更するのに1つのタイプのプロトコルを使用することでいくらかの仕事をしなければならないでしょう。
Flow Control
フロー制御
TCP has octet units of allocation, with no EOT and hence no impact of EOT on the allocation. The segment size, Transport Protocol Data Unit (TPDU) size, used by the protocol is invisible to the user, who sees allocations in units of octets.
TCPはEOTにもかかわらず、したがって、EOTのどんな影響なしでも八重奏ユニットの配分を配分に持っていません。 セグメントサイズ、ユーザにとって、プロトコルでサイズの、そして、中古のTransportプロトコルData Unit(TPDU)は目に見えません。(そのユーザは、ユニットの八重奏における配分を見ます)。
TP-4 has segment units of allocation, with a common segment size for both directions negotiated as part of connection establishment. Although in some implementations the protocol's flow control is not directly visible to the users, in others it is. In the latter case, users of TP-4 will see allocations in units of segments and will have to be aware of the segment size for this to be meaningful (for example, to know that a window of four 100-byte segments seen will be consumed by two messages of 101 to 200 bytes each).
TP-4には、コネクション確立の一部として交渉された両方の方向への共通セグメントサイズがあるセグメント単位の配分があります。 いくつかの実装で目に見えますが、他のもののユーザにとって、プロトコルのフロー制御は直接目に見えません。 後者の場合をTP-4のユーザは、これが重要である(例えば見られた4つの100バイトのセグメントの窓がそれぞれ101〜200バイトの2つのメッセージによって消費されるのを知る)ようにユニットのセグメントで配分を見て、セグメントサイズを意識しなければならないでしょう。
The impact is uncertain. Both octet and segment units of flow control can be argued to have their advantages for different types of application. The former makes it easy to indicate buffering limits in terms of total bytes (appropriate for stream transfer), while the latter makes it easy to indicate buffering limits in terms of messages (appropriate for block mode). The way in which flow control is exerted over an interface is complex and one of the most performance-sensitive areas of protocols, so a significant conversion and tuning effort would be required to get an application used with one type of high-level protocol to be able to perform using another.
影響は不確実です。 異なったタイプの適用のためのそれらの利点を持つために八重奏とセグメント単位のフロー制御の両方について論争できます。 前者で総バイトに関して(ストリーム転送に適切)で限界をバッファリングしながら、示すのが簡単になります、メッセージに関して(ブロックモードに適切)で限界をバッファリングしながら、後者で示すのが簡単になりますが。 どのフロー制御がインタフェースに出されているのが、複合体と1であるというプロトコルの最も多くの性能情報焦点地域のことであるかの道によって、重要な変換とチューニング取り組みが別のものを使用することで働くことができるように1つのタイプのハイレベルのプロトコルと共にアプリケーションを使用させるのに必要でしょう。
Error Detection
誤り検出
TCP applies ones-complement addition checksum. TP-4 uses an ISO
TCPはもの補数の追加チェックサムを適用します。 TP-4はISOを使用します。
National Research Council [Page 14] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[14ページ]RFC942 1985年2月のレポート輸送
algorithm (8). The error-detection properties of the TCP procedure have not been studied carefully, but the ISO algorithm is thought to be somewhat stronger and hence allows fewer nondetected errors in data passed to users. It should be noted that the TCP checksum is defined to include certain fields from the IP level including addresses so that double protection against misdelivery errors is provided. The practical difference in error-detection power is probably not important.
アルゴリズム(8)。 TCP手順の誤り検出特性が慎重に研究されていませんが、ISOアルゴリズムは、いくらか強いと考えられて、したがって、ユーザに渡されたデータに非検出されなかった誤りを許容します。 TCPチェックサムがアドレスを含むIPレベルからのある一定の分野を含むように定義されることに注意されるべきであるので、配達ミス誤りに対する二重保護を提供します。 誤り検出パワーの実用的な違いはたぶん重要ではありません。
Simultaneous Call Between Same Users
同じユーザの間の同時の呼び出し
TCP will establish one call. TP-4 will establish two calls if both sides support multiple calls, no call if they allow only one call (that is, see each other as busy), or in very unusual circumstances, one call. The impact is minor since most applications naturally have an initiator and a responder side.
TCPは1つの呼び出しを確立するでしょう。 1つの要求(すなわち、互いが忙しいとみなす)だけを許すか、または非常に珍しい事情(1つの呼び出し)で確立して、両側が複数の呼び出し、呼び出しを全くサポートしないと、TP-4は2つの呼び出しを確立するでしょう。 ほとんどのアプリケーションには創始者と応答者側が自然にあるので、影響は小さい方です。
Multiple Calls Between Same Addresses_
同じアドレス_の間の複数の呼び出し
TCP allows only one call between a given pair of source and destination ports. TP-4 allows more than one by using reference numbers. The impact is minor since it is easy to generate a new per-call port number on the calling side in most cases. This can be a problem in TCP, however, if both are well-known ports.
TCPは与えられた組のソースと仕向港の間の1つの呼び出しだけを許します。 TP-4は、参照番号を使用することによって、1つ以上を許容します。 多くの場合、新しい呼び出しが呼ぶ側のポートナンバーであると生成するのが簡単であるので、影響は小さい方です。 しかしながら、両方がウェルノウンポートであるなら、これはTCPの問題であるかもしれません。
Addressing
アドレシング
TCP provides sixteen bit ports for addressing within a node identified by the internet layer. Some of these ports are assigned to well-known applications, others are free for dynamic assignment as needed.
TCPはインターネット層によって特定されたノードの中のアドレシングに16ビットのポートを提供します。 これらのいくつかのポートがよく知られるアプリケーションに割り当てられて、ダイナミックな課題には、他のものは必要に応じて自由です。
TP-4 provides a variable-length transport suffix (same as Transport Service Access Point Identifier) in the call-request packet. The use of addresses at different levels in the ISO model has not yet been solidified, but it seems likely that addressing capabilities similar to TCP's will eventually be provided by TP-4 (or possibly the session layer) along with standard addresses for common applications.
TP-4は呼び出し要求パケットで(Transport Service Access Point Identifierと同じ)で可変長の輸送接尾語を提供します。 ISOモデルの異なったレベルにおけるアドレスの使用はまだ固められていませんが、TCPの意志と同様のアドレス指定能力は結局、一般的なアプリケーションのための標準のアドレスに伴うTP-4(または、ことによるとセッション層)によって提供されそうです。
The impact is likely to be minimal, but this is an open area of the ISO specifications that may need further definition for use by DOD.
影響は最小量である傾向がありますが、これはDODによる使用のためにさらなる定義を必要とするかもしれないISO仕様の空地です。
Binding User Entities to Connections
コネクションズへの拘束力があるユーザ実体
TCP requires a prior Listen Request from a user entity for it to be able to accept an incoming connection request. Normally a user entity must exist and declare itself to TCP, giving prior approval to accept
TCPは、入って来る接続要求を受け入れることができるようにユーザ実体から先のListen Requestを必要とします。 受け入れるために事前認可制度を与えて、通常、ユーザ実体は、TCPに存在していて、それ自体を宣言しなければなりません。
----- (8) For additional information, see Information Processing Systems, Open Systems Interconnection, Connection-Oriented Transport Protocol Specifications, ISO DIS 8073, Section 6.17, page 45.
----- (8) 追加情報に関しては、情報Processing Systemsを見てください、オープン・システム・インターコネクション、Connectionが指向のTransportプロトコルSpecifications、ISO DIS8073、セクション6.17、45ページ。
National Research Council [Page 15] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[15ページ]RFC942 1985年2月のレポート輸送
a call from a specific or general remote entity. In some implementations it may be possible for a nonresident user entity to cause a Listen Request to be posted and an instance of the entity to be created when a matching connection request arrives. TCP does not queue an incoming connection request with no matching Listen Request but instead rejects the connection.
特定の、または、一般的なリモート実体からの呼び出し。 いくつかの実装では、合っている接続要求が到着するとき、非居住者のユーザ実体でListen Requestが掲示されるのを作成して、実体のインスタンスを作成するのは可能であるかもしれません。 TCPは合っているListen Requestなしで入って来る接続要求を列に並ばせませんが、代わりに接続を拒絶します。
TP-4 requires no prior request but passes a Call Indication to a user entity whenever a Call Request is received. It is, however, left open as an implementation decision as to how TP-4 finds and/or creates an appropriate user entity to give the Call Indication; that is, the service does not include or define how user applications make themselves available for calls (no Listen Service Primitive). The implementation guidelines indicate that well-known addresses, prior process existence, and Call Request queuing are all facilities that may or may not be provided at the implementor's choice (9). This would seem to allow for different choices and hence failure to establish a connection between standard implementations (for example, caller expects requests not to be queued, while callee does queuing, and hence never responds).
Call Requestが受け取られているときはいつも、TP-4はどんな先の要求も必要としませんが、ユーザ実体にCall Indicationを渡します。 しかしながら、それはTP-4がCall Indicationに与えるために適切なユーザ実体を見つける、そして/または、どう作成するかに関して実装決定として開くままにされます。 すなわち、サービスは、ユーザアプリケーションで自分たちがどう要求(Listen Service Primitiveがない)に利用可能になるかを含んでもいませんし、定義もしません。 実施要綱は、よく知られるアドレス、先のプロセス存在、およびCall Requestの列を作りがすべて作成者の選択(9)で提供されるかもしれない施設であることを示します。 これは異なった選択と標準の実装の間に取引関係を築かないしたがって、ことを考慮するように思えるでしょう(例えば、訪問者は列に並ばせられないという要求を予想します、訪問される人が、列を作りをして、したがって、決して応じませんが)。
The practical impact is uncertain due to lack of experience with how the various options allowed by the TP-4 standard will be used in practice. TCP seems more oriented to a prior authorization mode of operation, while TP-4 most easily supports an indication-with-later-acceptance scenario. It is not clear how TP-4 will support rejecting calls to nonexistent or inactive user entities and how user entities could control how many calls they would accept. This area may require DOD refinement.
TP-4規格によって許容された様々なオプションが実際にはどう使用されるかで実用的な影響は経験の欠如のために不確実です。 TCPは、以上が操作の先の承認モードに適応したように思えますが、TP-4は最も容易に後の承認による指示シナリオをサポートします。 実在しないか不活発なユーザ実体への呼び出しを拒絶して、ユーザ実体が、それらがいくつの呼び出しを受け入れるかをどう制御するかもしれないかをTP-4がどのようにサポートするかは、明確ではありません。 この領域はDOD気品を必要とするかもしれません。
Out-of-Band Signals
バンドで出ている信号
TCP allows the user to specify an urgent condition at any point in the normal data stream. Several such indications may be combined, with only the last one shown to the destination. There is no limit to the number of urgent indications that can be sent. The TCP urgent messages are sent requesting expedited service from the network layer so network bottlenecks can be bypassed as well.
TCPはユーザに任意な点で通常のデータ・ストリームで緊急の状態を指定させます。 そのようないくつかの指摘が目的地に案内される最後のものだけに結合されるかもしれません。 送ることができる緊急の指摘の数への限界が全くありません。 急報が要求させられているTCPは、また、ネットワークボトルネックが迂回できるようにネットワーク層からサービスを速めました。
TP-4 allows users to send expedited data units carrying up to sixteen octets of user data. These are only half synchronized with the normal data stream since they may be delivered before previously sent normal data, but not after subsequently sent normal data. Each expedited data unit is delivered to the destination, and only one can be outstanding at a time. ISO has indicated its intention to allow transport protocols to use network-level expedited service, but this
TP-4は速められたデータ単位にユーザを利用者データの最大16の八重奏を運ばせます。 これらは、以前に正常なデータを送る前にそれらを提供するかもしれないので通常のデータ・ストリームと同期する半分だけですが、次に送られた正常なデータの後にそのような半分ではありません。 それぞれの速められたデータ単位は送付先に提供されます、そして、1つだけが一度に、傑出している場合があります。 ISOは、トランスポート・プロトコルがネットワークレベルを使用するのを許容するという意志がしかし、サービス、これを速めたのを示しました。
----- (9) Specification of a Transport Protocol for Computer Communications, Vol. 5: Guidance for the Implementor, Section 2.11.2. National Bureau of Standards, Institute for Computer Sciences and Technology, (Washington, D.C.) U.S. Department of Commerce, January 1983.
----- (9) コンピュータコミュニケーション、Vol.5のためのトランスポート・プロトコルの仕様: 作成者のための指導、セクション2.11.2。 規格基準局、コンピューターサイエンシズと技術の研究所(ワシントンDC) 1983年1月の米国商務省。
National Research Council [Page 16] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[16ページ]RFC942 1985年2月のレポート輸送
is not yet defined.
まだ定義されていません。
The impact is primarily for applications like terminal traffic handlers that must deal with interrupt-type signals of various types. The need to read an arbitrary amount of normal data and recognize urgent data in the normal stream are difficulties with TCP urgent service, but it has been used successfully by the Telnet protocol. The lack of full synchronization of the signal and normal data in TP-4 may require users to insert their own synchronization marks in the normal data stream [as was the case with the old ARPA Network Control Program (NCP)], and the limitation of one outstanding signal may be restrictive. Some effort would be required to convert higher-level protocols using one transport protocol to using the other.
影響は主として様々なタイプに関する中断タイプ信号に対処しなければならない端末のトラフィック操作者のようなアプリケーションのためのものです。 任意の量の正常なデータを読んで、正常なストリームにおける緊急のデータがTCPの緊急のサービスで困難であると認める必要性、それだけがTelnetプロトコルによって首尾よく使用されました。 TP-4での信号と正常なデータの完全な同期の不足は、ユーザが通常のデータ・ストリーム[古いアーパネットControl Program(NCP)があるケースのような]にそれら自身の同期マークを挿入するのを必要とするかもしれません、そして、1つの傑出している信号の限界は制限しているかもしれません。 何らかの取り組みが、もう片方を使用するのに1つのトランスポート・プロトコルを使用することで上位レベル・プロトコルを変換するのに必要でしょう。
Security
セキュリティ
The committee has determined that the TCP and TP-4 are sufficiently equivalent in their security-related properties so that no significant technical points favor the use of one over the other.
委員会が、TCPとTP-4が彼らのセキュリティ関連の所有地で十分同等であると決心していたので、どんなかなりのテクニカルポイントももう片方ほど1つの使用を好みません。
The DOD protocol architecture assigns the security-marking function to the IP layer and provides an 11-byte security option with a defined coding in the IP header.
DODプロトコルアーキテクチャは、安全保障マーク機能をIP層に割り当てて、IPヘッダーで11バイトのセキュリティオプションに定義されたコード化を提供します。
TP-4 provides a variable-length security option carried in Call Request packets. A variable-length security option field is also provided in the ISO IP. Standard encoding of security markings are under consideration but not yet defined and accepted.
TP-4はCall Requestパケットで運ばれた可変長のセキュリティオプションを提供します。 また、可変長のセキュリティオプション・フィールドをISO IPに提供します。 安全保障マークの標準のコード化は、考慮でありますが、まだ定義されていなくて受け入れます。
In addition to these explicit security-marking fields, the existence, coding, and placement of other header fields have security implications. If data is encrypted, for example, a checksum is usually used to determine if the decrypted data is correct, so the strength of the checksum has security implications.
これらの明白な安全保障マーク分野に加えて、他のヘッダーフィールドの存在、コード化、およびプレースメントには、セキュリティ意味があります。 例えば、データが暗号化されているなら、チェックサムが解読されたデータが正しいかどうか決定するのに通常使用されるので、チェックサムの強さに、セキュリティ意味があります。
Precedence
先行
TCP supports precedence by using three bits provided in IP headers of every packet. TP-4 provides a 2-byte priority option in Call Request packets. A 2-byte priority option in the ISO IP header is also under consideration. Currently, no implementations make use of precedence information (to support preemption, for example). There should be no impact, therefore, of changing from one protocol to the other.
TCPは、あらゆるパケットのIPヘッダーに提供された3ビットを使用することによって、先行をサポートします。 TP-4は2バイトの優先権オプションをCall Requestパケットに提供します。 ISO IPヘッダーの2バイトの優先権オプションは考慮中でもあります。 現在、どんな実装も先行情報(例えばサポート先取りに)を利用しません。 したがって、1つのプロトコルからもう片方に変化する影響が全くあるべきではありません。
Type of Service
サービスのタイプ
The types of network service that can be requested via TCP and TP-4 are somewhat different. The impact seems minimal since few networks do anything with the type of service fields at present with the exception of DARPA's packet radio and satellite nets. This may become more important in the future.
TCPとTP-4を通して要求できるネットワーク・サービスのタイプはいくらか異なっています。 DARPAのパケットラジオと衛星ネット以外に、わずかなネットワークしか現在のところサービス分野のタイプで何もしないので、影響は最小量に見えます。 これは将来より重要になるかもしれません。
National Research Council [Page 17] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[17ページ]RFC942 1985年2月のレポート輸送
Datagram Service
データグラムサービス
TCP provides only reliable session service. A separate User Datagram Protocol (UDP) in the DOD architecture supports transaction or connectionless-type interaction where individual messages are exchanged. UDP is merely an addition of the port-addressing layer to the basic datagram service provided by IP. No delivery confirmation or sequencing is provided (although IP provides fragmentation and reassembly).
TCPは信頼できるセッション・サービスだけを提供します。 DODアーキテクチャの別々のユーザー・データグラム・プロトコル(UDP)は個々のメッセージを交換するところでトランザクションかコネクションレスなタイプ相互作用をサポートします。 UDPは単にIPによって提供された基本的なデータグラムサービスへのポートを扱う層の追加です。 配送確認か配列を提供しません(IPは断片化と再アセンブリを提供しますが)。
The NBS TP-4 specification originally presented to the committee provided unit-data-transfer service within the same protocol framework as sessions (10). This material has since been deleted to bring the NBS proposal into conformance with ISO work. A separate ISO datagram protocol similar to UDP has been defined and is expected to become a draft proposed standard in June 1984.
元々委員会に提示されたNBS TP-4仕様はセッション(10)と同じプロトコルフレームワークの中でユニットデータ転送サービスを提供しました。 この材料は、以来、ISO仕事に応じてNBS提案を順応に運び込むように削除されています。 UDPと同様の別々のISOデータグラムプロトコルは、定義されて、1984年6月に草稿提案された標準になると予想されます。
Closing
閉じます。
TCP provides a graceful closing mechanism that ensures that all data submitted by users are delivered before the connection is terminated. The NBS TP-4 provides a similar mechanism, but is not included in the ISO standard TP-4, which provides only an immediate disconnect service. Impact is significant if the ISO version is used because users would then have to add their own graceful termination handshake if desired.
TCPは接続が終えられる前にユーザによって提出されたすべてのデータが提供されるのを確実にする優雅な開閉装置を提供します。 NBS TP-4は同様のメカニズムを提供しますが、ISOの標準のTP-4に含まれていません。(TP-4は即座の分離サービスだけを提供します)。 次に、望まれているなら、ユーザはそれら自身の優雅な終了握手を加えなければならないでしょう、したがって、ISOバージョンが使用されているなら、影響が重要です。
COMPARISON OF DOD AND ISO INTERNET LAYERS
DODとISOインターネット層の比較
The internet protocols of DOD and ISO are much more similar to one another than the transport protocols. This is not surprising since the Defense Department's IP was used as the basis for the International Standards Organization's IP. Some reformatting, renaming, and recoding of fields has been done. Hence not only are the services to higher layers essentially equivalent, but the protocol mechanisms themselves are also nearly identical. Due to the format changes, however, the two protocols are incompatible.
DODとISOのインターネットプロトコルはトランスポート・プロトコルからお互いとはるかに同様です。 国防総省のIPが国際Standards OrganizationのIPの基礎として使用されたので、これは驚くべきものではありません。 いくつかの再フォーマット、改名、および分野の再コード化は完了していました。 したがって、唯一でないのが、より高いことに対するサービスが本質的には同等物を層にするということですが、また、プロトコルメカニズム自体もほとんど同じです。 形式変化のために、しかしながら、2つのプロトコルが両立しないです。
It should be noted that the IP itself forms only part of the internet layer. For clarity it should also be noted that the internet layer in ISO is considered to be the top sublayer within the network layer.
IP自身がインターネット層の一部だけを形成することに注意されるべきです。 明快によって、また、ISOのインターネット層がネットワーク層の中の最高副層であると考えられるのが有名であるべきです。
In DOD, there is an additional Internet Control Message Protocol (ICMP) that deals with error conditions, congestion control, and simple routing updates to host computers. There is also a Gateway-to-Gateway Protocol (GGP) that deals with internet management and routing updates for gateways. In the ISO, only the IP itself has so far been
DODに、エラー条件、輻輳制御、および簡単なルーティングアップデートにホストコンピュータに対処する追加インターネット・コントロール・メッセージ・プロトコル(ICMP)があります。 また、ゲートウェイにはゲートウェイからゲートウェイへのインターネット管理とルーティングアップデートと取り引きするプロトコル(GGP)があります。 ISOには、IP自身しか今までのところありませんでした。
----- (10) National Bureau of Standards, Specification of a Transport Protocol for Computer Communications, Vol. 3, Class 4 Protocol, ICST/HLNP-83-3, February 1983.
----- (10) 規格基準局、コンピュータコミュニケーション、Vol.3、クラス4プロトコル、ICST/HLNP-83-3、1983年2月のトランスポート・プロトコルの仕様。
National Research Council [Page 18] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[18ページ]RFC942 1985年2月のレポート輸送
considered, while most error reporting, control, and routing functions are considered "management" functions that remain to be addressed in the future.
機能をほとんどの誤り報告、コントロールである間、考えられて、発送するのは将来扱われるために残っている「管理」機能であると考えられます。
The only significant differences in the IPs themselves are in the areas of addressing and error reporting. The DOD IP has a fixed-length, 32-bit source and destination addresses (identifying network and host) plus an 8-bit "protocol number" field to identify the higher-level protocol for which the IP data is intended. The ISO IP has variable-length source and destination addresses whose format and content are not yet specified, although preliminary documentation indicates that ISO intends to support a similar level of addressing (network/host) in a more global context which would allow use of current DOD addresses as a subset. There is no equivalent of the DOD protocol number field, although possibly the tail of the variable-length ISO addresses could be used for this purpose.
IPs自身の唯一の著しい違いがアドレシングと誤り報告の領域にあります。 DOD IPには、アドレス(ネットワークを特定して、ホスト)と8ビットの「プロトコル番号」がIPデータが意図する上位レベル・プロトコルを特定するためにさばく固定長、32ビットのソース、および目的地があります。 ISO IPには、形式と内容がまだ指定されていない可変長のソースと送付先アドレスがあります、予備のドキュメンテーションは、ISOが部分集合として現在のDODアドレスの使用を許すよりグローバルな文脈の同じ水準のアドレシング(ネットワーク/ホスト)をサポートするつもりであるのを示しますが。 DODプロトコルナンバーフィールドの同等物が全くありません、このためにことによると可変長のISOアドレスのテールを使用できましたが。
Error reporting is provided within the ISO IP by means of a separate packet type, while the DOD provides more complete error- and status-reporting functions via the separate Internet Control Message Protocol (ICMP), including routing "redirect" messages to hosts that have sent datagrams via nonoptimal routes.
別々のパケットタイプによってISO IPの中で誤り報告を提供します、別々のインターネット・コントロール・メッセージ・プロトコル(ICMP)でDODは、より完全な誤りと状態を報告する機能を提供しますが、「再直接」のメッセージをnonoptimalルートでデータグラムを送ったホストに発送するのを含んでいて。
In summary, from the functional point of view, DOD and ISO IP can be considered essentially equivalent with the provision that the ISO-addressing scheme is suitably resolved. The absence of routing and control procedures from the ISO internet layer means that additional procedures beyond IP would be needed to produce a complete, functioning, internet even if the ISO IP were adopted. It appears that the existing DOD ICMP and GGP or its successors could be modified to operate with the ISO IP with modest effort, but this requires further study and validation in an operational system.
概要では、機能的な観点から、ISOを扱っている体系が適当にそうである支給によって同等であると決心していた状態でDODとISO IPを本質的には考えることができます。 ISOインターネット層からのルーティングとコントロール手順の欠如は、ISO IPが採用されたとしてもIPを超えた追加手順が完全で、機能しているインターネットを生産するのに必要であることを意味します。 ISO IPと共に穏やかな取り組みで作動するように既存のDOD ICMPとGGPかその後継者を変更できたように見えますが、これは基幹系システムでさらなる研究と合法化を必要とします。
A table at the end of this chapter compares DOD and ISO IP packet formats.
本章の終わりのテーブルはDODとISO IPパケット・フォーマットを比較します。
COMPARISON ON THE BASIS OF PERFORMANCE, SECURITY, AND RISK
性能、セキュリティ、およびリスクに基づいた比較
Performance
パフォーマンス
The performance of a transport protocol, such as TCP or TP-4, is a function of its implementation as well as its inherent design. Experience in implementing TCP and other proprietary protocols has demonstrated that implementation considerations usually dominate. This makes it difficult to compare protocols, since a wide range in efficiency of implementations is possible. Furthermore, there are a number of dimensions along which an implementation can be optimized.
TCPかTP-4などのトランスポート・プロトコルの性能は固有のデザインと同様に実装の機能です。 TCPと他の固有のプロトコルを実装する経験は、通常、実装問題が支配されるのを示しました。 これで、実装の効率における広範囲が可能であるのでプロトコルを比較するのは難しくなります。 その上、実装を最適化できる多くの寸法があります。
Despite the difficulties, protocol designers have developed several metrics for comparing transport protocols. These view protocol performance from a variety of perspectives, including (1) user response time, (2) throughput on a single connection, (3) network and host computer resource utilization. Protocol efficiency can also be
困難にもかかわらず、プロトコルデザイナーは、トランスポート・プロトコルを比較するためにいくつかの測定基準を開発しました。 これらはさまざまな見解からプロトコル性能を見ます、単独結合、(3)ネットワーク、およびホストコンピュータリソース利用のときに(2) (1) ユーザ応答時間、スループットを含んでいて。 また、プロトコル効率があることができます。
National Research Council [Page 19] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[19ページ]RFC942 1985年2月のレポート輸送
significantly affected by the communications environment. Protocol efficiency must be considered in a wide range of communication environments, including local area networks, satellite links, terrestrial links, and packet-switched networks.
コミュニケーション環境でかなり影響を受けます。 さまざまな通信環境でプロトコル効率を考えなければなりません、ローカル・エリア・ネットワーク、衛星中継、地球のリンク、およびパケット交換網を含んでいて。
The critical algorithms most affecting protocol performance are those that perform end-to-end error control and end-to-end flow control. These algorithms affect the response time, throughput, and resource utilization of the protocol during the data transfer phase. The efficiency of the connection management procedures may also be important in applications involving frequent connections of brief duration.
プロトコル性能に最も影響する重要なアルゴリズムは終わりから終わりへの誤り制御と終わりから終わりへのフロー制御を実行するものです。 これらのアルゴリズムはデータ転送段階の間、プロトコルの応答時間、スループット、およびリソース利用に影響します。 また、接続管理手順の効率も、簡潔な持続時間の頻繁な接続にかかわりながら、アプリケーションで重要であるかもしれません。
The committee compared the algorithms and message formats specified for each protocol for critical functions, including flow-and error-control and connection management. They concluded that since the two protocols were sufficiently similar there would be no significant difference in performance of TCP or TP-4 implementations of equal quality optimized for a given environment.
そして、委員会はアルゴリズムを比較しました、そして、メッセージ・フォーマットは批判的機能として各プロトコルに指定しました、含んでいる、流れ、-、誤り制御と接続管理。 彼らは、2つのプロトコルがそこで十分同様であったのでそれが与えられた環境のために最適化されたTCPの性能か等しい品質のTP-4実装の著しい違いでないと結論づけました。
The committee compared the error-and-flow-control algorithms of TCP/IP and TP-4. Both employ window-based techniques using large-sequence number spaces and both permit large window sizes. Their differences are minor. TCP performs its error-and-flow-control in units of octets, rather than the protocol data units employed by TP-4. This adds a small amount of overhead to TCP calculation in return for a finer control over host buffer memory. The committee did not consider the difference significant, assuming that appropriate buffer management strategies are implemented by transport and higher-level protocols. TP-4 employs more sophisticated techniques to ensure that flow-control information is reliably transmitted than does TCP. These more sophisticated techniques may reduce TP-4 protocol overhead during periods of light load in some applications, possibly adding slightly more CPU load in other cases. The committee did not consider these effects significant.
委員会はTCP/IPとTP-4の誤りとフロー制御アルゴリズムを比較しました。 両方が、大きい一連番号空間を使用することで窓のベースのテクニックを使って、ともに大きいウィンドウサイズを可能にします。 それらの違いは小さい方です。 TCPはTP-4によって使われたプロトコルデータ単位よりむしろユニットの八重奏におけるその誤りとフロー制御を実行します。 これはホストバッファメモリの、よりよいコントロールのお返しにTCP計算に少量のオーバーヘッドを加えます。 委員会は、違いが重要であると考えませんでした、適切なバッファ経営戦略が輸送と上位レベル・プロトコルによって実装されると仮定して。 TP-4はフロー制御情報が確かに伝えられるのを保証するためにTCPより精巧なテクニックを使います。 これらのより精巧なテクニックは軽い荷の期間、使用目的によってはTP-4プロトコルオーバーヘッドを下げるかもしれません、ことによると他の場合で、より多くのCPU荷重をわずかに加えて。 委員会は、これらの効果が重要であると考えませんでした。
Both protocols employ a three-way handshake for establishing a transport connection. The differences between the TCP and TP-4 handshake are related to the addressing conventions employed for establishing connections and do not affect protocol efficiency. In the common cases where a client process requests a connection to a server process, the TCP and TP-4 operations are equivalent.
両方のプロトコルは輸送接続を確立するための3方向ハンドシェイクを使います。 TCPとTP-4握手の違いは、関係を樹立するのに使われたアドレシングコンベンションに関連して、プロトコル効率に影響しません。 よくある例では、中、クライアントプロセスがサーバプロセスに接続を要求するTCPとTP-4操作は同等です。
Both protocols permit a range of policy decisions in their implementation. These include (1) selection of timer values used to recover from transmission errors and lost packets, (2) selection of window sizes at the receiver and transmitter, and (3) selection of protocol data unit sizes. Both permit substantial reduction in control message overhead by expanding window sizes. Both permit credits to be granted "optimistically," permitting receiver buffers to be shared over several transport connections and permitting credit reduction in the event of buffer congestion. Both permit optimizing protocol efficiency by delaying control message traffic when it does
両方のプロトコルはそれらの実装におけるさまざまな政策決定を可能にします。 これらは(1) 伝送エラーと無くなっているパケットから回復するのに使用されるタイマ値の品揃え、(2) 受信機と送信機のウィンドウサイズの品揃え、および(3) データ単位が大きさで分けるプロトコルの選択を含んでいます。 両方が、ウィンドウサイズを広げることによって、コントロールメッセージオーバーヘッドのかなりの減少を可能にします。 両方が、クレジットが「楽観的に」与えられることを許可します、受信機バッファが数人の輸送の接続の上で共有されて、バッファ混雑の場合、クレジット減少を可能にしていることを許可して。 許可するとき、両方が、コントロールメッセージトラフィックを遅らせることによってプロトコル効率を最適化することを許可します。
National Research Council [Page 20] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[20ページ]RFC942 1985年2月のレポート輸送
not need to be transmitted, combining it with later data or control traffic.
後のデータかコントロールトラフィックにそれを結合して、伝えられる必要はありません。
The most significant difference between TCP and TP-4 flow control derives from slight differences in expression of flow control at the transport layer service interface. TCP employs a stream model while TP-4 uses a message model. These two models are equivalent in function; however, some higher-level applications protocols may be more naturally expressed in one model than the other. The committee considered the possibility that current ARPA protocols might require some adaptation to operate more efficiently with TP-4. For this reason the committee recommends that the DOD study the operation of current DOD higher-level protocols on TP-4 (recommendation 5, Chapter XI).
TCPとTP-4フロー制御の最も重要な違いがトランスポート層サービスインタフェースでフロー制御の式のわずかな違いに由来しています。 TP-4はメッセージモデルを使用しますが、TCPはストリームモデルを雇います。 これらの2つのモデルが機能で同等です。 しかしながら、いくつかの、よりハイレベルのアプリケーションプロトコルが1つのモデルでもう片方より自然に表されるかもしれません。 委員会は、現在のARPAプロトコルが何らかの適合を必要とするかもしれない可能性がTP-4と共に、より効率的に作動すると考えました。 この理由で、委員会は、DODがTP-4(推薦5、章のXI)における現在のDOD上位レベル・プロトコルの操作を研究することを勧めます。
Security
セキュリティ
The committee considered the impact of security requirements on transport protocols primarily and also on overall protocol hierarchies in the DOD, The American National Standards Institute (ANSI), and ISO. Based on the information the committee received, it finds that:
委員会は、輸送に関するセキュリティ要件の影響が主としてとDODの総合的なプロトコル階層に関してもプロトコルと、American National Standards Institut(ANSI)と、ISOであると考えました。 委員会が受け取った情報に基づいて、それは、以下のことがわかります。
The current TCP-4 and TP-4 are sufficiently equivalent in their security-related properties that no significant technical points would favor the use of one over the other.
現在のTCP-4とTP-4による十分、かなりのテクニカルポイントがないのがそうする彼らのセキュリティ関連の所有地の同等物がもう片方より1つの使用を好むということです。
There is no technical impediment to their equivalent evolution over time in the security area.
それらの同等な発展のどんな技術的な障害も時間がたつにつれてセキュリティ領域にありません。
Risk
リスク
There are several risks in implementing a new protocol or protocol family. These include (1) fatal flaws in protocol design not easily rectified, (2) errors in protocol specification, (3) ambiguities in protocol specification, (4) errors in protocol implementation, (5) performance degradation due to inefficient implementation, (6) performance degradation due to "untuned" implementation, and (7) performance degradation due to untuned application protocols.
新しいプロトコルかプロトコルファミリーを実装するのにおいていくつかのリスクがあります。 これらは容易に正されなかったプロトコルデザイン、プロトコル仕様に基づく(2)誤り、プロトコル仕様による(3)のあいまいさ、プロトコル実装における(4)誤り、効率の悪い実装による(5)性能退行、"非調整"の実装による(6)性能退行、および非調整されたアプリケーション・プロトコルによる(7)性能退行に(1) 重大な欠陥を含んでいます。
This list of risks comes from experience in implementing computer networks based on the DOD protocols and proprietary commercial protocols. Considering that it took more than ten years for the current TCP protocols to reach their current state of maturity and that the TP-4 protocol is only about two years old, the committee devoted considerable attention to the maturity of TP-4.
リスクのこのリストはDODプロトコルと独占商業プロトコルに基づくコンピュータネットワークを実装する経験から来ます。 現在のTCPプロトコルが彼らの円熟の現状に達するには10年以上かかって、TP-4プロトコルがほんのおよそ2歳であると考える場合、委員会はTP-4の円熟にかなりの注意をささげました。
Fatal Flaws in Protocol Design
プロトコルデザインにおける重大な欠陥
Early ARPANET protocols had a number of "fatal" design errors that resulted in deadlocks or other serious system failures. Commercial networks had similar problems in early design phases. The committee considered the possibility that TP-4 could suffer from similar faults and concluded that this was unlikely. TP-4 employs design techniques
早めのアルパネットプロトコルには、多くの行き詰まりをもたらした「致命的な」設計ミスか他の重大なシステム障害がありました。 商業ネットワークには、早めの設計段階における同様の問題がありました。 委員会は、TP-4が同様の欠点を欠点であることができた可能性を考えて、これがありそうもないと結論を下しました。 TP-4は設計技術を使います。
National Research Council [Page 21] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[21ページ]RFC942 1985年2月のレポート輸送
similar to those of TCP and proprietary transport protocols. The faults encountered in the ARPANET are now well known. Indeed, the state of the art in transport protocol design is now quite mature. The developers of the TP-4 protocol were familiar with the earlier protocols and their problems.
TCPと独占トランスポート・プロトコルのものと同様です。 アルパネットで遭遇する欠点は現在、よく知られています。 本当に、トランスポート・プロトコルデザインにおける到達技術水準は現在、かなり熟しています。 TP-4プロトコルの開発者は以前のプロトコルとそれらの問題に詳しかったです。
Errors and Ambiguities in Protocol Specification
プロトコル仕様による誤りとあいまいさ
Early in the development of TP-4, NBS developed a formal protocol specification and a test environment based on this specification. A protocol implementation can be partially compiled automatically from the formal specification. Other implementations can be tested against this master implementation. The NBS protocol laboratory was used to debug the formal specification of TP-4 and is currently being used to certify other implementations of TP-4. The laboratory has also developed and employed tools to analyze the specification for possible problems. The existence of this laboratory and the results obtained to date led the committee to conclude that there is no substantial risk associated with the TP-4 protocol specification.
早く、TP-4の開発では、NBSは正式なプロトコル仕様とこの仕様に基づく試験環境を開発しました。 形式仕様からプロトコル実装を部分的に自動的にコンパイルできます。 このマスター実装に対して他の実装をテストできます。 NBSプロトコル実験室は、TP-4に関する形式仕様をデバッグするのに使用されて、現在、TP-4の他の実装を公認するのに使用されています。 また、実験室は、起こりうる問題のための仕様を分析するのにツールを開発して、使いました。この実験室の存在とこれまで得られた結果は、委員会が、TP-4プロトコル仕様に関連しているどんなかなりのリスクもないと結論を下すように導きました。
In contrast TCP has only recently received a formal specification. To the committee's knowledge most existing TCP implementations predate the formal TCP specification and have not been derived from the formal specification. In the committee's opinion the formal TCP specification is likely to have more bugs or ambiguities than the TP-4 specification.
対照的に、TCPは最近、形式仕様を受け取るだけでした。 委員会のものが知っている限り、ほとんどの既存のTCP実装は、正式なTCP仕様より前に起こって、形式仕様から得られていません。 委員会の意見では、正式なTCP仕様はTP-4仕様よりバグかあいまいさを持っていそうです。
At the present time NBS has developed the only formal specification for ISO TP-4. ISO is currently developing standards for formal specification techniques that are similar to those used by NBS. When these specifications are complete ISO will update the TP-4 specification to include a formal description. In translating the current informal ISO specification into the formal specification there is a risk that the ISO specification may be changed such that it is no longer consistent with the current NBS specification. The National Bureau of Standards is playing a key role in developing the ISO formal specification techniques and formal specification. It plans to generate automatically an implementation of the ISO formal specification and verify it against the NBS specification using the NBS test tools. In the committee's opinion this makes the risk of unintentional changes in the ISO specification quite low.
現在では、NBSはISO TP-4のための唯一の形式仕様を開発しました。 ISOは現在、NBSによって使用されたものと同様の形式仕様のテクニックの規格を開発しています。 これらの仕様が完全であるときに、ISOは、形式的記述を含むようにTP-4仕様をアップデートするでしょう。 そこで現在の非公式のISO仕様を形式仕様に翻訳する際に、ISO仕様をあるかもしれない危険を変えるので、それはもう現在のNBS仕様と一致していません。 規格基準局はISO形式仕様のテクニックと形式仕様を見いだす際に重要な役割を果たしています。 それは、自動的にISO形式仕様の実装を生成して、NBSテスト・ツールを使用することでNBS仕様に対してそれについて確かめるのを計画しています。 委員会の意見では、これで、ISO仕様に基づく意図的でない変化の危険はかなり低くなります。
One possible risk remains. The ISO specification for TP-4 that was approved is an informal document subject to the ambiguities of informal protocol specifications. The formalization may remove ambiguities that have gone undetected and that were the basis of its approval. It is conceivable that once these ambiguities are exposed, the current consensus for TP-4 may dissolve. The committee considers this risk to be very low. The areas of ambiguity in protocol specifications are typically only of concern to protocol implementors. The current protocol implementors through much of the world are typically using the NBS formal specifications as a basis of their implementations of TP-4 and have access to the NBS test tools for
危険が残っているのが可能な1つ。 承認されたTP-4のためのISO仕様は非公式のプロトコル仕様のあいまいさを条件とした非公式のドキュメントです。 形式化は察知されずにいて、承認の基礎であったあいまいさを取り除くかもしれません。 これらのあいまいさがいったん暴露されると、TP-4に関する現在のコンセンサスが溶けるのが想像できます。 委員会は、このリスクが非常に低いと考えます。 プロトコル仕様によるあいまいさの領域は、単に作成者について議定書の中で述べるために通常重要です。 世界の大部分を通した現在のプロトコル作成者は、それらのTP-4の実装の基礎としてNBS形式仕様を通常使用していて、NBSテスト・ツールに近づく手段を持っています。
National Research Council [Page 22] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[22ページ]RFC942 1985年2月のレポート輸送
certifying their implementations. In the event of a possible conflict, the majority of implementors could be expected to support resolution of ambiguities in favor of the current NBS formal specification, making it unlikely that ISO would approve an alternate resolution.
それらの実装を公認します。 可能な闘争の場合、作成者の大部分が現在のNBS形式仕様を支持してあいまいさの解決をサポートすることが期待されるかもしれません、ISOが代替の決議を承認するだろうというのをありそうもなくして。
Errors in Protocol Implementation
プロトコル実装における誤り
Several factors influence the likelihood of errors in a protocol implementation. These include the complexity of the protocol, quality of the protocol specification, the experience of the implementors, and the availability of test tools. Based on the availability of the NBS test tools and formal protocol specification for TP-4, the committee did not see any significant risk of errors in implementing TP-4.
いくつかの要素がプロトコル実装における誤りの見込みに影響を及ぼします。 これらはプロトコルの複雑さ、プロトコル仕様の品質、作成者の経験、およびテスト・ツールの有用性を含んでいます。 NBSテスト・ツールとTP-4に、正式なプロトコル仕様の有用性に基づいて、委員会はTP-4を実装する際に誤りの少しの重要な危険も見ませんでした。
Performance Issues
パフォーマンス問題
The largest risk in implementing TP-4 concerns the performance of the implementations. This risk is not inherent in the protocol as specified, but is present in new implementations of any transport protocol. Experience has shown that performance can often be improved by a factor of two or more by careful attention to implementation details and careful performance measurement and tuning. The committee considered it likely that some initial implementations of TP-4 will have significantly lower performance than the current mature implementations of TCP. Evidence to support this conclusion may be found in data supplied by the DOD which show a wide range of performance of TCP implementations.
TP-4を実装するのにおいて最も大きいリスクは実装の性能に関係があります。 このリスクは、指定されるとしてプロトコルでは固有ではありませんが、どんなトランスポート・プロトコルの新しい実装でも存在しています。 経験は、2以上の要素で実装の詳細、慎重な性能測定、およびチューニングに関する慎重な注意で性能をしばしば向上させられることができるのを示しました。 委員会は、TP-4のいくつかの初期の実装には性能の低下がTCPの現在の熟している実装よりかなりありそうであると考えました。 この結論をサポートする証拠はTCP実装のさまざまな性能を示しているDODによって提供されたデータで見つけられるかもしれません。
Some members of the committee expressed the belief that over the long term, TP-4 will afford better performance due to widespread commercial support. Vendors will be highly motivated to optimize performance of their TP-4 implementations, since a large number of users will benchmark implementation performance. Many individuals will become familiar with implementations of TP-4 and with configuring and operating networks based on TP-4. Initially, this expertise will be found in organizations developing TP-4 implementations and installation.
委員会の何人かのメンバーが長期的に見るとTP-4が広範囲の商業サポートによる、より良い性能を提供するという信念を言い表しました。 多くのユーザはベンチマーク実装性能がそうして、それらのTP-4実装の性能を最適化するために動機づけられて、ベンダーが非常にそうでしょう。 多くの個人がTP-4の実装と構成して、TP-4に基づくネットワークを経営するのになじみ深くなるでしょう。 初めは、この専門的技術はTP-4実装とインストールを開発する組織で見つけられるでしょう。
The committee believes that the largest performance risks are short term. The performance of existing DOD high-level protocols may be affected by subtle differences between TP-4 and TCP interfaces. Highlevel DOD implementations and protocols may require retuning to attain some high-level efficiency using TP-4. Another short-term risk is potential lack of experience in configuring and operating TP-4-based networks. The committee believes that a program of testing and development would minimize these risks, ensuring that the current high-level DOD protocols run effectively on TP-4-based networks.
委員会は、最も大きい性能リスクが短期間であると信じています。 既存のDODハイレベルのプロトコルの性能はTP-4とTCPインタフェースの微妙な違いで影響を受けるかもしれません。 Highlevel DOD実装とプロトコルは、再調整が何らかのハイレベルの効率を得るのをTP-4を使用することで必要とするかもしれません。 別の短期的なリスクはTP-4を拠点とするネットワークを構成して、経営することにおいて潜在的経験の欠如です。 委員会は、テストと開発に関するプログラムがこれらの危険を最小にすると信じています、現在のハイレベルのDODプロトコルが有効にTP-4を拠点とするネットワークで動くのを確実にして。
There is a possibility that the equivalent, but different, protocol mechanisms and interfaces in TP-4 may manifest some undesirable behavior that is not expected and which cannot easily be removed by tuning. In this event ISO may find it necessary to make some
TP-4の同等な、しかし、異なったプロトコルメカニズムとインタフェースが予想しないで、チューニングで容易に取り除くことができない何らかの好ましくない行動を表すかもしれない可能性があります。 このイベントでは、ISOは、いくつかを作るのが必要であることがわかるかもしれません。
National Research Council [Page 23] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[23ページ]RFC942 1985年2月のレポート輸送
modifications to TP-4. It is unlikely that such problems will be serious enough to prevent an early transition to TP-4. If such problems are discovered, it is expected that they can be handled through the normal standards process of periodic enhancement. A number of proprietary commercial networking protocols are similar in operation to TP-4 and do not have serious performance problems. Any enhancements that may be desirable can probably be added to TP-4 in a compatible fashion, permitting interoperation of enhanced and unenhanced implementations.
TP-4への変更。 問題がTP-4への早めの変遷を防ぐことができるくらい重大になるのは、ありそうもないです。 そのような問題が発見されるなら、周期的な増進の正常な標準化過程でそれらを扱うことができると予想されます。 多くの独占商業ネットワーク・プロトコルは、稼働中でありTP-4と同様であり、重大な性能問題を持っていません。たぶんコンパチブルファッションでどんな望ましいかもしれない増進もTP-4に加えることができます、高められて「非-高め」られた実装のinteroperationを可能にして。
TABLE: Comparison of DOD and ISO IP Packet Formats
以下をテーブルの上に置いてください。 DODとISO IPパケット・フォーマットの比較
DOD ISO (not in correct order) ----------------------------------------------------------------------
DOD ISO(正しいオーダーでないのにおける)----------------------------------------------------------------------
Protocol version: 4 bits Version: 8 bits
Header Length (in 32-bit words): [Header] Length (in bytes): 8 bits
4 bits
Type of service: 8 bits Quality of service**: 8 bits
(includes 3-bit Precedence) Precedence**: 8 bits
Total Length: 16 bits Segment Length: 16 bits
ID: 16 bits Data Unit ID*: 16 bits
Don't Fragment flag Segmentation Permitted flag
More Fragments flag More Segments flag
Fragment offset: 13 bits Segment offset*: 16 bits
Time to live (sec): 8 bits Lifetime (.5 sec): 8 bits
Protocol number: 8 bits ---
Header checksum: 16 bits Header checksum: 16 bits
(provided by subnet layer) Network Layer Protocol ID: 8 bits
--- [Generate] Error flag
(in ICMP) Type: 5 bits
--- Total Length*: 16 bits
............. .............
Source address: 32 bits Source address length: 8 bits
Source address: var.
Dest. address: 32 bits Dest. address length: 8 bits
Dest. address: var.
............. .............
バージョンについて議定書の中で述べてください: 4ビットのバージョン: 8ビットのHeader Length(32ビットの単語による): [ヘッダー]の長さ(バイトによる): 8ビット4ビットのサービスのType: サービス**の8ビットのQuality: 8ビット(3ビットのPrecedenceを含んでいる)先行**: 8ビットのTotal Length: 16ビットのSegment Length: 16ビットのID: 16ビットのData Unit ID*: Fragment旗のSegmentation Permitted旗のMore Fragments旗のMore Segments旗のFragmentではなく、16ビットのドンが相殺しました: 13ビットのSegmentは*を相殺します: 生きる16ビットのTime(秒): 8ビットのLifetime(.5秒): 8ビットのプロトコル番号: 8ビット--- ヘッダーチェックサム: 16ビットのHeaderチェックサム: 16ビット(サブネット層のそばで提供する)はLayer Protocol IDをネットワークでつなぎます: 8ビット--- [生成します] エラーフラグ(ICMPの)タイプ: 5ビット--- 全長*: 16ビット… ............. ソースアドレス: 32ビットのSourceは長さを扱います: 8ビットのSourceアドレス: var. Destアドレス: 32ビットのDest長さを扱ってください: 8ビットのDestアドレス: var. ............. .............
OPTIONS: NOP, Security, OPTIONS: Padding, Security
Source Route, Record Route, Source Route, Record Route,
Stream ID, Time Stamp Quality of service, Precedence,
Error reason (only for error type)
............. .............
DATA DATA
......................................................................
オプション: NOP、セキュリティ、オプション: 詰め物、Security Source Route、Record Route、Source Route、サービスのRecord Route、Stream ID Time Stamp Quality、Precedence、Errorは推論します(誤りタイプのためだけに)… ............. データデータ…
* only present if segmentation is in use ** in options
* プレゼントしか分割であるならオプションにおける使用**にありません。
National Research Council [Page 24] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[24ページ]RFC942 1985年2月のレポート輸送
IV. STATUS OF DOD AND ISO PROTOCOL IMPLEMENTATIONS AND SPECIFICATIONS
IV。 DOD、ISOプロトコル実装、および仕様の状態
DEPARTMENT OF DEFENSE
国防総省
The DOD internetting protocol was first introduced in 1974 and later split into separate TCP and IP specifications. From 1974 until 1978, when they were adopted as DOD standards, the protocols underwent a number of major revisions. These revisions were largely a result of extensive experience gained by researchers working on the DARPA Internet project. The DARPA "Request for Comment" and "Internet Experimental Note" technical report series document the conclusions of numerous protocol-related studies and discussions. Successive specifications of TCP and other internet protocols are also given by reports in these series. Most of these specifications were informally presented and were accompanied by discussions that affected design choices. The most recent TCP documents introduce a more formal style of presentation (11).
DOD internettingプロトコルは、1974年に最初に、紹介されて、後で別々のTCPとIP仕様に分けられました。 それらがDOD規格として採用されたとき、1974年から1978年まで、プロトコルは多くの主要な改正を受けました。 これらの改正は主にDARPAインターネットプロジェクトに取り組むという研究者によって獲得された広範囲の経験の結果でした。 DARPA「コメントを求める要求」と「インターネットの実験注意」技術報告書シリーズは頻繁なプロトコル関連の研究と議論の結論を記録します。 また、これらのシリーズにおけるレポートはTCPと他のインターネットプロトコルの連続した仕様を与えます。 これらの仕様の大部分は、非公式に提示されて、デザイン選択に影響した議論で伴われました。 最新のTCPドキュメントは、より正式なスタイルのプレゼンテーション(11)を導入します。
The first experimental TCP implementations were completed in 1974 at Stanford University and Bolt Beranek and Newman, Inc., for the PDP-11/ELF and DEC-10/TENEX systems, respectively. Today implementation exists for numerous computer systems. While many of these were implemented at and are supported by university and other research groups, several are available as commercial products.
最初の実験的なTCP実装は1974年にPDP-11/ELFと12月-10/TENEXシステムのためにスタンフォード大学、Bolt Beranek、およびニューマンInc.でそれぞれ完成しました。 今日、実装は多数のコンピュータ・システムのために存在します。これらが多く間、実装された、大学と他の研究グループによってサポートされて、数個が商品として利用可能であるということです。
Testing of TCP was done on the ARPANET (12), other DOD networks (Satellite net, packet radio), and a variety of local networks. For several years a number of DARPA contractors used TCP in parallel with the old ARPANET transport protocol (NCP). In addition, for about six months preceding the January 1, l983, ARPANET cutover from NCP to TCP, these hosts were joined by additional TCP-only hosts (for a total of approximately thirty). This extensive testing prior to the cutover to TCP enabled the networks involved to maintain operational capability throughout
アルパネット(12)、他のDODネットワーク(衛星ネット、パケットラジオ)、およびさまざまな企業内情報通信網でTCPのテストをしました。 数年間、多くのDARPA契約者が古いアルパネットトランスポート・プロトコル(NCP)と平行してTCPを使用しました。 さらに、NCPからTCPまで1月1、l983、アルパネットカットオーバに先行するおよそ6カ月これらのホストは追加TCPだけホスト(合計およそ30のための)によって加わられました。 TCPへのカットオーバの前のこの大規模なテストは運用能力を維持するためにかかわったネットワークを可能にしました。
----- (11) Transport Control Protocol, DOD MIL-STD-1778, August 1983.
----- (11) 1983年8月に制御プロトコル、DOD軍規格-1778を輸送してください。
(12) The ARPANET is a data communications network established in 1969 by the DOD's Advanced Research Projects Agency to interconnect the computer resources at selected research centers at substantially lower costs than systems then available. The ARPANET is a fully operational 80-node network that interconnects over 200 host computers in the United States, the United Kingdom, and Norway. ARPA became the Defense Advanced Research Projects Agency (DARPA) in 1973.
(12) アルパネットは1969年にその時選択されたリサーチセンターで実質的にシステムより低いコストで利用可能な状態でコンピュータリソースとインタコネクトするためにDODのAdvanced Research Projects Agencyによって確立されたデータ通信網です。 アルパネットは合衆国、イギリス、およびノルウェーの200以上のホストコンピュータとインタコネクトする完全に操作上の80ノードのネットワークです。 ARPAは1973年に国防高等研究計画庁(DARPA)になりました。
National Research Council [Page 25] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[25ページ]RFC942 1985年2月のレポート輸送
the transition and to achieve normal service levels in a few months. Today the TCP-based DOD networks includes hundreds of hosts (over 300 on DDN alone) and serves thousands of users. Traffic on just the ARPANET component is now approximately 500 million packets per month.
移行してください、そして、標準を達成するために、数カ月後にレベルを修理してください。 TCPベースのDODがネットワークでつなぐ今日は、何百人ものホスト(DDNだけの上の300以上)を含んで、何千人ものユーザに役立ちます。 現在、1カ月あたりまさしくアルパネットコンポーネントに関するトラフィックはおよそ5億のパケットです。
TCP is also extensively used on local area networks including Ethernet and Pronet, as well as on CSNET, the Computer Science Research Network (Telenet hosts).
また、TCPはイーサネットとPronetを含むローカル・エリア・ネットワークの上と、そして、CSNETの上で手広く使用されます、コンピュータScience Research Network(テレネットのホスト)。
In addition to TCP, the DOD protocol architecture includes internet layer protocols for communication between hosts and gateways (ICMP) and between gateways (GGP). Experience indicates that the design of robust and powerful gateways that internet numerous networks and provide survivability is a complex challenge. DOD is developing new gateway protocols that could be adapted to work with either DOD's or ISO's IP.
TCPに加えて、DODプロトコルアーキテクチャはホストとゲートウェイ(ICMP)とゲートウェイ(GGP)とのコミュニケーションのためのインターネット層のプロトコルを含んでいます。 提供してください。そして、経験がそれを示す、強健のデザイン、強力なゲートウェイがそのインターネットの多数のネットワークをそうする、生存性は複雑な難題です。 DODはDODかISOのどちらかのIPと共に働くために適合させることができた新しいゲートウェイプロトコルを開発しています。
The higher-level protocols currently used on DDN for electronic mail (Simple Mail Transfer Protocol), file transfer (File Transfer Protocol), and remote log-in (Telnet) are TCP-specific. Their specifications are stable, and numerous implementations exist. The DOD has indicated its intent to adopt ISO higher-level protocols when they are specified and implementations are available.
現在電子メール(シンプルメールトランスファプロトコル)、ファイル転送(ファイルTransferプロトコル)、およびリモート中のログ(telnet)にDDNで使用されている上位レベル・プロトコルはTCP特有です。 それらの仕様は安定しています、そして、多数の実装は存在しています。 DODは、それらが指定されるときISO上位レベル・プロトコルを採用する意図と実装が利用可能であることを示しました。
The committee has concluded that the DOD transport and internet protocols are well tested and robust. It is unlikely that major problems with their design or specifications will be uncovered. No comprehensive facility or procedures for testing new implementations of TCP now exist, although efforts in this area are being started at Defense Communications Agency (DCA).
委員会は、DOD輸送とインターネットプロトコルがよくテストされていて体力を要すると結論を下しました。 それらのデザインか仕様に関する大した問題が発見されるのは、ありそうもないです。 現在TCPの新しい実装をテストするためのどんな包括的な施設も手順も存在していません、この領域の取り組みはDefense Communications Agency(DCA)で始められていますが。
INTERNATIONAL STANDARDS ORGANIZATION
世界規格組織
Standardization and development of the ISO IP and ISO TP-4 are proceeding in a relatively independent fashion. Currently, TP-4 is further along in the standardization process. The local area network communications environment has created an immediate need for TP-4 functions; however, communications within a single Local Area Network (LAN) do not need an internet capability. A "null" IP has been defined to enable TP-4 to be used on a single LAN without the necessity of a complete IP. It is quite likely that some early TP-4 products will implement this null IP, leaving implementation of the complete IP for future product development. In the following discussion, TP-4 and IP will be treated separately due to this potential independence.
ISO IPとISO TP-4の標準化と開発は比較的独立しているファッションで続いています。 現在、TP-4は標準化過程でずっとより遠いです。 ローカル・エリア・ネットワークコミュニケーション環境はTP-4機能の即座の必要性を作成しました。 しかしながら、ただ一つのローカル・エリア・ネットワーク(LAN)の中のコミュニケーションはインターネット能力を必要としません。 「ヌル」のIPは、TP-4が単一のLANで完全なIPの必要性なしで使用されるのを可能にするために定義されました。 いくつかの早めのTP-4製品がこのヌルIPをかなり実装しそうでしょう、完全なIPの実装を将来の商品開発に残して。 以下の議論では、TP-4とIPはこの潜在的独立のため別々に扱われるでしょう。
TP-4 Status and Plans
TP-4状態とプラン
The ISO TP-4 became a Draft International Standard in September 1983. The final stages in standardization are primarily procedural. The committee expects products that implement TP-4 to be widely available in the market within about two years. It normally takes twelve to eighteen months for implementations and testing prior to product announcement. Some vendors apparently began implementation and testing the protocol
ISO TP-4は1983年9月に国際規格案になりました。 標準化における最終段階は主として手続き上です。 委員会はおよそ2年以内に市場でTP-4が広く利用可能であると実装する製品を予想します。 通常、それは実装と製品発表の前にテストするのに12〜18カ月かかります。 ベンダーの中には明らかに実装とプロトコルをテストし始めたものもありました。
National Research Council [Page 26] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[26ページ]RFC942 1985年2月のレポート輸送
soon after it became a draft proposal in June 1982, because the protocol was essentially frozen at that time.
プロトコルがその時本質的には凍ったので、それは1982年6月にすぐ後に、試案になりました。
At present, INTEL and Able Computer have announced the availability of products that implement TP-4 for use over LANs. The committee does not know, however, whether these products have been delivered or incorporated into systems. In addition, more than twenty companies have indicated their support of TP-4 and their intention to incorporate TP-4 into future products, without announcing specific products or availability dates. Most companies do not make specific product announcements until relatively late in the product development process.
現在のところ、インテルとAbleコンピュータはLANの上の使用のためにTP-4を実装する製品の有用性を発表しました。 しかしながら、委員会は、これらの製品がシステムに提供されるか、または組み入れられたかを知りません。さらに、20以上の会社が彼らのTP-4のサポートと将来の製品にTP-4を組み入れるという彼らの意志を示しました、特定生産品か使用可能日を発表しないで。 大抵の会社は製品開発工程に比較的遅れるまで特定生産品を発表にしません。
In December 1982 six vendors and network users interested in early development of TP-4 products requested NBS to hold a series of workshops on the operation of TP-4 in a LAN environment. To date, four workshops have been held, with more than thirty companies in attendance. The first workshop set a goal of demonstrating multivendor networking at a major U.S. national computer conference. The second workshop, held in April 1983, determined that demonstrations would include a file transfer application and would be developed on two local area network technologies currently standardized by the Institute of Electrical and Electronics Engineers (IEEE). These technologies are the Carrier Sense Multiple Access with Collision Detection, which is standardized by IEEE committee 802.3, and the Token Bus, which is standardized by IEEE committee 803.4. The workshop selected the National Computer Conference in July 1984 for the demonstrations.
12月に、TP-4製品の初期発生に興味を持っている1982人の6つのベンダーとネットワーク利用者が、LAN環境における、TP-4の操作に関する一連のワークショップを開くようNBSに要求しました。 これまで、4つのワークショップが30以上の会社で出席で開かれました。 最初のワークショップは主要な米国国家のコンピュータ会議に「マルチ-ベンダー」ネットワークを示すという目標を設定しました。 1983年4月に開かれた第2ワークショップは、デモンストレーションがファイル転送アプリケーションを含んでいることを決定して、現在米国電気電子技術者学会(IEEE)によって標準化されている2つのローカル・エリア・ネットワーク技術で開発されるでしょう。 (それは、IEEE委員会802.3によって標準化されます)。これらの技術は、衝突検出型搬送波検知多重アクセスとToken Busです。(Token BusはIEEE委員会803.4によって標準化されます)。 ワークショップは1984年7月にデモンストレーションのためにNationalコンピュータコンファレンスを選択しました。
Vendors committed to the demonstration developed and tested TP-4 implementations using the NBS test tools. The workshops defined a schedule that called for individual testing through April 1984 with multivendor testing commencing thereafter. While the vendors that participated in the demonstration have emphasized that participation in the demonstration is not a commitment to product development, a number of large customers have indicated that there will be an immediate market demand for TP-4 implementation as soon after the demonstration as practical. The committee considers it highly likely that many commercial vendors will announce commitments to deliver TP-4 products shortly after the demonstration.
デモンストレーションに心がけるベンダーは、NBSテスト・ツールを使用することでTP-4実装を開発して、テストしました。 ワークショップはその後始まって、「マルチ-ベンダー」がテストされている状態で個々の1984年4月までのテストを求めたスケジュールを定義しました。 デモンストレーションに参加したベンダーが、デモンストレーションへの参加が商品開発の委任でないと強調している間、多くの大口顧客が、TP-4実装を求める即座の市場の需要が実用的であるのとデモンストレーションの後に同じくらいすぐあるのを示しています。 委員会は、多くの商業ベンダーがデモンストレーションのすぐ後に製品をTP-4に提供する委任を非常に発表しそうであると考えます。
Internetwork Protocol Status and Plans
インターネットワークプロトコル状態とプラン
The ISO Internetwork Protocol (IP) became a Draft International Standard (DIS) in May 1984 (13). The DIS was out for ballot for the previous eight months. Attaining DIS status freezes the technical approach, permitting implementations to begin.
ISO Internetworkプロトコル(IP)は1984年5月の(13)で国際規格案(DIS)になりました。 前の8カ月DISは投票のためのものでした。 DIS状態に達すると、実装が始まるのを許容して、技術的なアプローチは凍ります。
----- (13) ISO Draft Proposal, Information Processing Systems -- Data Communications -- Protocol for Providing Connectionless Network Services, DP 8473, May 1984.
----- (13) ISO試案、情報処理システム(データ通信)は、1984年5月にコネクションレスなネットワーク・サービス、DP8473を提供するために議定書を作ります。
National Research Council [Page 27] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[27ページ]RFC942 1985年2月のレポート輸送
The ISO IP specification is only one of several specifications needed to completely specify the Network Layer. A number of other specifications are needed, including a Gateway-to-Host error protocol, a network wide addressing plan, and a Gateway-to-Gateway Protocol for managing routing information. A complete specification is needed before an internetwork, consisting of gateways and hosts, can be deployed. Most of the complexity of the Network Layer, however, is confined to the gateways. A complete standardization of the Network Layer is not required to develop and deploy host systems.
ISO IP仕様はNetwork Layerを完全に指定するのに必要であるいくつかの仕様の1つにすぎません。 ゲートウェイからホストへの誤りプロトコルを含んで、他の多くの仕様が必要であり、ネットワークが広いアドレシングプランであり、ゲートウェイからゲートウェイは、ルーティング情報を管理するためのプロトコルです。 ゲートウェイとホストから成って、インターネットワークを配布することができる前に完全な仕様が必要です。 しかしながら、Network Layerの複雑さの大部分はゲートウェイに閉じ込められます。 Network Layerの完全な規格化は、展開して、ホストにシステムを配布するのに必要ではありません。
The International Standards Organization is currently developing proposals for conveying error information between hosts and gateways. It is expected that responses to the Draft Proposal by ISO members will include proposals to provide these functions. The committee does not consider this a controversial area and expects that these capabilities will be included in the ISO standard by the time it reaches Draft International Status.
国際Standards Organizationは現在、ホストとゲートウェイの間にエラー情報を伝えるための提案を開発しています。 ISOメンバーによるDraft Proposalへの応答がこれらの機能を提供するという提案を含むと予想されます。 Draftの国際Statusに達する時までに、委員会は、これが論議を呼んだ領域であると考えないで、これらの能力がISO規格に含まれると予想します。
Addressing is a more complex issue. The addressing structure of a computer internetwork depends on complex trade-offs between implementation complexity, flexibility, network cost, and network robustness. Addressing structure in a large network can influence the range of possible policy decisions available for routing network traffic. The trade-offs for a military environment may be significantly different from those of a commercial environment. The ISO has considered these factors in its existing IP. A flexible addressing scheme is provided, permitting implementation of a variety of addressing structures. Host computers need not be concerned with the internal structure of addresses. The committee considers that the IP-addressing scheme has sufficient flexibility that host implementations can be constructed that will support the full range of addressing philosophies allowed by ISO, including those needed by DOD.
アドレシングは、より複雑な問題です。 コンピュータインターネットワークのアドレシング構造は実装の複雑さと、柔軟性と、ネットワーク費用と、ネットワーク丈夫さの間の複雑なトレードオフに依存します。 大きいネットワークで構造を扱うと、ルーティングネットワークトラフィックに利用可能な可能な政策決定の範囲に影響を及ぼすことができます。 軍事環境のためのトレードオフは商業環境のものとかなり異なっているかもしれません。 ISOは既存のIPのこれらの要素を考えました。 さまざまなアドレシング構造の実装を可能にして、フレキシブルなアドレシング体系を提供します。 ホストコンピュータはアドレスの内部の構造に関係がある必要はありません。 委員会は、ホスト導入が十分な柔軟性であるかもしれませんが、組み立てられて、体系が持っているそうするIP-アドレシングがISOによって許容された最大限の範囲のアドレシング哲学をサポートすると考えます、DODによって必要とされたものを含んでいて。
Routing algorithms, like addressing, are complex and often controversial. For this reason ISO has not yet attempted standardization of routing algorithms. A routing algorithm is a key part of a Gateway-to-Gateway Protocol. A single network must implement a common routing algorithm. In the absence of an ISO routing algorithm, a network must be based on either proprietary routing algorithms or on other standards.
アドレシングのように、ルーティング・アルゴリズムは、複雑であって、しばしば論議を呼んでいます。 この理由で、ISOはまだルーティング・アルゴリズムの標準化を試みていません。ルーティング・アルゴリズムはゲートウェイからゲートウェイへのプロトコルの主要な部分です。 ただ一つのネットワークは一般的なルーティング・アルゴリズムを実装しなければなりません。 ISOルーティング・アルゴリズムがないとき、独占ルーティング・アルゴリズムに基づいた他の規格の上にネットワークがあるに違いありません。
The committee has studied the current ISO IP and the current ISO addressing structure. It believes that it will be possible to map the current DOD IP-addressing structure and routing algorithm into the ISO network layer. In practice this means that the Gateway-to-Host Protocols and addressing formats will fully comply with the ISO standards, while gateways will need to include additional DOD capabilities. (This is addressed in recommendations, section IX.) This approach will enable DOD to procure commercial host implementations, while retaining the need for procuring DOD-specific gateways. The committee believes these hybrid DOD-ISO gateways can be readily developed by modifying existing DOD gateway implementations. Since the majority of systems in a network are hosts and not gateways,
委員会は現在のISO IPと構造を扱う現在のISOを研究しました。 現在のDOD IPを扱っている構造とルーティング・アルゴリズムをISOネットワーク層に写像するのが可能であることは信じています。 実際には、これは、ゲートウェイからホストへのプロトコルとアドレス指定形式がISO規格に完全に従うことを意味します、ゲートウェイは、追加DOD能力を含む必要があるでしょうが。 (これは推薦、セクションIXで扱われます。) このアプローチは、DOD特有のゲートウェイを調達する必要性を保有している間、DODが商業ホスト導入を調達するのを可能にするでしょう。 委員会は、既存のDODゲートウェイ実装を変更することによって容易にこれらのハイブリッドDOD-ISOゲートウェイを開発できると信じています。 以来、ネットワークにおけるシステムの大部分がゲートウェイではなく、ホストです。
National Research Council [Page 28] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[28ページ]RFC942 1985年2月のレポート輸送
the committee considers this approach worthwhile.
委員会は、このアプローチ価値があると考えます。
To the committee's knowledge no vendor has yet announced plans to support the ISO Internetwork Protocol. This is not surprising, since the ISO IP attained Draft Proposal status only recently. The committee has considered the possibility that the ISO IP may not attain the same wide level of market demand and vendor support anticipated by TP-4. Since host support of IP is necessary for DOD to migrate to ISO protocols, the committee has considered this question in some depth.
委員会のものが知っている限り、どんなベンダーもまだISO Internetworkがプロトコルであるとサポートする計画を発表していません。 ISO IPが最近だけDraft Proposal状態に達したので、これは驚くべきものではありません。 委員会はISO IPがTP-4によって予期された同じ広いレベルの市場の需要とベンダーサポートに達しないかもしれない可能性を考えました。 DODがISOプロトコルにわたるのにIPのホストサポートが必要であるので、委員会は何らかの深さでこの質問を考えました。
While it is possible to operate TP-4 directly over a LAN or directly over an X.25-based, wide-area network, some form of internetwork capability or alternative approach is needed to interconnect systems attached to multiple LANs via Wide Area Networks (WANs). In the current ISO open systems architecture, this function is to be provided by the Network layer. There are two possible Network layer services, connectionless and connection oriented. The ISO architecture permits both of these services, leaving it to the market place to determine which approach is to be selected. The DOD believes that the connectionless approach best suits their needs.
LANの直接上、または、X.25ベースの広域ネットワークの直接上でTP-4を操作するのが可能である間、何らかの形式のインターネットワーク能力か代替的アプローチが、ワイドエリアネットワーク(WAN)で複数のLANに取り付けられたシステムとインタコネクトするのに必要です。 現在のISOオープンシステムアーキテクチャに、この機能はNetwork層のそばで提供することです。 Networkがコネクションレスで接続指向のサービスを層にするのが可能な2があります。 ISOアーキテクチャはこれらのサービスの両方を可能にします、選択されるためにアプローチがどれであるか決定するように市場に任せて。 DODは、コネクションレスなアプローチが彼らの必要性に最もよく合うと信じています。
Developing a connection-oriented network that operates over a mixed LAN and WAN environment is considerably more difficult than developing a connectionless one. Existing LANs are inherently connectionless and existing (X.25) WANs are inherently connection oriented. A protocol to provide internetwork service between these LANs must arrive at a common subnetwork capability. It is a relatively simple matter to adapt a connection-oriented to a connectionless service since it can be done by ignoring unneeded functions of the connection-oriented service. Adapting a connectionless subnetwork to the needs of a connection-oriented network service is much more difficult. Many of the functions provided by TP-4 would be needed in the network layer to build such a service.
複雑なLANとWAN環境の上で作動する接続指向のネットワークを発展させるのはコネクションレスなものを開発するよりかなり難しいです。 既存のLANは本来コネクションレスです、そして、本来既存の(X.25)WANは適応する接続です。 これらのLANの間に相互ネットワーク・サービスを提供するプロトコルは一般的なサブネットワーク能力に到着しなければなりません。 コネクション型サービスの無視することによってそれができて以来のコネクションレス型サービスへの接続指向の不要な機能を適合させるのは、比較的簡単な問題です。 接続指向のネットワーク・サービスの必要性にコネクションレスなサブネットワークを適合させるのははるかに難しいです。 TP-4によって提供された機能の多くが、そのようなサービスを組み込むのにネットワーク層で必要でしょう。
Some work is currently going on in European Computer Manufacturer's Association (ECMA) to interconnect WANs and LANs in a connection-oriented fashion. There is considerable controversy surrounding several proposals, since some participants in the standards process do not believe the proposals conform to the ISO Reference Model for Open Systems Interconnection. This, plus their complexity, makes it unlikely that a connection-oriented network standard will gain support in ISO in the immediate future.
いくらかの仕事が、現在、ヨーロッパのコンピュータManufacturerのAssociation(ECMA)で接続指向のファッションでWANとLANとインタコネクトし続けています。 いくつかの提案を囲む大きな論争があります、標準化過程の何人かの関係者が、提案がオープン・システム・インターコネクションのためのISO Reference Modelに従うと信じていないので。 これ、およびそれらの複雑さで、接続指向のネットワーク規格がISOでもっとも近い将来においてサポートを獲得するのがありそうもなくなります。
There is an immediate need for users to build networks consisting of interconnected LANs and WANs. Such networks are currently in place using vendor proprietary architectures. Market pressures to build multivendor LAN and WAN networks make it quite likely that vendors will adopt the immediate solution and implement the connectionless ISO IP. The committee believes that DOD can enhance the early availability of ISO IP by announcing its intention to use it. Commercial availability of IP is an important part of a migration strategy, as described in the section on recommendations. The
ユーザがインタコネクトされたLANとWANから成るネットワークを造る即座の必要があります。 そのようなネットワークが、現在適所にベンダーの独占アーキテクチャを使用することであります。 「マルチ-ベンダー」LANとWANネットワークを築き上げる市場圧で、ベンダーが即座のソリューションを採用して、コネクションレスなISO IPを実装するのがかなりありそうになります。 委員会は、DODがそれを使用するという意志を発表することによってISO IPの早めの有用性を高めることができると信じています。 IPの商業有用性は推薦のときにセクションで説明されるように移行戦略の重要な部分です。 The
National Research Council [Page 29] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[29ページ]RFC942 1985年2月のレポート輸送
committee believes that vendors would be responsive to DOD requests for IP, since IP is quite simple to implement in comparison with TP-4 and since they foresee the need to operate in mixed LAN-WAN environments.
委員会は、ベンダーがIPを求めるDOD要求に敏感であると信じています、IPはTP-4との比較で実装するのがかなり簡単であり、複雑なLAN WAN環境で作動する必要性について見通すので。
National Research Council [Page 30] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[30ページ]RFC942 1985年2月のレポート輸送
V. MARKETS
V.市場
The committee reviewed the market demand and its potential with respect to both TCP and TP-4 to provide an indication of the likelihood and rapidity with which competition and its benefits will develop. The committee concludes that the market demand for TCP protocols will be small outside the United States. The demand for TP-4, on the other hand, is expected to be worldwide.
委員会は市場の需要と競争とその利益が展開する見込みと急速のしるしを供給するTCPとTP-4の両方に関するその可能性を見直しました。 委員会は、TCPプロトコルを求める市場の需要が合衆国の外で小さくなると結論を下します。 他方では、TP-4の需要が世界中にあると予想されます。
In this report we use the term market demand to indicate the potential or actual demand for products using the protocols under discussion. A large market is characterized by a broad demand from all sectors of the marketplace: consumers, businesses, and governments. The broadest demand is an international demand in all sectors. We distinguish the demand for products from the supply that usually develops as a result of the demand. It is assumed here that a broad market demand will result in a broad range of products, competitive in price, quality, function, and performance.
このレポートでは、私たちは製品のために議論でプロトコルを使用することで可能性か実需を示すという用語市場の需要を使用します。 大きな販路は市場のすべてのセクターからの広い要求で特徴付けられます: 消費者、ビジネス、および政府。 最も広い要求はすべてのセクターで国際的な要求です。 私たちは通常、要求の結果、展開する供給と製品の需要を区別します。 ここで好況市場要求が広範囲な製品をもたらすと思われます、価格、品質、機能、および性能では、競争力があります。
The demand for products implementing computer communication protocols is discussed in relation to the requirements placed on the potential customer. Specifically, the customer may be required to acquire products that meet one or the other of the standards under discussion or may have no obligation to use either of the two. That is, customers will fall into one of the following classes with respect to these standards:
見込み客に置かれた要件と関連してコンピュータ通信プロトコルを実装する製品の需要について議論します。 明確に、顧客には、議論で規格の1かもう片方を満たす製品を入手するのが必要でない、2つのもののどちらかを使用する義務が全くないかもしれません。 すなわち、顧客はこれらの規格に関して以下のクラスの1つになるでしょう:
1. DOD standards required.
1. DOD規格が必要です。
2. International or National standards required.
2. 国際かNational規格が必要です。
3. No requirement with respect to standards.
3. 規格に関する要件がありません。
Although customers in the third class may be under no formal obligation to use standards, they may still prefer a standard solution for several possible real or perceived benefits. They may, for example, obtain a broader selection of products using the standard solution or may obtain a more competitive price. They may also require a specific communication protocol in order to share information with products that are required by fiat to implement certain standard protocols. This need for compatible protocols to communicate is a powerful driving force toward communication standards.
3番目のクラスの顧客が規格を使用するどんな正式な義務の下にもいないかもしれませんが、彼らはまだいくつかの可能な本当の、または、知覚された利益の標準液を好んでいるかもしれません。 彼らは、例えば、標準液を使用することで製品の、より広い品揃えを得るか、または、より他社にひけをとらない価格を得るかもしれません。 また、彼らは、ある標準プロトコルを実装するのに法令で必要である製品と情報を共有するために特定の通信プロトコルを必要とするかもしれません。 コンパチブルプロトコルが交信するこの必要性はコミュニケーション規格に向かった強力な原動力です。
DEPARTMENT OF DEFENSE NETWORKS MARKET STATUS AND PLANS
国防総省ネットワークは状態とプランを売り出します。
The major networks of the Defense Data Network include the following:
Defense Data Networkの主要なネットワークは以下を含んでいます:
National Research Council [Page 31] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[31ページ]RFC942 1985年2月のレポート輸送
Military Network (MILNET)--operational and growing.
軍用のNetwork(MILNET)--操作上であって増加しています。
Advanced Research Projects Agency Network (ARPANET)--operational and growing.
高等研究計画局ネットワーク(アルパネット)--操作上であって増加しています。
WWMCCS Intercomputer Network (WIN)--to be upgraded.
WWMCCS Intercomputer Network(WIN)--アップグレードするように。
DOD Intelligence Information System (DODIIS)--to be upgraded.
DOD Intelligence情報システム(DODIIS)--アップグレードするように。
Strategic Air Command Digital Information Network (SACDIN)--to be upgraded.
戦略空軍Digital情報Network(SACDIN)--アップグレードするように。
Movement Information Network (MINET)--to be established in 1984.
動き情報Network(MINET)--1984年に証明されるために。
Sensitive Compartmented Information (SCI) net--to be established in 1985.
機密のCompartmented情報(SCI)ネット--1985年に証明されるために。
TOP SECRET (TS) net--to be established in 1985.
TOP SECRET(TS)ネット--1985年に証明されるために。
SECRET net--to be established in 1986.
SECRETネット--1986年に証明されるために。
Initially, each of these networks has its own backbone. The networks will be integrated into a common Defense Data Network in a series of phases starting in 1984 with the integration of MILNET and MINET. It is planned that by 1988 they will all be integrated but communities of interest will operate at different security classifications interconnected with Internet Private Line Interfaces (IPLIs). When appropriate technology becomes available in the late 1980s, the network will have the capability for multilevel security, including end-to-end encryption, and will achieve interoperability between all users.
初めは、それぞれのこれらのネットワークには、それ自身のバックボーンがあります。 ネットワークは一般的なDefense Data Networkに1984年にMILNETとMINETの統合から始まる一連のフェーズに統合されるでしょう。 それは計画されています。1988年までには、すべて統合するようになりますが、興味がある共同体が異なったセキュリティ分類のときに作動するのがインターネットで兵士の線Interfaces(IPLIs)とインタコネクトしました。 適正技術が1980年代後半に利用可能になると、ネットワークは、終端間暗号化を含む多レベルセキュリティのために能力を持って、すべてのユーザの間に相互運用性を実現するでしょう。
The following observations are relevant to the TCP and TP-4 issue:
以下の観測はTCPとTP-4問題に関連しています:
The DOD currently has two major networks, MILNET and ARPANET, currently comprising the DDN. About sixty subnets and hundreds of hosts are internetted and most use TCP.
DODには、現在DDNを包括して、現在、2つの主要なネットワーク、MILNET、およびアルパネットがあります。 ホストのおよそ60のサブネットと数百がinternettedされます、そして、大部分はTCPを使用します。
This year a European network, MINET, will be activated and integrated into the DDN. It uses TCP.
今年、ヨーロッパのネットワーク(MINET)は、DDNと動かされて、統合されるでしょう。 それはTCPを使用します。
In the second half of 1983, fifteen additional subscribers have been added to MILNET and current planning estimates hundreds more additional subscribers in 1984 and 1985.
1983年の後半に、15人の追加加入者がMILNETに言い足されました、そして、現在の計画は1984年と1985年に数百が、より多くの追加加入者であると見積もっています。
For the many DDN users that are, or shortly will be, interconnected over common backbones, there are groups of users that need interoperability within the group. These groups are determined by the military department they are part of as well as by functions such as logistics, maintenance, training, and many others.
あるか、またはまもなく、あって、一般的なバックボーンの上で内部連絡した多くのDDNユーザのために、グループの中で相互運用性を必要とするユーザのグループがあります。 これらのグループは軍事省によって決定されて、それらが機能とロジスティクスなどの機能による部分です、メインテナンス、トレーニングということであり、多くが他のものです。
The Air Force and the Army are both committed to the use of TCP for some of their networks or subnetworks (including Local Area
空軍と陸軍がともにTCPのそれらのネットワークかいくつかのサブネットワークの使用に心がける、(Local Areaを含んでいること。
National Research Council [Page 32] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[32ページ]RFC942 1985年2月のレポート輸送
Networks) and active acquisition programs are underway, or will be initiated, during the next twelve to eighteen months.
ネットワーク、)、活発な獲得プログラムは、進行中である、または次の12〜18カ月開始されるでしょう。
The DDN Program Office has procured, or shortly will procure, devices to facilitate terminal and host access to DDN hosts and terminals. These devices employ TCP.
DDN Programオフィスは、端末を容易にするデバイスとDDNホストと端末へのホストアクセスを調達して、まもなく、調達するでしょう。 これらのデバイスはTCPを使います。
NATO has discussed protocol standards and has selected ISO as an approach, subject to its being adapted to meet military requirements, if such adaptation is necessary. There is no definitive planning underway, however, to develop a NATO computer network.
NATOは、プロトコル標準について議論して、それが適合していることを条件としたアプローチとしてのISOが軍事の必要条件を満たすのを選択しました、そのような適合が必要であるなら。 しかしながら、NATOコンピュータネットワークを開発するためには進行中の決定的な計画がありません。
The Mail Bridge that will allow traffic to pass between the classified segment and the unclassified segment will use TCP and is scheduled for a 1987 Initial Operational Capability (IOC).
トラフィックを分類されたセグメントと非分類されたセグメントの間で終わらせるメールBridgeはTCPを使用して、1987Initial Operational Capability(IOC)のために予定されています。
In general, the backbone in the various networks provides functions at layers below TCP and TP-4. As a result a backbone (such as MILNET) could support users of either protocol set. The users of one set could not, however, interoperate with the users of another unless additional steps are taken.
一般に、様々なネットワークにおけるバックボーンはTCPとTP-4の下の層で機能を提供します。 その結果、バックボーン(MILNETなどの)はどちらかのプロトコルセットのユーザをサポートするかもしれません。 しかしながら、追加方法が取られない場合、1セットのユーザは別のもののユーザと共に共同利用しないかもしれません。
In summary, there is a large TCP community operational today and the community is growing rapidly. In addition, there are, or shortly will be, procurements underway that plan to use TCP. The rate of growth cannot be precisely estimated in part because of uncertainties in demand and availability of trunks and cryptographic equipment. On the other hand, interconnection of several major networks will not take place until 1987 or later; and for those elements that are interconnected, there are many groups of users that primarily require interoperability with each other.
概要には、今日操作上の大きいTCP共同体があります、そして、共同体は急速に発展しています。 さらに、あるか、またはまもなく、あって、進行中の調達はTCPを使用するその計画です。 トランクスと暗号の設備の要求と有用性の不明確なことのために正確に成長率を一部見積もることができません。 他方では、いくつかの主要なネットワークのインタコネクトは1987年以降まで行われないでしょう。 そして、インタコネクトされるそれらの要素のために、主として互いがある相互運用性を必要とするユーザの多くのグループがあります。
System Descriptions
システム記述
MILNET is a network for handling the unclassified operational data of the DOD. It was created after the decision in 1982 to cancel the AUTODIN II system by dividing the ARPANET into two nets, MILNET and ARPA Research Net. The majority of the capacity of ARPANET was assigned to MILNET, and the number of subscribers is growing rapidly. The network backbone does not require the use of TCP but its use is generally mandated for subscribers. To achieve TCP functions, the DDN will procure some interface devices and thereby take the burden off some subscribers.
MILNETは、DODの非分類された操作上のデータを扱うためのネットワークです。 それは、1982年の決定の後にアルパネットを2つのネット、MILNET、およびARPA Researchネットに分割することによってAUTODIN IIシステムを取り消すために作成されました。 アルパネットの容量の大部分がMILNETに選任されました、そして、加入者の数は急速に成長しています。 ネットワーク基幹はTCPの使用を必要としませんが、一般に、使用は加入者のために強制されます。 DDNは、TCP機能を獲得するために、いくつかのインタフェース機器を調達して、その結果、何人かの加入者から負担を取るでしょう。
ARPANET supports most of the research organizations sponsored by DARPA. It generally uses TCP but some users continue to use NCP.
アルパネットはDARPAによって後援された研究組織の大部分をサポートします。 それは一般にTCPを使用しますが、何人かのユーザが、NCPを使用し続けています。
MINET is a European network scheduled for Initial Operational Capability (IOC) in 1984 to handle unclassified operational traffic, mostly logistical, and tie into the MILNET. It will have 8 nodes, 8 TACs, and 3 hosts to process electronic mail. These hosts and others to be added to the net will use TCP and the File Transfer Protocol (FTP).
MINETは1984年のInitial Operational Capability(IOC)が非分類された操作上のほとんどロジスティクスのトラフィックを扱って、MILNETを激しく攻撃する予定であったヨーロッパのネットワークです。 それには、電子メールを処理するために、8つのノード、8TACs、および3人のホストがいるでしょう。 ネットに追加されるべきこれらのホストと他のものはTCPとFile Transferプロトコル(FTP)を使用するでしょう。
National Research Council [Page 33] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[33ページ]RFC942 1985年2月のレポート輸送
The Department of Defense Intelligence Information System currently uses a home-grown protocol. Sometime after 1984 its plans are to upgrade it to TCP. It will be a 3-node, 3-host net with plans to upgrade it to 20 to 30 nodes and about 50 hosts. The net is run at a high-security level (SCI) for communicating compartmented data. The SCI network consists of those users of SCI who are outside of DODIIS.
国防総省Intelligence情報システムは現在、国産のプロトコルを使用します。 1984年以降いつか、プランはそれをTCPにアップグレードさせることです。 それは3ノード(20〜30のノードとおよそ50人のホストにそれをアップグレードさせる計画を伴う3ホストのネット)でしょう。 ネットは、compartmentedデータを伝えるために高いセキュリティー・レベル(SCI)で実行されます。 SCIネットワークはDODIISの外にいるSCIのそれらのユーザから成ります。
SACDIN is an upgrade of the digital communications system of the Strategic Air Command. The IOC is planned for about 1985. At present, TCP is not planned initially as a protocol. SACDIN will operate with multilevel security up to Top Secret sensitive information.
SACDINは戦略空軍のディジタル通信システムのアップグレードです。 IOCは1985年頃のために計画されています。 現在のところ、TCPは初めは、プロトコルとして計画されていません。 SACDINは多レベルセキュリティでTop Secret機密情報まで作動するでしょう。
WIN is the WWMCCS Information Network. It is currently operational and uses NCP as a transport protocol. There is a major effort underway to modernize the WWMCCS, including upgrading or replacing current computers, providing Local Area Networks at major centers throughout the world, and providing common software packages for utilities and some applications. The upgrading of the transport protocols is part of this effort. Schedules are still uncertain but there is a target of 1986 for the protocol upgrading.
WINはWWMCCS情報Networkです。 それは、現在、操作上であり、トランスポート・プロトコルとしてNCPを使用します。 WWMCCSを近代化するためには進行中の主要な取り組みがあります、現在のコンピュータをアップグレードするか、または取り替えるのを含んでいて、世界中の主要なセンターでローカル・エリア・ネットワークを提供して、ユーティリティといくつかのアプリケーションに一般的なソフトウェアパッケージを提供して。 トランスポート・プロトコルのアップグレードはこの取り組みの一部です。 スケジュールはまだ不確実ですが、プロトコルアップグレードのための1986年の目標があります。
TOP SECRET is a network that will support top secret users other than WIN and SACDIN.
TOP SECRETはWINとSACDIN以外の最高機密ユーザをサポートするネットワークです。
SECRET net is a network that will operate at the Secret level. It should be very useful for a large community that does not routinely need top secret or compartmented information. This is a community primarily outside the command and intelligence communities and includes missions such as logistics, procurement, and research and development. DOD will start the system as soon as there is sufficient cryptographic equipment; by 1986 they hope to have a 90-node network with several hundred subscribers.
SECRETネットはSecretレベルで作動するネットワークです。 それは非常にきまりきって最高機密かcompartmented情報を必要としない大きい共同体の役に立つべきです。 これは、主としてコマンドと情報機関の外の共同体であり、ロジスティクスや、調達や、研究開発などの任務を含んでいます。 十分な暗号の設備があるとすぐに、DODはシステムを始動するでしょう。 1986年までには、彼らは、数100人の加入者との90ノードのネットワークを持っていることを望んでいます。
The Army plans to establish a Headquarters Net tying together major headquarters with an IOC of 1986. It will use TCP.
陸軍は、1986年のIOCで主要な本部を結びつけながら、本部ネットを確立するのを計画しています。 それはTCPを使用するでしょう。
The Air Force has established a Program Office to help in the development of Local Area Networks at major Air Force installations. These could be internetted using the DDN and thereby also gain access to other nodes. TCP has been mandated. Initial procurements are underway.
空軍は、主要な空軍施設のときにローカル・エリア・ネットワークの開発で助けるためにProgramオフィスを設立しました。 これらは、DDNを使用することでinternettedされて、その結果、また、他のノードへのアクセスを得るかもしれません。 TCPは強制されました。 初期の調達は進行中です。
Mail Bridge will provide gateways between ARPA Research Net and other elements of the DDN. These would use TCP and are scheduled for IOC in 1987.
メールBridgeはDDNのARPA Researchネットと他の要素の間にゲートウェイを供給するでしょう。 これらは、TCPを使用して、1987年のIOCのために予定されています。
During 1984 the DDN is procuring two capabilities that will facilitate use of the network and higher-level protocols.
1984の間、DDNはネットワークと上位レベル・プロトコルの使用を容易にする2つの能力を調達しています。
The first capability will be provided shortly by Network Access Controllers (NAC). The NACs provide three elements all based on TCP:
最初の能力はすぐNetwork Access Controllers(NAC)によって提供されるでしょう。 NACsはTCPにすべて基づく3つの要素を提供します:
National Research Council [Page 34] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[34ページ]RFC942 1985年2月のレポート輸送
1. Terminal Access Controllers (TACs) allow a cluster of terminals
to access hosts on the DDN. Many are in operation today as a
legacy of the ARPANET developments. New ones will be
competitively procured.
1. 端末のAccess Controllers(TACs)は端末のクラスタをDDNでホストにアクセスさせます。 多くが今日、アルパネット開発のレガシーとして稼働中です。 新しいものを競争的に調達するでしょう。
2. Terminal Emulation Processes (TEP) allow the connection of a
high-capacity host to the DDN through a number of terminal-like
lines.
2. 端末のEmulation Processes(TEP)は多くの端末のような系列を通して高容量ホストの接続をDDNに許します。
3. Host Front-End Processors (HFP) allow high-capacity host
connection to the DDN through use of a Network Front End that
off loads much processing capacity from the host.
3. ホストFront-終わりのProcessors(HFP)はホストからそんなにオフなNetwork Front Endの使用によるDDNとの接続が積み込む高容量ホストに多くの処理容量を許容します。
The second capability will be provided by software the DDN is currently procuring for up to seventeen families of specific combinations of hosts and their commercially available operating systems. The software packages will include 1822 or X.25, TCP, and utility protocols for terminal access, mail, and file transfer. Initial operational capability is planned for late 1985.
DDNはソフトウェアによる、ホストの特定の組み合わせの17のファミリーまで現在の調達と彼らの商業的に利用可能なオペレーティングシステムです。2番目の能力は、端末のアクセス、メール、およびファイル転送のためにソフトウェアパッケージが1822を含むだろうか、そして、またはX.25と、TCPと、ユーティリティプロトコルになるでしょう。 初期の運用能力は1985年後半のために計画されています。
Integration
統合
MINET will be connected to MILNET in 1984. This will be an unclassified network.
MINETは1984年にMILNETに接続されるでしょう。 これは非分類されたネットワークになるでしょう。
WIN, DODIIS, SECRET, and SACDIN will be integrated as a classified network in 1987 at the earliest. Since they all operate at different security levels, they will be able to use the same DDN backbone but will be cryptologically isolated.
Win、DODIIS、SECRET、およびSACDINは1987年に分類されたネットワークとして最も早いところで統合するでしょう。 彼らが皆、異なったセキュリティー・レベルで作動するので、それらは、同じDDNバックボーンを使用できますが、cryptologicallyに孤立するでしょう。
Integration and interoperability of all the networks will not be possible until the late 1980s at the earliest, since this will require successful implementation of an advanced technology for end-to-end cryptological networking and the development of techniques for multilevel security in individual and netted computer systems.
すべてのネットワークの統合と相互運用性は最も早いところで1980年代後半まで可能にならないでしょう、これが終わりから終わりへのcryptologicalネットワークのための先進技術と個々の、そして、網で覆われたコンピュータ・システムにおける多レベルセキュリティのためのテクニックの開発のうまくいっている実装を必要とするので。
The use of gateways as elements to integrate networks is under consideration. Gateways are currently operational to interconnect MILNET with (l) ARPANET (six gateways primarily used to exchange mail between authorized users), (2) MINET (one gateway for use prior to integration of the two networks into one), and (3) eight developmentally oriented networks. There are many more gateways internetting ARPANET with other research nets. Most of these gateways use the ARPA-developed Gateway-to-Gateway Protocol. It is now realized that this protocol is deficient for widespread use and ARPA has been investigating alternatives.
ネットワークを統合する要素としてのゲートウェイの使用は考慮中であります。 ゲートウェイは、現在、(l) アルパネット(6門は主として以前は認定ユーザの間でよくメールを交換していた)、(2) MINET(1つへの2つのネットワークの統合の前の使用のための1門)、および(3) 8つの開発上に指向のネットワークと共にMILNETとインタコネクトするために操作上です。 他の研究ネットでアルパネットをinternettingするずっと多くのゲートウェイがあります。 これらのゲートウェイの大部分はゲートウェイからゲートウェイへのARPAによって開発されたプロトコルを使用します。 今、普及使用に、このプロトコルが不十分であることが実現されて、ARPAは代替手段を調査しています。
The earliest requirement for additional gateways in the operational elements of the DDN will be to internet Local Area Networks into global networks of the DDN. A new "stub" protocol has been developed that might meet this need. The DDN is reviewing its requirements for available gateways and approaches.
DDNの世界的なネットワークへのインターネットローカル・エリア・ネットワークにはDDNの演算要素の追加ゲートウェイのための最も早い要件があるでしょう。 この需要を満たすかもしれない新しい「スタッブ」プロトコルを開発してあります。 DDNは利用可能なゲートウェイとアプローチのための要件を再検討しています。
National Research Council [Page 35] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[35ページ]RFC942 1985年2月のレポート輸送
INTERNATIONAL AND NATIONAL STANDARD MARKET DEMAND FOR TP-4
TP-4を求める国際的で国家の標準の市場の需要
In the United States and most countries of the world, national standards organizations adopt international data communication standards.
合衆国と大部分では、世界の国であり、国家規格組織は国際的なデータ通信規格を採用します。
In the United States the standards for the transport protocols are established by the American National Standards Institute (ANSI). The same standards for the federal sector are established by the NBS with an exception for DOD's military needs which may be established by MIL standards. Market demand for the latter was previously discussed.
合衆国に、トランスポート・プロトコルの規格はAmerican National Standards Institut(ANSI)によって確立されます。 連邦のセクターの同じ規格はMIL規格によって確立されるかもしれないDODの軍事の必要性のために例外があるNBSによって確立されます。 以前に、後者を求める市場の需要について議論しました。
Outside the DOD there are numerous government agencies and organizations such as the Federal Aviation Agency, Internal Revenue Service, the Federal Bureau of Investigation, and the Federal Reserve Banks which have, or will have, networks that fall under the guidance of the NBS and will probably use the NBS-specified standard protocols when the NBS standard is issued. Already the Federal Reserve is procuring its computer networking products using the X.25 protocol.
外では、そこのDODはNBS規格が発行されるとき、NBSによって指定された標準プロトコルを持つか、持って、その秋にNBSの指導の下にネットワークでつないで、またはたぶん使用する連邦航空庁や、国税庁、連邦捜査局や、連邦準備制度理事会バンクスなどの多数の政府機関と組織です。 既に、連邦準備制度理事会は、X.25プロトコルを使用することでコンピュータネットワーク製品を調達しています。
National Support of International Standards
世界規格の国家のサポート
The earliest evidence of demand for TP-4 products is in countries that give strong support for ISO standards. Most countries outside of the United States give the international standards much stronger governmental support than the United States does for a variety of reasons. First, in most cases these governments own the postal and telecommunication monopolies. Frequently, the responsibility for these organizations is at a ministerial level in the government. Furthermore, many of the modern countries have concluded that the information industry is a national resource and one of the growth industries of the future. International standards that are neutral, in the sense that no manufacturer has a head start, give the companies in these countries the additional margin they feel is necessary to compete in the worldwide market. It is also recognized by many that a worldwide market is much better than a market demand fragmented by national geographic and political considerations. Finally, the PTTs have traditionally provided information services equivalent to those for which some of the ISO computer communication protocols are designed. The best example is Teletext, which is an upgraded version of the Telex system used widely outside the United States.
TP-4製品の需要の最も初期の証拠がISO規格の強力な支持を与える国にあります。 合衆国における外のほとんどの国が合衆国がさまざまな理由でそうするよりはるかに強い政府のサポートを世界規格に与えます。 多くの場合、まず最初に、これらの政府は郵便と電気通信独占を所有しています。 頻繁に、これらの組織への責任が聖職者のレベルに政府であります。 その上、近代的な国の多くが、情報産業が国家のリソースと未来の成長産業の1つであると結論を下しました。 どんなメーカーにも有利なスタートがないという意味で、中立である世界規格は彼らが世界的な市場に参加するのに必要であると感じる追加証拠金をこれらの国の会社に与えます。 また、多くで、世界的な市場が市場の需要が国家の地理的で政治上の問題で断片化したよりはるかに良いと認められます。 最終的に、PTTはISOコンピュータ通信プロトコルのいくつかが設計されているそれらに同等な情報サービスを伝統的に提供しました。 最も良い例はTeletextです。(そのTeletextは合衆国の外で広く使用されるTelexシステムのアップグレードしたバージョンです)。
Consequently, government networks in many countries use the international ISO standards or the national standards derived from the international standards. Bid requests for government networks in France and Germany, for example, have required support for ISO protocols for over a year even though the standards are not yet fully approved. These bids ask the respondent only to state support for the protocols. No doubt, as the ISO protocols become stable, these countries will require the protocols for their networks. These government networks will further influence the implementation of networks not actually required to use the international and national standards.
その結果、多くの国の政府ネットワークは国際的なISO規格か世界規格から得られた国家規格を使用します。 規格はまだ完全に承認されるというわけではありませんが、例えば、フランスとドイツの政府ネットワークを求める付け値の要求はISOプロトコルに1年間以上支持を要しています。 これらの付け値はプロトコルの国家的な支援に応答者を招くだけです。 間違いなく、ISOプロトコルが安定するようになるとき、これらの国はそれらのネットワークのためにプロトコルを必要とするでしょう。 これらの政府ネットワークはネットワークの実装が実際に国際的で国家の規格を使用するのを必要としなかった影響を促進するでしょう。
National Research Council [Page 36] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[36ページ]RFC942 1985年2月のレポート輸送
MARKET SEGMENTS NOT REQUIRED TO USE TCP OR TP-4
市場セグメントはTCPかTP-4を使用するのが必要ではありません。
Most of the demand for communication protocols comes from potential customers who are under no government fiat to use either TCP or TP-4 protocols in their networks or network products. Many of these will use existing supplier-specified protocols. Such protocols have been embedded in products for over ten years and are well tested both formally and through field experience in thousands of networks. Continuing demand for these protocols will not contribute to the relative demand for either TCP or TP-4.
通信プロトコルの需要の大部分はそれらのネットワークかネットワーク製品の中にTCPかTP-4プロトコルのどちらかを使用するために政府法令がないことでいる見込み客から来ます。 これらの多くが既存の供給者によって指定されたプロトコルを使用するでしょう。 そのようなプロトコルは、10年間以上製品に埋め込まれていて、正式で何千ものネットワークの実地経験を通してよくテストされます。 これらのプロトコルの継続する要求はTCPかTP-4のどちらかの相対的な需要に貢献しないでしょう。
There are widely recognized advantages in using international standard protocols for computer communications. First, there is tremendous value in exchanging information with other information users. As the standard protocols become widely used, the value of the information accessible through networks using these protocols is normally greater than the value of information accessible through less widely used networks protocols. This is the reason that industry groups such as airlines, banks, and insurance companies band together to set up common networks. Similarly, it is recognized that there are economies of scale for widely used networking protocols both in the sense that equipment can be obtained at lower cost and in the sense that the manufacturer's improvements in performance, function, and cost will be repaid by market demand. In addition, many network protocol users wish to have the option to procure equipment from a wide variety of vendors. Sometimes international standards encourage this environment. Finally, international organizations would prefer to have common procurement of equipment and software for worldwide operations. Thus international standards are preferred for operational as well as logistic considerations.
コンピュータコミュニケーションに世界規格プロトコルを使用するのにおいて広く認識された利点があります。 まず最初に、他の情報ユーザと共に情報交換するのにおいて物凄い値があります。 標準プロトコルが広く使用されるようになるのに従って、通常、これらのプロトコルを使用するネットワークを通してアクセスしやすい情報の価値は以下を通ってアクセスしやすい情報価値が広くネットワークを使用したよりすばらしいプロトコルです。 これは航空会社や、銀行や、保険会社などの同業種グループが一般的なネットワークを設立するために団結する理由です。 同様に、低い費用で設備を入手できるという意味と市場の需要で性能、機能、および費用におけるメーカーの進歩を返済するという意味には広く使用されたネットワーク・プロトコルのための規模の経済があると認められます。 さらに、多くのネットワーク・プロトコルユーザには、さまざまなベンダーから設備を調達するために、オプションがありたいです。 時々、世界規格はこの環境を奨励します。 最終的に、国際機関は、世界的な操作のための設備とソフトウェアの一般的な調達を持っているのを好むでしょう。 したがって、世界規格は操作上の、そして、ロジスティクスの問題のために好まれます。
In the United States much of the demand for TP-4 will develop in the industries that exchange information regularly with entities of the federal government. If the Federal Reserve were to use the TP-4 standard for exchanging information with member banks, for example, there would be pressure on the banks to use TP-4. Similarly, if DOD suppliers wish to have easy access to DOD employees using a system based on TCP, they would need to use TCP. Also many of the university-oriented networks use the ARPANET protocols to exchange information with other university ARPANET users.
合衆国では、TP-4の需要の多くが連邦政府の実体で産業でその交換情報を定期的に開発するでしょう。 連邦準備制度理事会が加盟銀行で情報交換するTP-4規格を使用するなら、例えば、圧力がTP-4を使用する銀行にあるでしょうに。 同様に、DOD供給者がTCPに基づいてある方法を使っているDOD従業員にたやすく近づく手段を持ちたいなら、彼らは、TCPを使用する必要があるでしょう。 また、大学指向のネットワークの多くが、他の大学のアルパネットユーザと共に情報交換するのにアルパネットプロトコルを使用します。
The committee concludes that the demand for TP-4 in the United States will significantly out weigh the demand for TCP independent of DOD's adoption of TP-4. If DOD adopts the ISO TP-4 immediately or if DOD adopts TP-4 after a demonstration, the U.S. market demand for TCP protocols will disappear as the current networks are converted to TP-4. If DOD chooses to use the DOD TCP indefinitely, clearly the DOD and ARPANET demand for TCP will continue.
委員会は、合衆国のTP-4の需要がDODのTP-4の採用の如何にかかわらずTCPの需要を熟慮するためにかなり外で望んでいると結論を下します。 DODがすぐに、ISO TP-4を採用するか、またはDODがデモンストレーションの後にTP-4を採用すると、現在のネットワークがTP-4に変換されるとき、TCPプロトコルを求める米国の市場の需要は見えなくなるでしょう。 DODが、DOD TCPを無期限に使用するのを選ぶと、明確に、TCPのDODとアルパネット需要は続くでしょう。
A similar set of market forces operates outside the United States except that the foreign governments are more strongly in favor of international and national standards and have smaller investments in nonstandard equipment. Thus there are even more industries drawn to
外国政府が国際的で国家の規格を支持してより強くである標準的でない設備によりわずかな投資を持っているのを除いて、同様のセットの市場の力は合衆国の外で作動します。 したがって、描かれたさらに多くの産業があります。
National Research Council [Page 37] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[37ページ]RFC942 1985年2月のレポート輸送
the standards in order to share information. This is illustrated by the extremely strong support for ISO efforts. The European Computer Manufacturers Association has been active in the TP-4 standardization effort. NATO appears committed to TP-4 implementations, and there is likely to be intense competition in this arena. Lacking the federal government support of two different protocol suites, there is a stronger force to adopt a single international standard in most countries. There are other countries with a similar problem, however. Germany is beginning to install systems based on its unique national standard but has committed to convert eventually to ISO protocols.
規格、情報を共有してください。 これはISO取り組みの非常に強いサポートで例証されます。 欧州コンピューター製造者協会はTP-4標準化取り組みで活動的です。 NATOはTP-4実装に心がけるように見えます、そして、おそらく、深刻な競争がこのアリーナにあるでしょう。 2つの異なったプロトコル群の連邦政府サポートを欠いていて、ほとんどの国にただ一つの世界規格を採用するために、より強い力があります。 しかしながら、同様の問題がある他国があります。ドイツは、ユニークな国家規格に基づくシステムをインストールし始めていますが、結局ISOプロトコルに変えるために公約されました。
The committee concludes that there will be little market demand for the TCP protocols outside the United States. The strong international demand will be for ISO protocols, including TP-4.
委員会は、合衆国の外にTCPプロトコルを求める市場の需要がほとんどないと結論を下します。 強い国際的な要求はTP-4を含むISOプロトコルのためにものになるでしょう。
National Research Council [Page 38] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[38ページ]RFC942 1985年2月のレポート輸送
VI. DEVELOPMENT OF STANDARD COMMERCIAL VERSUS SPECIAL COMMERCIAL PRODUCTS
VI。 一般的なコマーシャルの対特別な商品開発
DOD has expressed a desire to use off-the-shelf commercial products because they are expected to be less costly. It is expected that performance of commercial products will be optimized to increase competitiveness. User cost will be lower because of a large commercial customer base over which to amortize costs for development, continuous improvements, and maintenance. Furthermore, the DOD may benefit from having more vendors compete for their business. This section examines the way vendors select standard products for development and the implications in cost, continuing supports, and improvements.
DODはそれほど高価でないと予想されるのですぐ入手できる商品を使用する願望を述べました。 商品の性能が競争力を増強するために最適化されると予想されます。 ユーザ費用は開発、連続した改良、およびメインテナンスのためにコストを清算する大きい商業顧客ベースのために低いでしょう。 その上、より多くのベンダーにそれらのビジネスを競争させるのからDODは利益を得るかもしれません。 このセクションはベンダーが費用、継続的なサポート、および改善における開発と含意のために規格品を選択する方法を調べます。
PRODUCT DEVELOPMENT VERSUS SYSTEM INTEGRATION
商品開発対システム統合課
It is assumed in this discussion that off-the-shelf commercial products can be used through system integration to construct system solutions. Most vendors supply both standard products and system integration services. Some vendors supply only the integration functions, using other vendors' products. System integration adds value to the product and in some cases results in modifications of the product to meet system requirements. When standard products are used, the responsibility for continuing maintenance and improvements almost always can be passed to the product developer. Thus in this discussion we assume that off-the-shelf commercial products are standard products supplied by vendors to implement one or more transport-level protocols for the DOD.
この議論では、システムソリューションを構成するのにシステムインテグレーションを通してすぐ入手できる商品を使用できると思われます。 ほとんどのベンダーが規格品とシステム・インテグレーション・サービスの両方を供給します。 ベンダーの中には他のベンダーの製品を使用して、統合機能だけを供給するものもあります。 システムインテグレーションは、システム要求を満たすために製品といくつかのケース結果で製品の変更で価値を高めます。 規格品が使用されているとき、ほとんどいつも継続するメインテナンスと改良への責任を製品開発者に渡すことができます。 したがって、この議論では、私たちは、すぐ入手できる商品がDODのために1つ以上の輸送レベルプロトコルを実装するためにベンダーによって供給された規格品であると思います。
CRITERIA FOR SELECTION OF STANDARD PRODUCTS
規格品の品揃えの評価基準
The product vendor's choice to develop a standard product is governed by market requirements, economic opportunities, and other design considerations. In the case of data transmission products, market requirements include competition, connection to the installed base of products, market growth, and satisfaction of the standards requirements of customers.
規格品を開発する製品ベンダーの選択は市場の必要性、ビジネス・チャンス、および他のデザイン問題によって支配されます。 データ伝送製品の場合では、市場の必要性は規格顧客の要求の製品、市場成長、および満足のインストールされたベースに競争、接続を含んでいます。
Often the vendor will develop a product that supports several protocols as options. Usually only one or two protocols will be selected for primary support, and all other options are considered for secondary support. The primary protocols selected for implementation are based upon the largest potential market for the vendor. These protocols become the vendor's standard products. Standard products are announced for sale and supported on a continuing basis. Implementations of secondary protocols are often adaptations of the implementations of standard protocols and may be suboptimal with respect to performance and continuing vendor support. Often secondary implementations are created when an RFP is issued and the vendor who wishes to respond to the RFP must create a special product to do so. This committee believes that, in general, future standard data transmission products will be either TP-4 or vendor-unique protocols and TCP will be a special product.
しばしば、ベンダーはオプションとしていくつかのプロトコルをサポートする製品を開発するでしょう。 通常、1か2つのプロトコルだけがプライマリサポートのために選択されるでしょう、そして、すべての別の選択肢がセカンダリサポートのために考えられます。 実装のために選択されたプライマリプロトコルはベンダーの最も大きい潜在市場に基づいています。 これらのプロトコルはベンダーの規格品になります。 規格品は、販売で発表されて、ずっと継続する形態で支えられます。 セカンダリプロトコルの実装は、しばしば標準プロトコルの実装の適合であり、性能と継続するベンダーサポートに関して準最適であるかもしれません。 RFPが発行されるとき、しばしばセカンダリの実装は作成されます、そして、RFPに応じたがっているベンダーはそうするために特別産を作成しなければなりません。 この委員会はそれを信じています、そして、一般に、将来の標準のデータ伝送製品は、TP-4かベンダーユニークなプロトコルのどちらかになるでしょう、そして、TCPは特別産になるでしょう。
National Research Council [Page 39] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[39ページ]RFC942 1985年2月のレポート輸送
STANDARD VERSUS SPECIAL PRODUCT
特別産に対して標準です。
Within the OSI architectural model, seven layers are defined, each of which will have protocols defined for interconnection of systems. These protocols are controlled by standards. TP-4 is an example of a protocol for the transport layer. These protocols will be implemented on many vendor systems that have different systems architecture, different operating system architectures, and, therefore, differences in the specifics of the layer interface. The vendor systems will be designed to optimize the specific environments that each vendor has determined are most important to satisfy the major market objective for that vendor's particular computer architectures. This determines the vendor's standard system and architecture. Support of special requirements will frequently be designed as modifications to a standard system, using translators and other techniques to bridge the differences in layer interface definitions, operating systems structure, and protocols. Most support activity, optimization of performance and resource usage will be directed at the standard system architecture selected by the supplier.
OSIの建築モデルの中では、どれにシステムのインタコネクトのために定義されたプロトコルがあるかについて7つの層がそれぞれ定義されます。これらのプロトコルは規格によって制御されます。 TP-4はトランスポート層のためのプロトコルに関する例です。 これらのプロトコルは異なったオペレーティングシステムアーキテクチャを持っていて、層のインタフェースの詳細の異系統アーキテクチャ、およびその結果違いを持っている多くのベンダーシステムの上で実装されるでしょう。 ベンダーシステムは、そのベンダーの特定のコンピュータ・アーキテクチャのために各ベンダーが主要な市場目的を満たすために最も重要であることを決定した特定の環境を最適化するように設計されるでしょう。 これはベンダーの標準のシステムとアーキテクチャを決定します。 特別な要件のサポートは標準のシステムへの変更として頻繁に設計されるでしょう、層のインターフェース定義、オペレーティングシステム構造、およびプロトコルの違いをブリッジするのに翻訳者と他のテクニックを使用して。 ほとんどのサポート活動、供給者によって選択された標準のシステム構築は性能とリソース用法の最適化に向けられるでしょう。
Special-Product Process
特別産プロセス
Special-product development is initiated to meet customer specifications. The specifications, schedule, and cost assume that special products are released using an existing version of the software system (operating system, language, communications, and data manager). Support for the special product is conditioned on a support contract. The special product is tested and released with that system. This provides the fastest availability of the product, since the schedule will only include the time to develop the product and test it with the selected system. It is likely that by the time a product and its software system are delivered, a newer version of the software system containing code corrections and added functions and other new products will have been released. Additional cost to the customer is required if the vendor is to modify the special product to operate on this new version of software. This occurs frequently in a rapidly developing technology. If the special product is not modified, operational and maintenance expenses may increase.
特別産開発は、顧客仕様を満たすために開始されます。 仕様、スケジュール、および費用は、特別産がソフトウェア・システム(オペレーティングシステム、言語、コミュニケーション、およびデータ管理ソフトウェア)の既存のバージョンを使用することでリリースされると仮定します。 特別産のサポートはサポート契約を条件とします。 特別産は、そのシステムでテストされて、リリースされます。 これは製品の最も速い有用性を提供します、スケジュールが製品を開発して、選択されたシステムでそれをテストする時間を含むだけであるので。 製品とそのソフトウェア・システムが提供される時までには、ソフトウェア・システムがコード修正、加えられた機能、および他の新製品を含むより新しいバージョンはリリースされそうであってしまうでしょう。 ベンダーがソフトウェアのこの新しいバージョンで操作する特別産を変更するつもりであるなら、顧客への別途費用が必要です。 これは急速に展開している技術で頻出します。 特別産が変更されていないなら、操作上とメインテナンス費用は上がるかもしれません。
Standard-Product Process
規格品プロセス
A standard product is developed to meet the market requirements of a market area. The development of a standard product generally has a target date that is used as a basis for scheduling system development, fabrication, and testing into a planned software system release. The product then is included in the test and integration plan for the system release and integration into a systems test procedure to assure operation with the other parts of the software system. The standard product then becomes a part of the software system, and as new releases of the system are made, the product is tested as a part of the integrated system to assure that it still operates with the revised, new system. The product may also be enhanced to satisfy new requirements or resolve problems of the earlier version. The product
規格品は、市場地域に関する市場の必要性を満たすために開発されます。 一般に、規格品の開発には、スケジューリングシステム開発と、製作と、計画されたソフトウェア・システムリリースにテストする基礎として使用される目標日付があります。 そして、製品はテストとシステム・テスト手順へのシステムリリースと統合が他の部品がある操作にソフトウェア・システムを保証する統合計画に含まれています。 次に、規格品はソフトウェア・システムの一部になります、そして、システムの新版をするとき、それが改訂されて、新しいシステムでまだ作動していることを保証するために融合システムの一部として製品をテストします。 また、製品は、新しい要件を満たすか、または以前のバージョンの問題を解決するために高められるかもしれません。 製品
National Research Council [Page 40] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[40ページ]RFC942 1985年2月のレポート輸送
then will operate with the latest software system release.
そして、最新のソフトウェア・システムリリースで、作動するでしょう。
The integration process complicates the development process. The increased complexity may result in a longer development schedule or may require more resources than special products require since (1) the cycle may involve a longer product requirement definition, (2) additional planning and integration testing may be needed to coordinate the product design with other system activities, and (3) there is the possibility of up to twelve months' delay in scheduling a software system release, which for most vendors generally occurs at 6- to 12 month intervals. The product may be maintained with a corrective code released in intermediate system fabrication and integrated into the following software release. Different categories of support may be available and these categories may vary by product. The support categories may range from no support to full unlimited warranty.
統合プロセスは開発過程を複雑にします。 (3) (1) サイクルは、より長い製品要件定義にかかわるかもしれません、(2)の追加計画、統合テストが他のシステム活動でプロダクトデザインを調整するのに必要であるかもしれないので、増強された複雑さは、より長い開発スケジュールをもたらすか、または特別産が必要とするより多くのリソースを必要とするかもしれません、そして、一般に、ほとんどのベンダーのために6〜12カ月の間隔を置いて起こるソフトウェア・システムリリースの計画をすることにおける、最大12カ月の遅れの可能性があります。 調整策のコードが中間システム製作でリリースされて、以下のソフトウェアリリースと統合されている状態で、製品は維持されるかもしれません。 サポートの異なったカテゴリは利用可能であるかもしれません、そして、これらのカテゴリは製品で異なるかもしれません。 サポートカテゴリはサポートがないのから完全な無制限な保証まで及ぶかもしれません。
CONCLUSION
結論
The committee concludes that there are significant benefits for the Department of Defense in using standard commercial products that meet the department's operational needs:
委員会は、部の操作上の需要を満たす標準の商品を使用するのにおいて国防総省に、重要な利益があると結論を下します:
Costs to the DOD for development, production, and maintenance are significantly lower because (l) vendors spread the cost over a much larger user base, (2) commercial vendors have to be efficient in their operations in view of the competition in the market, and (3) vendors look for ways to upgrade their product to meet competition.
(l) ベンダーがはるかに大きいユーザベースにわたって費用を広げて、(2) 市場での競争から見て商業ベンダーが彼らの操作で効率的でなければならなく、(3) ベンダーが競合に応じるためにそれらの製品をアップグレードさせる方法を探すので、開発、生産、およびメインテナンスのためのDODへのコストはかなり低いです。
The department may get additional useful products because vendors integrate the protocol function into their corporate software and hardware product lines. Thus the DOD may be able eventually to use standard commercial software application products that are built on top of, and thereby take advantage of, the transport protocols. The DOD will thereby have a wider selection of standard commercial application products to choose from. By depending on industry to manage the development, maintenance, and upgrade of products, the DOD can use its scarce management and technical resources on activities unique to its mission.
ベンダーがそれらの法人のソフトウェアとハードウェア製品ラインとプロトコル機能を統合するので、部は追加役に立つ製品を手に入れるかもしれません。 したがって、DODは、結局、トランスポート・プロトコルについて組立の標準の商用ソフトウェア応用機器を使用して、その結果、利点を活用するためにできるかもしれません。 その結果、DODには、選ぶ標準の商業応用機器の、より広い品揃えがあるでしょう。 製品の開発、メインテナンス、およびアップグレードを管理するために産業に頼ることによって、DODは任務にユニークな活動に関するその不十分な管理と技術的な資源を使用できます。
National Research Council [Page 41] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[41ページ]RFC942 1985年2月のレポート輸送
National Research Council [Page 42] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[42ページ]RFC942 1985年2月のレポート輸送
VII. RESPONSIVENESS OF INTERNATIONAL STANDARDS PROCESS TO CHANGE
VII。 変える国際的な標準化過程の反応性
The international standards process has proven its ability to respond quickly to new requirements and protocol problems uncovered during standardization. The United States, through organizations such as the NBS, the ANSI, and IEEE has a leadership role in this process. The committee concludes that the process can be responsive to DOD's needs.
世界規格プロセスはすばやく新しい要件に応じる性能を立証しました、そして、プロトコル問題は標準化の間、発見しました。 NBSや、ANSIや、IEEEなどの組織による合衆国には、このプロセスにおけるリーダーシップの役割があります。 委員会は、プロセスがDODの必要性に敏感である場合があると結論を下します。
The DOD will benefit from active participation in the international protocol standardization efforts. This will ensure that the DOD's evolving computer communications needs will be met in future commercial products. Also the DOD will have access to a broad spectrum of protocol experts and have access to those developing future commercial products. These benefits will far out weigh the costs of participation.
DODは国際的なプロトコル標準化取り組みへの積極的な参加の利益を得るでしょう。 これは、DODがコンピュータコミュニケーションの必要性を発展するのが将来の商品の中で会われるのを確実にするでしょう。 また、DODはプロトコルの専門家の広いスペクトルに近づく手段を持っていて、それらの展開している将来の商品に近づく手段を持つでしょう。 これらの利益は参加のコストの重さがあるためにはるかに外で望んでいます。
There will probably be very few high-priority instances where DOD will require immediate changes to its operational commercial software. These may relate to security or survivability. In order to accommodate these changes in the short run, the DOD will need agreements with its commercial suppliers for quick fixes to be made while the standard is being changed.
たぶん、ほんのわずかな高優先度インスタンスがDODが操作上の商用ソフトウェアへの急激な変化を必要とするところにあるでしょう。 これらはセキュリティか生存性に関連するかもしれません。 短期的にはこれらの変化を収容して、DODは、規格を変えている間、即効薬を作るために商業供給者との協定を必要とするでしょう。
National Research Council [Page 43] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[43ページ]RFC942 1985年2月のレポート輸送
National Research Council [Page 44] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[44ページ]RFC942 1985年2月のレポート輸送
VIII. OPTIONS FOR DOD AND NBS
VIII。 DODとNBSのためのオプション
The committee believes that the Department of Defense is committed to adopting commercial standards when they are suitable and available and, therefore, will adopt the ISO standards eventually as the military standard for transport-level communication protocol. Further, the DOD realizes the benefits in cost and reliability of obtaining its data communications equipment from vendors who offer it as standard products. Of the three options identified by the committee, the first two are ways for the DOD to realize these benefits while the third option would withhold the benefits from the DOD indefinitely.
委員会は、それらが適当であって、利用可能であるときに、国防総省が商業規格を採用するよう心がけると信じて、したがって、結局、輸送レベル通信プロトコルの軍事の規格としてISO規格を採用するでしょう。 さらに、DODは規格品としてそれを提供するベンダーからデータ通信装置を入手する費用と信頼性で利益がわかります。 委員会によって特定された3つのオプションでは、最初の2は3番目のオプションがDODから利益を無期限に差し控えているだろうという間にDODがこれらの利益がわかる方法です。
The primary difference between Option l and Option 2 is in the timing of the transition from TCP to TP-4. This timing difference has implications in risk, cost, and manageability of the transition. (This is discussed in Chapter X in greater detail.)
TCPからTP-4までの変遷のタイミングにはOption lとOption2のプライマリ違いがあります。 この期間差異に、変遷のリスク、費用、および管理可能性における意味があります。 (章Xで詳細によりすばらしいこれについて議論します。)
Option 1
オプション1
The first option is for the DOD to immediately modify its current transport policy statement to specify TP-4 as a costandard along with TCP. In addition, the DOD would develop a military specification for TP-4 that would also cover DOD requirements for discretionary options allowed under the NBS protocol specifications. Requests for proposals (RFPs) for new networks or major upgrades of existing networks would specify TP-4 as the preferred protocol. Contracts for TP-4 systems would be awarded only to contractors providing commercial products, except for unique cases.
第1の選択はDODがすぐにTCPに伴うcostandardとしてTP-4を指定するように現在の輸送施政方針を変更することです。 さらに、DODはまた、NBSプロトコル仕様に基づき許容された任意のオプションのためのDOD要件をカバーするTP-4のための軍事の仕様を開発するでしょう。 既存のネットワークの新しいネットワークか大きな更新のための提案(RFPs)を求める要求は都合のよいプロトコルとしてTP-4を指定するでしょう。 ユニークなケース以外の商品を供給する契約者だけがTP-4システムのための契約を獲得するでしょう。
Existing networks that use TCP and new networks firmly committed to the use of TCP-based systems could continue to acquire implementations of TCP. The DOD should carefully review each case, however, to see whether it would be advantageous to delay or modify some of these acquisitions in order to use commercial TP-4 products. For each community of users it should be decided when it is operationally or economically most advantageous to replace its current or planned systems in order to conform to ISO standards without excessively compromising continued operations.
TCPを使用する既存のネットワークとしっかりTCPベースのシステムの使用に心がける新しいネットワークは、TCPの実装を取得し続けることができました。 しかしながら、DODは、商業TP-4製品を使用するために遅らせるか、またはこれらのいくつかの獲得を変更するのが有利であるかどうか確認するために慎重に各ケースについて再審理するはずです。 現在の、または、計画されたシステムを置き換えるのが操作上か経済的に最も有利であるときに、ユーザの各共同体において、それは、継続運転に過度に感染しないでISO規格に従うために定まっているべきです。
United States government test facilities would be developed to enable validation of TP-4 products. The Department of Defense would either require that products be validated using these test facilities or be certified by the vendor. The test facilities could also be used to
合衆国政府テスト機能は、TP-4製品の合法化を可能にするために見いだされるでしょう。 国防総省は、製品がこれらのテスト機能を使用することで有効にされるか、またはベンダーによって公認されるのを必要とするでしょう。 また施設も使用されているかもしれないテスト
National Research Council [Page 45] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[45ページ]RFC942 1985年2月のレポート輸送
isolate multivendor protocol compatibility problems. The existing NBS validation tools should be used as the base for the DOD test facilities.
「マルチ-ベンダー」プロトコル互換性の問題を隔離してください。既存のNBS合法化ツールはDODテスト機能にベースとして使用されるべきです。
Because under this option networks based on both TCP and TP-4 would coexist for some time, several capabilities that facilitate interoperability among networks would need to be developed. The Department of Defense generally will not find them commercially available. Examples are gateways among networks or specialized hosts that provide services such as electronic mail. The department would need to initiate or modify development programs to provide these capabilities, and a test and demonstration network would be required.
TCPとTP-4の両方に基づくネットワークはしばらくこのオプションで共存しているでしょう、したがって、ネットワークの中で相互運用性を容易にするいくつかの能力が開発される必要があるでしょう。 一般に、国防総省は、それらが商業的に利用可能であることがわからないでしょう。 例は電子メールなどのサービスを提供するネットワークか専門化しているホストの中のゲートウェイです。 部は、これらの能力を提供するように開発プログラムを開始するか、または変更する必要があるでしょう、そして、テストとデモンストレーションネットワークが必要でしょう。
Option 2
オプション2
Under Option 2 the Department of Defense would immediately announce its intention to adopt TP-4 as a transport protocol costandard with TCP after a satisfactory demonstration of its suitability for use in military networks. A final commitment would be deferred until the demonstration has been evaluated and TP-4 is commercially available.
Option2の下では、国防総省はすぐに、ミリタリー・ネットワークにおける使用への適合の満足できるデモンストレーションの後にTCPと共に輸送プロトコルcostandardとしてTP-4を採用するという意志を発表するでしょう。 デモンストレーションが評価されて、TP-4が商業的に利用可能になるまで、最終的な委任は延期されるでしょう。
The demonstration should take at most eighteen months and should involve development of TP-4 implementations and their installation. This option differs from Option 1 primarily in postponing the adoption of a TP-4 standard and, consequently, the issuance of RFPs based on TP-4 until successful completion of a demonstration. The department should, however, proceed with those provisions of Option 1 that may be completed in parallel with the demonstration. Early issuance of a TP-4 military specification, development of validation procedures, and implementation of means for interoperability would be particularly important in this regard.
デモンストレーションは、高々18カ月かかるべきであり、TP-4実装の開発と彼らのインストールにかかわるべきです。 このオプションは主としてデモンストレーションの無事終了までTP-4に基づく、TP-4規格の採用とその結果RFPsの発行を延期するのにおいてOption1と異なっています。 しかしながら、部はデモンストレーションと平行して完成するかもしれないOption1に関するそれらの条項を続けるべきです。 TP-4の軍事の仕様の早めの発行、合法化手順の開発、および相互運用性のための手段の実装は特にこの点で重要でしょう。
Option 3
オプション3
Under the third option the DOD would continue using TCP as the accepted transport standard and defer any decision on the use of TP-4 indefinitely. The department would be expected to stay well informed of the development and use of the new protocol in the commercial and international arena and, with the National Bureau of Standards, work on means to transfer data between the two protocol systems. Testing and evaluation of TP-4 standards by NBS would continue. The DOD might eventually accommodate both protocol systems in an evolutionary conversion to TP-4.
3番目のオプションで、DODは受け入れられた輸送規格としてTCPを使用し続けて、TP-4の使用のときにどんな決定も無期限に延期するでしょう。 部は、商業的、そして、国際的なアリーナに新しいプロトコルの開発と使用で通じた状態で滞在して、規格基準局と共に2台のプロトコルシステムの間にデータを移す手段に働くと予想されるでしょう。NBSによるTP-4規格のテストと評価は続くでしょう。 DODは結局、進化論の変換で両方のプロトコルシステムをTP-4に収容するかもしれません。
National Research Council [Page 46] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[46ページ]RFC942 1985年2月のレポート輸送
IX. COST COMPARISON OF OPTIONS
IX。 オプションの原価比較
There are so many variables affecting cost, it is impossible to compare precisely the cost for each option over time. The estimates in this section are, therefore, mostly qualitative. They are based on the wide experience of several committee members in commercial networking (14).
費用に影響するとても多くの変数があるので、時間がたつにつれて各オプションのために正確に費用を比較するのは不可能です。 したがって、このセクションの見積りはほとんど質的です。 それらは数人の委員の商業ネットワーク(14)の幅広い経験に基づいています。
Cost comparisons among the three options are difficult for two reasons:
3つのオプションの中の原価比較は2つの理由で難しいです:
1. There are an unlimited number of scenarios that can be considered for the growth of DOD's data communication networks in the next fifteen to twenty years, involving questions such as (a) How many different implementations will there be? (b) What economies of scale can be achieved? (c) How much software will be shared between different implementations? (d) How much will the standards change for greater effectiveness or to accommodate higher-layer standards? and (e) What will happen to manpower costs in this high-skill area?
1. 次の15〜20年間でDODのデータ通信ネットワークの成長のために考えることができる無制限な数のシナリオがあります、(a) いくつの異なった実装があるかなどの意味ありげな問題? (b) どんな規模の経済を達成できますか? (c) どのくらいのソフトウェアが異なった実装の間で共有されるでしょうか? (d) 規格は、より大きい有効性か、より高い層の規格を収容するためにどれほど変化するでしょう--(e) そして、この高技能領域の労働力コストはどうなるでしょうか?
2. It is difficult to isolate the costs attributable to developing, implementing, and maintaining the protocols at issue. This is especially true if we assume DOD continues to use its own unique protocols. For both in-house and contractor efforts, the costs associated with TCP are folded into many other efforts. If DOD moves to commercial protocols, the marginal costs may be more visible.
2. 問題でプロトコルを開発して、実装して、維持するのに起因するコストを隔離するのは難しいです。 私たちが、DODが、それ自身のユニークなプロトコルを使用し続けていると思うなら、これは特に本当です。 ともに社内と契約者取り組みにおいて、TCPに関連しているコストは他の多くの取り組みに折り重ねられます。 DODが商業プロトコルに移行するなら、限界原価は、より目に見えるかもしれません。
----- (14) The committee has had some access to a study recently conducted by the Defense Communication Agency that compares the costs of commercially maintained versus government-maintained operating systems for the Honeywell computers used in WWMCCS. Although the WWMCCS example has many fewer dimensions and systems than are covered by this analysis, the committee urges the DOD to review this study as a good example of potential savings from commercially vended software. (WWMCCS-ADP System Software Economic Analysis. J. Stephens and others, Joint Data Systems Support Center, Defense Communications Agency, Technical Report, in draft.)
----- (14) 委員会は最近WWMCCSで使用されるハネウェルコンピュータのために商業的に政府によって維持されたオペレーティングシステムに対して維持されていることのコストを比較する防衛通信委員会によって行われた研究にいくつか近づく手段を持っていました。 WWMCCSの例には多くの、より少ない寸法とシステムがありますが、委員会は、この分析でカバーされているより商業的に販売されたソフトウェアから潜在的貯蓄の好例としてこの研究を批評するようDODに促します。 (WWMCCS-ADPシステムソフト経済分析。 J。 スティーブンズと他のもの、JointデータシステムズSupportセンター、Defense Communications Agency、草稿におけるTechnical Report。)
National Research Council [Page 47] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[47ページ]RFC942 1985年2月のレポート輸送
A major motivation expressed by the DOD for using commercial protocols is that the commercial protocols are significantly cheaper. If this is the case, then many in the DOD would like to know the savings over the next ten to twenty years if DOD adopts TP-4. This is not a question we will try to answer in this report, but the concept of opportunity costs is significant. If DOD can successfully move to commercial standards, then it will eventually be able to use DOD's scarce management and technical resources to strengthen its efforts in other areas of information communications and processing that are more unique to the DOD. Given the finite pool of such resources available to the DOD, the value of this transfer may be significantly greater than the dollars saved by adopting the international standards.
商業プロトコルを使用するためにDODによって述べられた主要な動機は商業プロトコルがかなり安いということです。 これがそうであるなら、DODがTP-4を採用するなら、DODの多くが次の10〜20年間貯蓄を知りたがっています。 これは私たちがこのレポートで答えようとするという質問ではありませんが、機会費用の概念は重要です。 DODが首尾よく商業規格に動くことができると、結局、DODによりユニークな情報コミュニケーションと処理の他の領域で努力を強化するのにDODの不十分な管理と技術的な資源を使用できるでしょう。 DODに利用可能なそのようなリソースの有限プールを考えて、この転送の値はドルが世界規格を採用することによって節約されたよりかなり大きいかもしれません。
The following assumptions have been used in trying to estimate the cost factors if DOD moves toward adopting TP-4 using either Option 1 or 2:
以下の仮定はOption1か2を使用することでTP-4を採用することに向かってDODが動くならコスト要因を見積もろうとする際に使用されました:
No major subsystem of the DDN (which includes MILNET, DODIIS, WWMCCS, and so forth) would use both protocols at the same time except possibly for a brief transition period.
ことによると簡潔な過渡期以外に、DDN(MILNET、DODIIS、WWMCCSなどを含んでいる)のどんな主要なサブシステムも同時に、両方のプロトコルを使用しないでしょう。
In only a few selected cases would a capability be required to handle both protocols. These cases could include select hosts that use both, special servers (most likely mail servers) that could provide functions between several communities of interest using both protocols, or translating gateways between networks.
ほんのいくつかの選択された場合では、能力が、両方のプロトコルを扱うのに必要でしょうか? これらのケースは両方を使用する選んだホスト、両方のプロトコルを使用するか、またはネットワークの間のゲートウェイを翻訳しながら興味があるいくつかの共同体の間の機能を提供できた特別なサーバ(たぶんメールサーバ)を含むかもしれません。
Within the DDN both sets of protocols would be used for a period of five to ten years starting eighteen months after the DOD approves the use of TP-4 in a new system.
中では、両方のセットのプロトコルがDODの18カ月始まる5〜10年後にしばらく使用されているDDNが新しいシステムにおけるTP-4の使用を承認します。
In virtually all cases, the phase-over from TCP to TP-4 in a subsystem of the DDN would be performed at a time when there is a major upgrade of subsystem elements that include TCP as a part. In other words, the transition is not merely a substitution of transport or internet software except in cases where the hardware currently being used is from a vendor who has started to offer TP-4 as a commercial product. Where this is not the case, the transition includes the substitution of new hardware whose vendor provides TP-4 commercially.
ほとんどすべての場合では、部分としてTCPを含んでいるサブシステム要素の大きな更新があるとき、オーバーDDNのサブシステムによるTCPからTP-4までのフェーズは実行されるでしょう。 言い換えれば、変遷は単に輸送か現在使用されるハードウェアが商品としてTP-4を提供し始めた業者から来ているケース中以外のインターネットソフトウェアの代替ではありません。 これがそうでないところでは、変遷は業者が商業的にTP-4を提供する新しいハードウェアの代替を含んでいます。
COST FACTORS AND MODEL
コスト要因ANDモデル
Four major factors must be considered in evaluating the costs of the three options:
3つのオプションのコストを評価する際に4つの重要な要因を考えなければなりません:
1. How much lower will be the cost of commercial, standard-product
protocols compared to those developed and acquired by the DOD?
1. いくらが、より低くDODによって開発されて、取得されたものと比較された商業の、そして、標準の製品のプロトコルの費用になるでしょうか?
2. If DOD decides to adopt TP-4, how quickly can it start using it
in new systems, and how quickly will it phase TCP out of older
systems?
2. DODが、TP-4を採用すると決めるなら、どれくらいすばやく新しいシステムでそれを使用し始めることができるか、そして、どれくらいすぐに、より古いシステムからTCPの位相を合わせるでしょうか?
National Research Council [Page 48] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[48ページ]RFC942 1985年2月のレポート輸送
3. What will be the one-time cost of management and test before DOD
is prepared to start using TP-4?
3. DODがTP-4を使用し始めるように準備される前の管理とテストの1回の費用は何になるでしょうか?
4. What will be the marginal costs of maintaining the two standards
over the 5- to 10-year transition period?
4. 何が2つの規格を終わっているのに維持する限界原価が10年の過渡期への5であったならそうするでしょうか?
Savings Using Commercial Software
商用ソフトウェアを使用する貯蓄
Commercial software providing TP-4 will tend to be cheaper than DOD provided TCP because commercial one-time and recurring costs (especially the former) can be apportioned over a larger consumer base, and the commercial supplier will tend to be more efficient. As in most cases where one compares the cost of one product provided by two vendors, there will be situations where a DOD vendor providing TCP can do it more cheaply than a commercial vendor providing TP-4. These occurrences will be rare but they illustrate the difficulty of developing detailed quantitative models that compare the costs. Factors relating to competing suppliers go far beyond the transport protocols themselves and distort such models.
商業1回の、そして、再発しているコスト(特に前者)をより大きい消費者ベースにわたって分配できて、商業供給者が、より効率的である傾向があるので、TP-4を提供する商用ソフトウェアは、DODがTCPを提供したより安い傾向があるでしょう。 状況がTCPを提供するDOD業者がそれがTP-4を提供する商業業者より安くできるところに多くの場合1つが2つの業者によって供給された1個の製品の費用を比較するところにあるので。 これらの発生はまれになるでしょうが、それらはコストを比較する詳細な数量モデルを開発するという困難を例証します。 競争している供給者に関連する要素がそのようなモデルを歪めに遠くにトランスポート・プロトコル自体を超えて行きます。
The first argument relating to the size of the consumer base has many factors. For the time period under consideration, DOD represents about 3 percent of the commercial U.S. computer base. It would follow that DOD should pay much less in development and support costs for the commercial products. But there are other factors. The number of commercial suppliers is larger than the number of DOD suppliers by a factor of 5-10. The DOD's need for transport and internet protocols will be greater than the average commercial user in the time period under consideration. If commercial vendors break out the costs of developing these protocol features earlier than planned, DOD will pick up a larger share of the tab. This could be by a factor of 2 or more. A good deal of the one-time development and production costs of TCP have already been spent by the DOD or partly written off by DOD vendors. This factor would be extremely difficult to estimate, but we do not think it is very significant since the major costs in implementation relate to processes down-the-line from getting a C-language version. These down-the-line processes must be repeated in great part as families of hardware and software are upgraded with system and technology improvements to meet DOD directives for standard TCP products. There are also factors that cut in the other direction; if the DOD is only 3 percent of the U.S. commercial user market, it is an even smaller fraction of the international user market. This latter market is growing; its need for ISO protocols will be relatively higher than the U.S. market, and market share for U.S. manufacturers, including foreign subsidiaries, is large and holding its own.
消費者ベースのサイズに関連する最初の議論は多くの要素を持っています。 考慮している期間に、DODは商業米国コンピュータベースのおよそ3パーセントを表します。 DODがまして、開発中であるのに支払って、商品のためにコストを支持するはずであるということになるでしょう。 しかし、他の要素があります。 商業供給者の数はDOD供給者の数より5-10の要素で大きいです。 DODの輸送とインターネットプロトコルの必要性は普通の営利的ユーザより期間でさらにすばらしく考慮中になるでしょう。 商業業者が計画されているより早くこれらのプロトコル機能を開発するコストを広げると、DODはタブの、より大きいシェアを拾うでしょう。 これは2以上の要素であるかもしれません。 TCPの多くの1回の開発と生産費が、既にDODによって費やされるか、またはDOD業者によって一部すぐに書かれました。 この要素は見積もっているのが非常に難しいでしょうが、私たちは、少佐が実現関連の過程でC言語バージョンを得るのからのダウンザラインかかるのでそれが非常に重要であると思いません。 ハードウェアとソフトウェアの家族がシステムと技術の向上でアップグレードして、標準のTCP製品のためのDOD指示を満たすとき、かなりの部分でこれらのダウンザラインの過程を繰り返さなければなりません。 それがもう片方の方向に切った要素もあります。 DODが米国営利的ユーザ市場の3パーセントにすぎないなら、それは国際的なユーザ市場のさらにわずかな部分です。 この後者の市場は発展しています。 ISOプロトコルの必要性が米国市場より比較的高くなって、海外従属会社を含む米国のメーカーのためのシェアは、大きく、屈しません。
The situation is equally complex when it comes to comparing the efficiency of commercial vendors with DOD vendors when it relates to developing, installing, and maintaining transport and internet protocols. The elements that favor increased efficiency of the commercial supplier include the following:
開発に関連すると商業業者の効率をDOD業者と比べることとなると、状況は等しく複雑です、輸送とインターネットプロトコルをインストールして、維持して。 商業供給者の増加する効率を支持する要素は以下を含んでいます:
National Research Council [Page 49] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[49ページ]RFC942 1985年2月のレポート輸送
The commercial marketplace is much larger, less regulated, and is forced, therefore, to seek greater efficiency and innovation.
商業市場は、はるかに大きく、それほど規制されていなくて、したがって、やむを得ずより大きい効率と革新を求めます。
Transport and internet protocols represent functions that interact very closely with operating systems, the largest portion of which are commercial. The major sources of expertise for dealing with these operating systems are in the commercial marketplace, primarily with the vendors who supply the hardware as well as with vendors who specialize in related products.
商業である輸送とプロトコルが表す中で非常に密接にオペレーティングシステムと対話する機能、部分最も大きいインターネット。 これらのオペレーティングシステムに対処するための専門的技術の主要な源が商業市場、主としてハードウェアを提供する業者、および関連商品を専門とする業者と共にいます。
The commercial sector is in the business of managing the interplay between operating systems, protocols, related software and hardware products, new technology and architecture, and the relationship between all these and the market. If DOD adopts TP-4, it will be delegating many of these management functions to a marketplace that will generally make better and faster decisions.
オペレーティングシステムと、プロトコルと、関連するソフトウェアと、ハードウェア製品と、新技術と構造の間で交錯を管理して、すべてのこれらと市場の間で関係を管理するビジネスには商業部門があります。 DODがTP-4を採用すると、それは一般に、成功する市場と、より速い決定へこれらの管理機能の多くを代表として派遣するでしょう。
For every dollar that the DOD might invest in TCP, how much would it cost to gain comparable capability with TP-4 procured as vendor standard products? The many factors involved make a precise estimate impossible. We believe, however, that TP-4 can be procured at substantial savings and with virtually no economic risk if the market develops as we believe it will, with many vendors offering it as a commercial product by mid-1986. On the average, we judge the savings to be 30 to 80 percent including initial installation, field support, and maintenance.
DODがTCPに投資するかもしれないあらゆるドルで、それは、業者規格品としてTP-4を調達している状態で匹敵する能力を獲得するのにいくらかかるでしょうか? 要素がかかわった多くで、正確な見積りは不可能になります。 しかしながら、私たちは、私たちが、それがそうすると信じているとき市場が発展するなら多額の預金において実際にはどんな経済的リスクでもTP-4を調達できないと信じています、多くの業者が1986年中頃までに商品としてそれを提供していて。 平均して、私たちは、貯蓄が初度施設、分野サポート、および維持を含む30〜80パーセントであると判断します。
How Soon Will TP-4 Be Used?
すぐ、TP-4はどのように使用されるでしょうか?
The sooner that DOD decides to use TP-4, the greater will be DOD's savings. These savings can offset the adverse cost factors discussed in the next two sections: the cost to decide to use TP-4 and the added cost for the period when two standards (TCP and TP-4) are in use.
DODが、TP-4を使用すると、より早く決めれば決めるほど、DODの貯蓄は、よりすばらしくなるでしょう。 これらの貯蓄は次の2つのセクションで議論した不利なコスト要因を相殺できます: 2つの規格(TCPとTP-4)が使用中である期間、TP-4と加えられた費用を使用すると決める費用。
Currently, TCP is generally used in MILNET, MINET, and ARPANET. As previously stated in the assumptions, even if DOD decides to move aggressively toward TP-4, there are no evident, strong economic or operational reasons for converting these users to the new standards until a major upgrade of the users' communications and processing subsystems is planned. Also in the next twelve to eighteen months new uses of these nets are planned that will expand existing subnets and these new users would use TCP in order to be interoperable with the current users in their community of interest.
一般に、現在、TCPはMILNET、MINET、およびアルパネットに使用されます。 前述のように仮定には、DODが、積極的にTP-4に近づくと決めても、ユーザのコミュニケーションと処理サブシステムの大きな更新が計画されるまでこれらのユーザを新しい規格に変換するどんな明白で、強い経済の、または、操作上の理由もありません。 次の12〜18カ月でも、既存のサブネットを広くするこれらのネットの新しい用途が計画されています、そして、これらの新しいユーザは彼らの利益共同体の現在のユーザと共に共同利用できるのにTCPを使用するでしょう。
In some cases the planning for new subnets for new communities of users is well along. DODIIS is a primary example. Some of these subnets should very likely proceed with TCP, but others appear to be prime targets for TP-4 if DOD is to move in the direction of adopting TP-4. The WWMCCS and its WIN are probably good examples of the latter. Planning and implementation for all of these subsystems must move ahead, however, and if DOD does not make a firm commitment to TP-4 by mid-1985, the number of systems that will move ahead with TCP will
いくつかの場合、ユーザのニューコミュニティへの新しいサブネットのための計画はずっと良いです。 DODIISは第一の例です。 これらのサブネットのいくつかがたぶんTCPを続けるべきですが、TP-4を採用することの向きにDODが動くつもりであるなら、他のものは、TP-4に、主要な目標であるように見えます。 WWMCCSとそのWINはたぶん後者の好例です。 しかしながら、これらのサブシステムのすべてのための計画と実現は前方に動かなければなりません、そして、DODが1985年中頃までにTP-4の堅い公約をしないなら、TCPを続けるシステムの数はのようになるでしょう。
National Research Council [Page 50] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[50ページ]RFC942 1985年2月のレポート輸送
probably constitute almost half of the growth of the DDN in the next five years. In other words, delay of a decision to move to TP-4 until 1986 would mean that most of the DDN subnets that will exist in the late 1980s will be based on TCP, whereas a decision for TP-4 a year earlier could significantly reduce this number.
たぶん次の5年間でおよそ半分のDDNの成長を構成してください。 言い換えれば、1986年までTP-4に動くという決定の遅れは、1980年代後半に存在するDDNサブネットの大部分がTCPに基づきますが、TP-4のための決定が1年前にこの数をかなり減少させるかもしれないことを意味するでしょう。
Cost of Decision to Use TP-4
TP-4を使用するという決定の費用
The costs of the decision to use TP-4 include the one-time management and test costs that DOD decides are needed before a TP-4 commitment and policy can be approved. Under Option 1 these costs are small. Under Option 2 they are significantly higher, although the amount will depend on the extent and duration of the testing needed. Under Option 3 there will be no management and test costs.
TP-4を使用するという決定のコストは1回の管理とDODがTP-4委任と方針を承認できる前に必要であると決めるテストコストを含んでいます。 Option1の下では、これらのコストはわずかです。 Option2の下では、それらはかなり高いです、量が必要であるテストの範囲と持続時間によるでしょうが。 Option3の下には、管理とテストコストが全くないでしょう。
Marginal Costs of Maintaining Two Standards
2つの規格を維持するマージンのコスト
If DOD moves toward the gradual introduction of TP-4, both standards will have to be maintained for five to ten years. The additional costs of maintaining two standards include the following:
DODがTP-4のゆるやかな導入に近づくと、両方の規格は5〜10年間維持されなければならないでしょう。 2つの規格を維持する追加コストは以下を含んでいます:
Management costs of dealing with two standards.
2つの規格に対処する管理コスト。
Costs for developing and maintaining capabilities for limited intercommunication between systems using the different transport and internet protocols. These include costs for gateways, dual-capability hosts, and special servers such as mail.
システムの間の限られた相互通信のために異なった輸送とインターネットプロトコルを使用することで能力を見いだして、維持するためのコスト。 これらはメールなどのゲートウェイへのコスト、二元的な能力ホスト、および特別なサーバを含んでいます。
Parallel validation capability. The DOD is implementing a validation capability for DOD TCP. This is similar to the currently operational NBS facility for TP-4 testing. If DOD selects Option 1, there is a question whether this DOD facility should be completed for TCP (because the number of new implementations of TCP would be small several years from now). If DOD selects Option 2, the facility is probably desirable.
合法化能力に沿ってください。 DODはDOD TCPのために合法化能力を実行しています。 TP-4テストに、これは現在操作上のNBS施設と同様です。 DODがOption1を選択するなら、このDOD施設がTCPのために完成するべきであるかどうかという(TCPの新しい実現の数は現在から数年間少ないでしょう、したがって)質問があります。 DODがOption2を選択するなら、施設はたぶん望ましいです。
Costs for maintaining research and development (R&D) programs to improve the standards. A part of the DARPA and DCA research and development programs in information technology is directed at system issues related to TCP. This includes work on internet issues, gateways, and higher-level protocols. The committee has not reviewed the research program for details and cost; however, a commitment to move toward ISO standards should affect the program. Costs would increase to the extent that the program would be involved with interactions with both protocols. There would be some decreased requirements for R&D in light of potential dependence on commercial R&D to improve the standards. In the next several years, however, the committee concludes that dual standards would, on balance, somewhat increase R&D costs because of the DOD's unique operational requirements.
規格を改良するために研究開発(研究開発)プログラムを維持するためのコスト。 TCPに関連するシステム銘柄は情報技術におけるDARPAとDCA研究開発プログラムの一部に向けられます。 これはインターネット問題、ゲートウェイ、および上位レベル・プロトコルへの作業を含んでいます。 委員会は詳細と費用のための研究計画を再検討していません。 しかしながら、ISO規格に近づく委任はプログラムに影響するべきです。 コストはプログラムが両方のプロトコルとの相互作用にかかわるだろうという範囲まで上がるでしょう。 商業研究開発への潜在的依存の観点から研究開発が規格を改良するといういくつかの減少している要件があるでしょう。 しかしながら、数年内に、委員会は、二元的な規格がDODのユニークな操作上の要件のためにバランスで研究開発コストをいくらか上げると結論を下します。
These costs are roughly the same for Options 1 and 2 and depend on how DOD manages the transition. Under an austere transition, which does
これらのコストは、Options1と2にはおよそ同じであり、DODがどう変遷を管理するかに依存します。 厳格なそうする変遷で
National Research Council [Page 51] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[51ページ]RFC942 1985年2月のレポート輸送
not provide extensive interoperability between TP-4 and TCP-based systems and minimizes costs in other areas, the overall costs could be low in comparison with potential savings.
TP-4とTCPベースのシステムの間に大規模な相互運用性を供給しないで、他の領域のコスト、総合的なコストを最小にする、潜在的貯蓄との比較で低いかもしれません。
Evaluation of Options by Cost
費用によるオプションの評価
In terms of the previously discussed factors, savings can develop in two ways: by using TP-4 instead of TCP in new systems and by replacement of TCP with TP-4 in existing systems when this can be done smoothly and efficiently. The earlier that TP-4 is introduced, the greater these savings.
以前に議論された要素に関して、貯蓄は2つの方法で展開できます: スムーズに効率的にこれができると既存のシステムで新しいシステムのTCPの代わりにTP-4とのTCPの交換でTP-4を使用することによって。 より早くにTP-4を導入すれば導入するほど、これらの貯蓄は、よりすばらしいです。
In contrast costs will be incurred in two ways: in one-time planning to use TP-4 and in continuing costs of operating two standards.
対照的に、コストは2つの方法で被られるでしょう: TP-4を使用する1回の計画と2つの規格を操作する継続するコストで。
The following is a summary of the cost evaluation of the three options in the near term:
近いうちに↓これは3つのオプションのコスト評価の概要です:
Option 3 is least expensive. It achieves no commercial savings but has no costs for one-time planning and maintenance of dual standards.
オプション3は最も高価ではありません。 それは、二元的な規格の1回の計画とメンテナンスのためにどんな商業貯蓄も達成しませんが、コストを全く持っていません。
Option 1 is at most only slightly more expensive than Option 3 since one-time planning costs (which are much lower than for Option 2) and maintenance costs can be significantly offset with commercial savings in the following several years.
オプション1は次の数年間で商業貯蓄で1回の計画コスト(Option2よりはるかに低い)と維持コスト以来のOption3をかなり相殺できるより高々わずかにだけ高価です。
Option 2 is most expensive since it does not realize significant offsetting commercial savings.
重要な相殺商業貯蓄がわからないので、オプション2は最も高価です。
In the longer term (beyond the next several years) commercial savings for Options 1 and 2 should overtake costs of transition, and both these options should cost the same.
より長い期間(次の数年間の)で、Options1と2のための商業貯蓄は変遷のコストに追いつくべきです、そして、これらのオプションの両方が同じくらいかかるべきです。
There is a concern on the part of some members of the committee whether the higher near-term costs of Option 2 are adequately offset by the Option's long-term savings to warrant the transition.
関心が委員会の何人かのメンバー側のOption2の、より高い短期間コストが変遷を保証するためにOptionの長期の貯蓄で適切に相殺されるか否かに関係なく、あります。
National Research Council [Page 52] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[52ページ]RFC942 1985年2月のレポート輸送
X. EVALUATION OF OPTIONS
オプションのX.評価
We present a summary of the strengths and weaknesses of each option, followed by a detailed evaluation for each set of criteria.
私たちは強さの概要とそれぞれのセットの評価基準のための詳細な評価があとに続いたそれぞれのオプションの弱点を提示します。
SUMMARY
概要
Option 1's primary benefit is that it would allow the DOD to obtain the benefits of standard commercial products in the communication protocol area at an early date. These benefits include smaller development, procurement, and support costs; more timely updates; and a wider product availability. By immediately committing to TP-4 as a costandard for new systems, Option 1 minimizes the number of systems that have to be converted eventually from TCP. The ability to manage the transition is better than with Option 2 since the number of systems changed would be smaller and the time duration of mixed TCP and TP-4, operation would be shorter. Interoperability with external systems (NATO, government, and commercial), which presumably will use TP-4, would also be brought about more quickly. Option 1 involves greater risk, however, since it commits to a new approach without a demonstration of its viability.
オプション1の主要便益はDODがそれで期日前半の通信プロトコル領域の標準の商品の利益を得ることができるだろうということです。 これらの利益は、よりわずかな開発、調達、およびサポートコストを含んでいます。 よりタイムリーなアップデート。 そして、より広い製品の入手可能性。 すぐに新しいシステムのためのcostandardとしてTP-4に公約することによって、Option1は結局TCPから変換されなければならないシステムの数を最小にします。 変えられたシステムの数は、より少ないでしょう、したがって、変遷を管理する能力がOption2より良いです、そして、混ぜられたTCPとTP-4、操作の時間持続時間は、より短いでしょう。 また、外的システム(NATO、政府、およびコマーシャル)がある相互運用性はおよそよりすばやくもたらされているでしょう。(おそらく、外的システムはTP-4を使用するでしょう)。 しかしながら、オプション1は、生存力のデモンストレーションなしで新しいアプローチに公約するので、より高い危険にかかわります。
As with Option 1, a primary benefit of following Option 2 would be obtaining the use of standard commercial products. Unit procurement costs probably would be lower than with Option 1 since the commercial market for TP-4 will have expanded somewhat by the time DOD would begin to buy TP-4 products. Risk is smaller compared to Option 1 since testing and demonstration of the suitability for military use will have preceded the commitment to the ISO protocols. Transition and support costs would be higher than for Option 1, however, because more networks and systems would already have been implemented with TCP. Also this is perhaps the most difficult option to manage since the largest number of system conversions and the longest interval of mixed TCP and TP-4 operations would occur. In addition, interoperability with external networks through standardization would be delayed.
Option1なら、Option2に続く主要便益は標準の商品の使用を得ているでしょう。 DODがいくらか製品をTP-4に買い始めるだろうという時までにTP-4の商業市場が広がってしまうだろうので、調達がかかる単位はたぶんOption1より低いでしょう。 適合のテストとデモンストレーションが軍用にISOプロトコルの委任に先行して以来Option1と比べて、リスクは、より低いです。 より多くのネットワークとシステムはTCPと共に既に導入されたでしょう、しかしながら、したがって、変遷とサポートコストはOption1より高いでしょう。 システム変換の最多数と混ぜられたTCPとTP-4操作の最長間隔は起こるでしょう、また、したがって、これが恐らく管理する中で最も難しいオプションです。 さらに、標準化による外部のネットワークがある相互運用性は遅れるでしょう。
The principal benefit of exercising Option 3 would be the elimination of transition cost and the risk of faulty system behavior and/or delay. It would allow the most rapid achievement of full internal interoperability among DOD systems. Manageability should be good, since only one set of protocols would be in use (one with which the DOD already has much experience) and the DOD would be in complete control of system evolution. Procurement costs for TCP systems would remain high compared to standard ISO protocol products, however, and availability of implementations for new systems and releases would remain limited. External interoperability with non-DOD systems would be limited and inefficient.
Option3を運動させる主要な利益は、変遷費用の除去と不完全なシステムの振舞い、そして/または、遅れのリスクでしょう。 それはDODシステムの中に完全な内部の相互運用性の最も急速な実績を許容するでしょう。管理可能性は良いはずです、1セットのプロトコルだけが使用中でしょう、そして、(DODには多くの経験が既にあるもの)DODはシステム展開の完全なコントロール中でしょう、したがって。 しかしながら、標準のISOプロトコル製品と比べて、TCPシステムのための調達コストは高いままで残っているでしょう、そして、新しいシステムとリリースのための実装の有用性は制限されたままで残っているでしょう。 非DODシステムがある外部の相互運用性は、限られていて効率が悪いでしょう。
National Research Council [Page 53] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[53ページ]RFC942 1985年2月のレポート輸送
In summary, Option 1 provides the most rapid path toward the use of commercial products and interoperability with external systems. Option 2 reduces the risk but involves somewhat greater delay and expense. Option 3 provides a quicker route to interoperability within the Defense Department and at the least risk, but at a higher life-cycle cost and incompatibility with NATO and other external systems.
概要では、Option1は外的システムで商品と相互運用性の使用に向かって最も急速な経路を提供します。オプション2は、危険を減少させますが、いくらか大きい遅れと費用を伴います。 オプション3は、国防総省以内と最少のリスクにおいてより迅速なルートを相互運用性に提供しますが、NATOと他の外的システムがある、より高いライフ・サイクル・コストと不一致で提供します。
DEFENSE DEPARTMENT OBJECTIVES VERSUS OPTIONS
国防総省目的対オプション
The committee has identified a set of DOD objectives for transport protocols, discussed in Section II of this report. In this section we discuss the potential of each of the three options for achieving those objectives. The objectives have been grouped into five major categories that serve as criteria for evaluation of options.
委員会はこのレポートのセクションIIで議論したトランスポート・プロトコルのために1セットのDOD目的を特定しました。 このセクションで、私たちは、それらの目的を達成するためにそれぞれの3つのオプションの可能性について議論します。 目的はオプションの評価基準として機能する5つの大範疇に分類されました。
Functional and Performance Objectives
機能的、そして、パフォーマンス目的
There are certain functional and performance objectives that standard DOD transport protocols must satisfy. Key objectives include security capabilities, the ability to establish message precedence in crisis situations, and survivability of continuing operations when failures occur and portions of the network become inoperable. This implies continuous availability of the primary data transmission network and the ability to reconfigure the networks to operate after some of its nodes are lost.
標準のDODトランスポート・プロトコルが満たさなければならない機能的、そして、性能のある目的があります。 主要目的はセキュリティ能力(危機的状況、および失敗が起こって、ネットワークの一部が手術不能になるときの継続事業の生存性にメッセージ先行を確立する能力)を含んでいます。 これは、いくつかのノードが無くなった後に作動するためにプライマリデータ伝送ネットワークの連続した有用性とネットワークを再構成する能力を含意します。
As previously stated, the two protocols are functionally equivalent. TCP and TP-4 have equivalent reliability characteristics and are able to detect and recover from failures. The committee also concludes that robustness, availability, and performance in crises are equivalent using either protocol. The committee concludes that all three options equally satisfy the functional objectives that DOD requires.
前述のように、2つのプロトコルが機能上同等です。 TCPとTP-4は失敗から同等な信頼性特性値を持って、検出して、回復できます。 また、委員会は、危機の丈夫さ、有用性、および性能がどちらのプロトコルも使用することで同等であると結論を下します。 委員会は、すべての3つのオプションが等しく、DODが必要とする機能目的を満たすと結論を下します。
Since the performance characteristics of TCP versus TP-4 will be a function primarily of the particular implementations, the committee concludes that the two protocols are sufficiently alike that there are no significant differences in performance of a TCP or a TP-4 implementation of equal quality when each is optimized for a given environment.
TCP対TP-4の性能の特性が主として特定の実装の機能になるので、委員会は、2つのプロトコルが十分同じく、それぞれが与えられた環境のために最適化されるそれがTCPの性能か等しい品質のTP-4実装の著しい違いが全くいないということであると結論を下します。
If Option 1 is selected, early implementations may result in suboptimal performance. Option 2 specifies that there be a demonstration network established that will provide time for adjustment, testing, and gaining experience. Option 3 would result in no reduction in performance of current networks. The maturity of TCP has resulted in many implementations that have demonstrated good performance. This experience provides a knowledge base for future implementations of either TCP or TP-4. In either case, however, initial implementations of TCP or TP-4 may be suboptimal and require additional development to optimize performance.
Option1が選択されるなら、早めの実装は準最適の性能をもたらすかもしれません。 オプション2は調整のためのテストしている時間を提供する設立されたデモンストレーションネットワークと獲得が経験であったならそこでそれを指定します。 オプション3は現在のネットワークの性能の減少を全くもたらさないでしょう。 TCPの円熟は望ましい市場成果を示した多くの実装をもたらしました。 この経験はTCPかTP-4のどちらかの将来の実装に知識ベースを提供します。 どちらの場合ではも、しかしながら、TCPかTP-4の初期の実装は、性能を最適化するために準最適であり、追加開発を必要とするかもしれません。
National Research Council [Page 54] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[54ページ]RFC942 1985年2月のレポート輸送
Maximizing Interoperability
相互運用性を最大にします。
A high-priority DOD objective is interoperability among its internal networks and among internal networks and non-DOD, external networks, including NATO. Interoperability allows users of a network to have access to applications on the same or other networks.
高優先度DOD目的は内部のネットワークの中と、そして、NATOを含む内部のネットワークと、非DODの、そして、外部のネットワークの中の相互運用性です。 相互運用性で、ネットワークのユーザは同じであるか他のネットワークにおけるアプリケーションに近づく手段を持つことができます。
Option 3 would allow the DOD to increase internal interoperability most rapidly by continuing to mandate use of TCP for all new systems. Interoperability with external systems, however, the vast majority of which are expected to use ISO standard protocols, will remain limited.
オプション3はしかしながら、TCPのすべて新しいシステム相互運用性の使用を強制し続けていることによって外的システムで最も急速に内部の相互運用性を増強するそれのかなりの大部分がISOを使用することが期待されるDODに標準プロトコルを許容して、制限されたままで残るでしょう。
The more quickly DOD moves to use TP-4, the more rapidly external interoperability will improve. In the short run internal interoperability will be reduced due to the existence of both TCP and TP-4 protocols by different subnets. This problem is greater with Option 2 then Option 1 since the number of systems and the length of time both protocols are in use is greater. In both options the problem can be reduced by providing special servers and translating gateways to provide limited interoperability where needed among subnets using different protocols.
DODがTP-4を使用するために、よりはやく移行すれば移行するほど、より多くの急速に外部の相互運用性が向上するでしょう。 短期的には、内部の相互運用性はTCPとTP-4プロトコルの両方の存在のため異なったサブネットによって減少させられるでしょう。 システムの数と両方のプロトコルが使用中である時の長さが、より大きいので、この問題はOption2の当時のOption1と共に、より重大です。 両方のオプションでは、問題は、サブネットの中で異なったプロトコルを使用することで必要であるところで特別なサーバを提供して、限られた相互運用性を提供するためにゲートウェイを翻訳することによって、減少できます。
Minimizing Procurement, Development, and Support Costs
調達、開発、およびサポートコストを最小にします。
A DOD goal is to assure availability of commercial-grade transport systems from vendors and minimize development, procurement, and continuing support costs. Both Option 1 and, after demonstration, Option 2 result in DOD adopting the TP-4 standard that has the endorsement of both national (ANSI) and international (ISO) standards organizations. Further, this protocol has been endorsed for use by NATO, the European Computer Manufacturer's Association, the Computer and Business Equipment Manufacturer's Association (CBEMA), and the NBS Institute of Computer Sciences and Technology for the information processing community of the federal government.
DOD目標は、ベンダーから有用性に商用銘柄輸送システムを保証して、開発、調達、および継続的なサポートコストを最小にすることです。 Option1とデモンストレーションの後にOption2の両方が両方の裏書きを国家にするTP-4規格(ANSI)を採用するDODと国際的な(ISO)規格組織をもたらします。 さらに、このプロトコルは使用のためにコンピューターサイエンシズとTechnologyのNATO、ManufacturerのヨーロッパのコンピュータAssociation、コンピュータとBusiness Equipment ManufacturerのAssociation(CBEMA)、およびNBS Instituteによって連邦政府の情報処理共同体に是認されました。
The result of the endorsements will be widespread use of the standard protocol in worldwide networks and a large number of vendors supplying commercial grade products supporting TP-4. As previously noted, many vendors have already stated they plan to develop TP-4-based products and many are already doing this in-house. Thus a large market and large vendor base will assure the availability of commercial grade TP-4 products.
裏書きの結果はTP-4をサポートする商用銘柄製品を供給する世界規模のネットワークと多くのベンダーで標準プロトコルの普及使用になるでしょう。 上述しているように、多くのベンダーが、TP-4ベースの製品を開発するのを計画していると既に述べました、そして、多くがこれほど内部で既にしています。 したがって、大きな販路と大きいベンダーベースは商用銘柄TP-4製品を有用性に保証するでしょう。
A large market and supply of commercial-grade products will give DOD a large competitive base from which to select its data transmission systems. The effect will be to reduce DOD acquisition cost because large markets allow vendors to amortize development and support cost over a large base. This favors adoption of either of the options that results in DOD using TP-4 as its standard.
商用銘柄製品の大きな販路と供給はデータ伝送システムを選択する大きい競争力があるベースをDODに与えるでしょう。効果は大きな販路がベンダーに大きいベースにわたって開発を清算して、費用をサポートさせるのでDOD取得原価を変えることでしょう。 これは規格としてTP-4を使用することでDODをもたらすオプションのどちらかの採用を支持します。
With the availability of commercial-grade products, vendors will take the responsibility for continuing maintenance and enhancements of the product. Transmission products are tightly coupled to the operating
商用銘柄製品の有用性で、ベンダーは製品の継続するメインテナンスと増進のために責任を引き受けるでしょう。 トランスミッション製品は作動への密結合です。
National Research Council [Page 55] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[55ページ]RFC942 1985年2月のレポート輸送
systems on the host computer systems in which they operate. With vendor support of the products, evolution of both the host computer operating system and transmission system will occur in synchronization. This again favors the adoption by DOD of either the Option 1 or Option 2 that results in TP-4. In these options much of the support cost is covered by the vendors and spread over the large market base. This reduces the development and maintenance cost passed on to the DOD.
それらが作動するホストコンピュータシステムの上のシステム。 製品のベンダーサポートで、ホストコンピュータオペレーティングシステムと伝動装置の両方の発展は同期で起こるでしょう。 これは再びTP-4をもたらすOption1かOption2のどちらかのDODによる採用を支持します。 これらのオプションでは、サポート費用の多くが、大きな販路ベースの上にベンダーでカバーされて、広げられます。 これはDODに通過された開発と維持費を抑えます。
The committee does not believe that a large market beyond the DOD will develop for TCP because worldwide markets for products will be based on the ISO standards. Consequently, if the DOD chooses Option 3, only the DOD-dedicated vendors would supply TCP as standard products resulting in a smaller market and supply for TCP products and limited availability of TCP products.
委員会は、製品の世界的な市場がISO規格に基づくのでDODを超えた大きな販路がTCPのために発展すると信じていません。 その結果、DODがOption3を選ぶなら、DODが専用であるベンダーだけがTCP製品のTCP製品と限られた有用性のための、より小さい市場と供給をもたらす規格品としてTCPを供給するでしょう。
If DOD remains with TCP, many commercial vendors will be forced to develop and support both the commercial standard products (TP-4) and DOD standard special products (TCP) to stay in both markets. In many cases only the large market-based products such as TP-4 will be considered standard and TCP products will be considered special products. The effect is higher development and support cost to the vendors which would be passed on to DOD. Thus the incentive for continuing enhancement to the special product, TCP, would be reduced. This responsibility would be passed to DOD, also resulting in higher costs.
DODがTCPと共に残っていると、多くの商業ベンダーが、両方の市場にいるように商業規格品(TP-4)とDODの両方が標準の特別産(TCP)であると開発して、サポートするのが余儀なくされるでしょう。 多くの場合、TP-4などの大きい市場ベースの製品だけが標準であると考えられるでしょう、そして、TCP製品は特別産であると考えられるでしょう。 効果は、より高い開発とDODに通過されるベンダーへのサポート費用です。 したがって、特別産に増進を続けるための誘因(TCP)は減少するでしょう。 また、より高いコストをもたらして、この責任はDODに通過されるでしょう。
Ease of Transition
変遷の容易さ
The DOD is concerned with the ease and risk associated with transition from the current network architecture using TCP to its future network architecture. The objectives for DOD are to reduce the interruption of data communication services supplied by its active networks; minimize the risk of using an immature, untried protocol; and maximize the use of the critical skills, knowledge, and experience of the engineers who develop the communications products.
DODはTCPを使用する現在のネットワークアーキテクチャから将来のネットワークアーキテクチャまでの変遷に関連している容易さとリスクに関係があります。 DODのための目的は活動的なネットワークによって供給されたデータ通信サービスの中断を抑えることです。 未熟で、実施されていないプロトコルを使用する危険を最小にしてください。 そして、コミュニケーション製品を開発する技術者のきわどい技能、知識、および経験の使用を最大にしてください。
The maturity of TCP and the momentum that exists in the DOD community for implementing future systems using TCP would favor Option 3. Selection of Option 3 would minimize interruption of service and minimize risk. With this option there would be no transition; the DOD would remain with its current policy. There would be no conversion costs and the only risks for DOD would be associated with poor implementations of new TCP-based products.
TCPの円熟とTCPを使用することで将来のシステムを導入するためのDOD共同体に存在する勢いはOption3を支持するでしょう。 Option3の選択は、停電を最小にして、危険を最小にするでしょう。 このオプションと共に、変遷が全くないでしょう。 DODは通貨政策で残っているでしょう。 変換コストが全くないでしょう、そして、DODのための唯一のリスクが新TCPベースの製品の貧しい実装に関連しているでしょう。
The committee believes that much of the technical risk is associated with implementations. Therefore, given the relative state of their specifications and implementations as discussed earlier, the committee feels that the risks are comparable for implementing new products for either TCP or TP-4. Since DOD is acquiring many new networks the implementation risk of either TCP or TP-4 will be equal.
委員会は、技術的なリスクの多くが実装に関連していると信じています。 したがって、より早く議論するとしてのそれらの仕様と実装の状態を親類に考えて、委員会は、TCPかTP-4のどちらかのために新製品を実装するのにおいて、リスクが匹敵していると感じます。 DODが多くの新しいネットワークを買収しているので、TCPかTP-4のどちらかの実装リスクは等しくなるでしょう。
If DOD chooses Option 1, it will display confidence in the TP-4
DODがOption1を選ぶと、それはTP-4での信用を示すでしょう。
National Research Council [Page 56] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[56ページ]RFC942 1985年2月のレポート輸送
specifications and in the vendor's implementations through its immediate commitment for TP-4 use in new military networks. DOD will, in effect, be making a commitment similar to that of vendors who are planning this protocol for their standard products. Since most new networks would not use a transport protocol other than TP-4, this minimizes the number of networks and therefore the cost of converting and maintaining TCP networks to TP-4.
仕様と新しいミリタリー・ネットワークにおけるTP-4使用のための即座の委任を通したベンダーの実装で。 DODは事実上公約をそれらの規格品のためにこのプロトコルを計画しているベンダーのものと同様にするでしょう。 ほとんどの新しいネットワークはTP-4以外のトランスポート・プロトコルを使用しないでしょう、これがネットワークの数を最小にして、したがって、その結果TCPネットワークをTP-4に変換して、維持する費用を最小にします。
Since the standard TP-4 products from vendors are not available today, DOD endorsement of TP-4 may have the effect of accelerating vendor development of standard products. These products are expected to be generally available by 1986. Thus Option 1 can be consistent with the manufacturers' expected product plans. Option 1 provides, therefore, the least conversion cost but with higher risk for DOD conversion.
ベンダーからの標準のTP-4製品が今日利用可能でないので、TP-4のDOD裏書きには、規格品のベンダー開発を加速するという効果があるかもしれません。 一般に、これらの製品が1986年までに利用可能であると予想されます。 したがって、Option1はメーカーの予想された製品プランと一致している場合があります。 したがって、オプション1はDOD変換のために最少の加工費にもかかわらず、より高いリスクに提供されます。
If DOD chooses Option 2, then the risk that TP-4 will not meet DOD needs is reduced since there is no commitment to use this protocol until a successful demonstration is completed. In the interim, many networks will have been committed using TCP, resulting in higher conversion costs than with Option 1. In summary, Option 2 provides a lower risk approach for DOD to convert to TP-4, but will encounter the higher conversion cost.
DODがOption2を選ぶなら、うまくいっているデモンストレーションが終了するまでこのプロトコルを使用する委任が全くないので、TP-4がどんな大会DODの必要性も望んでいない危険は減少します。 その間、Option1より高い変換コストをもたらして、多くのネットワークが、TCPを使用することで遂行されてしまうでしょう。 概要では、Option2はDODがTP-4に変えるように下側のリスクアプローチを提供しますが、より高い加工費に遭遇するでしょう。
There is a great deal of experience with TCP and thus there is an engineering community that is highly knowledgeable about it. As previously noted, however, if DOD remains with TCP, some DOD vendors will be forced to support multiple protocol products. The functional equivalence and similarities between TCP and TP-4 permit an easy transition for the experienced engineer to move from TCP to TP-4. Option 2 allows more time for this transition to occur, and thereby minimizes the risk associated with a complete switch to TP-4.
TCPには大きな経験があります、そして、その結果、それに関して非常に博識な工学共同体があります。 しかしながら、DODがTCPと共に残っているなら上述しているように、いくつかのDODベンダーが、複数のプロトコルが製品であるとやむを得ずサポートするでしょう。 TCPとTP-4の間の機能的な等価性と類似性はTCPからTP-4まで動かす経験豊富な技術者のための簡単な変遷を可能にします。 オプション2は、この変遷が起こるより多くの時間を許容して、その結果、完全なスイッチに関連している危険をTP-4に最小にします。
In addition to the transport protocols, a transition from TCP to TP-4 also involves the conversion of applications. The committee has concluded that the services provided by TCP and TP-4 are comparable and applications software can be moved from TCP to TP-4 without loss of functionality. Obviously, Option 3 requires no conversion to existing applications on current implementations. Option 2 will result in more applications interfacing to TCP than Option 1, thus potentially increasing conversion costs. In the future DOD could minimize the cost of conversion by standardizing the services provided by the transport layer to the applications.
また、トランスポート・プロトコルに加えて、TCPからTP-4までの変遷はアプリケーションの変換にかかわります。 委員会は、TCPとTP-4によって提供されたサービスが匹敵していて、アプリケーションソフトウェアを機能性の損失なしでTCPからTP-4に移されることができると結論を下しました。 明らかに、Option3は現在の実装で既存のアプリケーションに変換を全く必要としません。 オプション2はOption1よりTCPに連結するアプリケーションをもたらして、その結果、潜在的に変換コストを増強するでしょう。 将来、DODは、トランスポート層でアプリケーションに提供されたサービスを標準化することによって、転化費を最小にすることができるでしょう。
Manageability and Responsiveness to DOD Requirements
DOD要件への管理可能性と反応性
The final set of objectives is concerned with the degree of difficulty that DOD will experience in managing its installed networks and future networks. As communications requirements evolve, DOD must have the ability to alter specifications so they will satisfy new requirements. Finally, DOD requires facilities for validation of protocol implementations as they are added to their networks.
目的のファイナルセットはDODがそのインストールされたネットワークと将来のネットワークを経営する際に経験する難易度に関係があります。 コミュニケーション要件が発展するときDODには仕様を変更する能力がなければならないので、彼らは新しい要件を満たすでしょう。 最終的に、それらが自己のネットワークに追加されるとき、DODはプロトコル実装の合法化のために施設を必要とします。
Since Option 3 is to maintain the status quo, no additional management
Option3が現状、どんな追加管理も維持することになっていないので
National Research Council [Page 57] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[57ページ]RFC942 1985年2月のレポート輸送
difficulty is anticipated.
困難は予期されます。
Both Option 1 and Option 2 will cause some additional management difficulties since they require that the current momentum for adopting TCP to be redirected toward TP-4 without loss of intensity. In addition to this change, DOD must manage both TCP and TP-4 networks. This will add to its management difficulties.
彼らがそれを必要とするので、Option1とOption2の両方がいくつかの追加経営危機を引き起こすでしょう。強度の損失なしでTP-4に向かって向け直されるべきTCPを採用するための現在の勢い。 この変化に加えて、DODはTCPとTP-4ネットワークの両方を経営しなければなりません。 これは経営危機に加えるでしょう。
Option 2 will result in greater management difficulties than Option l due to the larger number of TCP systems that must eventually be converted and the larger time period over which both protocols must be supported.
オプション2は結局変換しなければならない多くのTCPシステムと両方のプロトコルをサポートしなければならないより大きい期間のためOption lより大きい経営危機をもたらすでしょう。
There are benefits from each option. If Option 3 is selected, DOD and its vendors have sole responsibility for determining what changes are needed, implementing the change, validating the change and the ongoing maintenance of the standard. If either Option 1 or Option 2 is chosen, then DOD may encounter difficulty in persuading the standards groups to adopt its proposals; however, DOD would gain the experience and knowledge of the industry standards-making bodies. The industry standards bodies should be receptive to good technical arguments for correction of errors or apparent major deficiencies in the protocol. The standards bodies that maintain the standard should become a technical resource for DOD to develop its military specifications.
各オプションからの利益があります。 Option3が選択されるなら、DODとそのベンダーには、どんな変化が必要であるかを決定することへの唯一の責任があります、変化を実装して、規格の変化と進行中のメインテナンスを有効にして。 Option1かOption2のどちらかが選ばれているなら、DODは提案を採用するように規格グループを説得することにおける苦労に遭遇するかもしれません。 しかしながら、DODは規格を作る産業団体に関する経験と知識を獲得するでしょう。 業界標準化団体は誤りの修正のための良い技術的な議論かプロトコルの見かけの主要な欠乏に受容的であるべきです。 規格を維持する標準化団体はDODが軍事の仕様を開発する技術的な資源になるはずです。
Since TP-4 will be a commercial standard, those vendors who adhere to the standard will insure that validation facilities are in place. The National Bureau of Standards has a test facility for TP-4. No such facility exists for TCP. If Option 1 or Option 2 is chosen, DOD can use this facility to validate vendor implementations. DOD should work with NBS to develop a similar facility for TCP. This is particularly important for new implementations of TCP. DOD should continue working with and through NBS in getting needed protocol revisions introduced into the appropriate standards bodies.
TP-4が商業規格になるので、規格を固く守るベンダーは、合法化施設が適所にあるのを保障するでしょう。 規格基準局には、TP-4のためのテスト機能があります。 どんなそのような施設もTCPのために存在していません。 Option1かOption2が選ばれているなら、DODは、ベンダー実装を有効にするのにこの施設を使用できます。 DODは、TCPのために同様の施設を見いだすためにNBSと共に働いているはずです。 TCPの新しい実装には、これは特に重要です。 DODは、NBSとNBSを通して必要なプロトコル改正を適切な標準化団体に導入させる際に働き続けているはずです。
In summary, Option 3 results in no new management difficulties while Option 2 causes the greatest difficulties. Option 1 allows DOD to move toward commercialized standard products with the smallest addition of management tasks.
概要では、Option2は最も大きな困難を引き起こしますが、Option3はどんな新しい経営危機ももたらしません。 オプション1で、DODは管理タスクの最も小さい追加で商業化している規格品に近づくことができます。
EFFECT OF PROPOSED OPTIONS ON MARKET SHARE
提案されたオプションのシェアへの効果
Option 1 would quickly reduce the market held by TCP products as TP-4 products begin to take hold in the marketplace. In addition, it would enhance the ability of U.S. manufacturers to compete in the world networks market based on ISO standards because they would not have to engage in parallel development nor support two sets of protocols for very long. Option 2 could have a comparable but less pronounced effect in the marketplace and it would be delayed. Because of the very probable rapid deployment of TCP-based systems in DOD networks while the TP-4 is still in the demonstration phase, however, many more networks than in Option 1 would probably end up using TCP. This would tend to reduce the U.S. manufacturer's competitive edge in the world
オプション1はTP-4製品が市場で保持を取り始めるのでTCP製品によって保持された市場を急速に減少させるでしょう。 さらに、それは米国のメーカーが非常に長い間並行開発に従事する必要はないでしょう、したがって、ISO規格に基づく市場に世界ネットワークに参加して、2セットのプロトコルにサポートに参加する能力を高めるでしょう。 オプション2は市場に匹敵しますが、それほど著しくない効果を持っているかもしれません、そして、それは遅れるでしょう。 DODでのTCPベースのシステムの非常にありえそうな急速な展開のために、TP-4はOption1よりしかしながら、デモンストレーションフェーズでずっと多くのネットワークを静めることですが、ネットワークは結局、たぶんTCPを使用するでしょう。 これは、世界で米国のメーカーの競争力を減少させる傾向があるでしょう。
National Research Council [Page 58] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[58ページ]RFC942 1985年2月のレポート輸送
market because their need to develop and maintain both TCP products as well as TP-4 products would dilute their skill resources. The same thing would happen with Option 3. Although none of the options would affect the world market for TP-4 greatly, Option 3 would result in a residual market for TCP products in the DOD and related networks.
TCP製品とTP-4製品の両方を開発して、維持する彼らの必要性はそれらの技能リソースを希釈するでしょう、したがって、売り出してください。 同じことはOption3と共に起こるでしょう。 オプションのいずれもTP-4の世界市場に大いに影響しないでしょうが、Option3はDODと関連するネットワークでTCP製品の残りの市場をもたらすでしょう。
Products made specifically for this market would continue to exist, but with functions limited to this specific market, the products would lack some of the advantages of large-scale production and product development.
特にこの市場に作られた製品は存続するでしょうが、機能がこの特定の市場に制限されている状態で、製品は大量生産と商品開発の利点のいくつかを欠いているでしょう。
National Research Council [Page 59] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[59ページ]RFC942 1985年2月のレポート輸送
National Research Council [Page 60] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[60ページ]RFC942 1985年2月のレポート輸送
XI. RECOMMENDATIONS
ξ。 推薦
We first present our basic recommendation and then provide detailed recommendations on aspects that require amplification. These are followed by additional considerations in several important areas relating to the transition plans. Many of our recommendations are closely related to each other, and care should be taken not to consider any single recommendation in isolation.
私たちは、最初に、私たちの基本的な推薦を提示して、次に、増幅を必要とする局面で詳細な推薦を提供します。 追加問題は、変遷プランに関連しながら、いくつかの重要な領域でこれらのあとに続いています。 私たちの推薦の多くが密接に互いに関連します、そして、分離して少しのただ一つの推薦も考えないように注意するべきです。
BASIC RECOMMENDATION
基本的な推薦
The committee unanimously recommends that DOD should adopt the ISO TP-4 (and IP) as DOD costandards with its TCP (and IP) and move toward eventual exclusive use of TP-4. Transition to use of the ISO standards, however, must be managed to maintain operational capabilities and minimize risks. The timing of the transition to use of these protocols is, therefore, a major concern, and the committee was divided on the best schedule to recommend.
委員会は、DODがTCP(そして、IP)と共にDOD costandardsとしてISO TP-4(そして、IP)を採用して、TP-4の最後の専用に近づくはずであることを満場一致して勧めます。 しかしながら、運用能力を維持して、危険を最小にするためにISO規格の使用への変遷を管理しなければなりません。 したがって、これらのプロトコルの使用への変遷のタイミングは主要な関心事です、そして、委員会は推薦する中で最も良いスケジュールについて意見が分かれました。
A majority of the committee favored immediate adoption of the ISO protocols as costandards with TCP, giving major procurements in 1984-85 the option of using these standards (Option 1). A minority favored deferring adoption of the ISO protocols by the DOD until after a demonstration of commercial quality implementations supporting military applications (Option 2). This difference is reflected in detailed recommendations 2-4 below. The reasons for the two viewpoints are based on differences within the committee on the extent of the risk associated with adopting a protocol, TP-4, that has not been implemented on operational networks.
委員会の大部分がTCPと共にcostandardsとしてISOプロトコルの即座の採用を支持しました、1984-85 これらの規格(オプション1)を使用するオプションにおける主要な調達を与えて。 少数が、軍事利用が(オプション2)であるとサポートする商業上質の実装のデモンストレーションの後までDODによるISOプロトコルの採用を延期するのを支持しました。 この違いは以下で詳細な推薦2-4に反映されます。 2つの観点の理由はプロトコル、操作上のネットワークで実装されていないTP-4を採用すると関連しているリスクの範囲の委員会の中で違いに基づいています。
DETAILED RECOMMENDATIONS
詳細な推薦
In the following recommendations the committee provides details about actions that should be taken to implement the basic recommendations. Most of the recommendations involve actions that require the DOD to take the lead role, with occasional support from the NBS Institute for Computer Sciences and Technology. Some recommendations are directed more toward NBS. Other government agencies and parties interested in using DOD protocols or in their future evolution may also find these recommendations applicable.
以下の推薦に、委員会は基本的な推薦を実装するために取られるべきである行動に関する詳細を明らかにします。 推薦の大部分はDODが主役を連れて行くのを必要とする動作にかかわります、NBS Instituteからのコンピューターサイエンシズの時々のサポートとTechnologyと共に。 いくつかの推薦がNBSにさらに向けられます。 また、他の政府機関とDODプロトコルを使用するか、それらの今後の発展に興味を持っているパーティーは、これらの推薦が適切であることがわかるかもしれません。
National Research Council [Page 61] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[61ページ]RFC942 1985年2月のレポート輸送
(1). DOD should rapidly identify "open areas" of the ISO TP-4 specifications where various options for implementation are allowed and define a required subset for use in DOD systems (a MIL-SPEC version of the standards, for example). In doing this, the DOD should work with the NBS with the goal of developing a Federal Standard, that has relatively few options for implementation, facilitates maximum federal interoperability, and makes it clear to vendors which functions are required in their commercial products.
(1). DODは急速に実装のための様々なオプションが許容されているISO TP-4仕様の「空地」を特定して、DODシステム(例えば、規格のMIL規格バージョン)における使用のために必要な部分集合を定義するはずです。 これをする際に、DODが連邦規格を開発するという目標があるNBSと共に働いているはずであり、それは、実装のための比較的わずかなオプションしか持たないで、最大の連邦の相互運用性を容易にして、どの機能がそれらの商品の中で必要であるかをベンダーに断言します。
(2). DOD should aggressively develop and implement a plan for integration of TP-4 as a costandard with TCP and for migration toward its eventual exclusive use. The plan should include provision for rapid completion of a MIL-SPEC (detailed recommendation 1), either validation or demonstration facilities (detailed recommendation 3), timing for procurement of systems with the new protocols (detailed recommendation 4), development of equipment and procedures to support a period of joint operation with both TCP and TP-4 protocols in use, and guidelines for eventual conversion of TCP systems to the new protocols.
(2). DODは積極的にTCPとcostandardとしてのTP-4の統合と移行のためのプランを最後の専用に向かって開発して、実装するはずです。 プランはMIL規格(詳細な推薦1)の急速な完成への支給を含むべきです、合法化かデモンストレーション施設(詳細な推薦3)のどちらか、新しいプロトコル(詳細な推薦4)によるシステムの調達のタイミング、使用中のTCPとTP-4プロトコルとTCPシステムの最後の変換のためのガイドラインの両方で新しいプロトコルに共同経営の期間をサポートする機器と操作法の開発。
Whatever timing is chosen for the introduction of ISO protocols, an extended period must be expected when both TCP and TP-4 are in use in different systems. Hence equipment and procedures must be developed to provide limited communication between systems using the two protocol sets. This will include dual protocol operation for some gateways, relay hosts, service hosts, and terminal concentrators. A secondary purpose of the test system described in detailed recommendation 3 should be to aid in development of this transition support equipment.
ISOプロトコルの導入に選ばれているどんなタイミング、TCPとTP-4の両方が異系統で使用中であるときに、長期間を予想しなければなりません。したがって、2つのプロトコルセットを使用することでシステムの限られたコミュニケーションを提供するために機器と操作法を開発しなければなりません。 これは数門、中継ホスト、サービス・ホスト、および端末の集中装置のための二元的なプロトコル操作を含むでしょう。 詳細な推薦3で説明されたテスト・システムの副次目的はこの変遷支援機材の開発で支援することであるべきです。
Both a general transition strategy and specific transition plans for each existing system should be developed. The switchover from old to new protocols will take place at different times as appropriate for each system during an overall transition period of many years.
一般的な変遷戦略とそれぞれの既存のシステムのための特定の変遷プランの両方が開発されるべきです。 古いプロトコルから新しいプロトコルまでの転換はいろいろな時間に各システムのために何年も総合的な過渡期の間、適宜行われるでしょう。
(3). As soon as possible, the DOD should develop a protocol test facility. If Option 1 is followed, this facility would serve primarily to validate implementations of both old and new protocol sets. If Option 2 is followed, the facility would initially focus on demonstrating the suitability of the new protocols for use in a military environment as rapidly as possible and then provide for testing of commercially supplied protocol implementations.
(3). できるだけ早く、DODはプロトコルテスト機能を見いだすはずです。 Option1が続かれているなら、この施設は、主として古いものと同様に新しいプロトコルセットの実装を有効にするのに役立つでしょう。 Option2が続かれているなら、施設は、初めは、軍事環境における使用のために早急に新しいプロトコルの適合を示すのは焦点を合わせて、商業的に供給されたプロトコル実装のテストに備えるでしょう。
For validation purposes, the NBS protocol-testing facility developed for ISO protocols should serve as a good basis, but extensions to deal with any DOD-specific option for the ISO protocols, performance, and DOD protocols would be necessary. DOD is now beginning such a program.
合法化目的のために、ISOプロトコルのために見いだされたNBSプロトコル試験施設は良い基礎として機能するはずですが、ISOプロトコルのためのどんなDOD特有のオプションにも対処する拡大、性能、およびDODプロトコルが必要でしょう。 DODは現在、そのようなプログラムを始めています。
National Research Council [Page 62] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[62ページ]RFC942 1985年2月のレポート輸送
For a more complete demonstration, commercial-quality implementations of the ISO protocols must be obtained and shown to support military applications in an operational subnetwork such as such as ARPANET or DODIIS. In both cases the facility should also be used for development and demonstration of the transition support equipment mentioned in detailed recommendation 2.
より完全なデモンストレーションにおいて、アルパネットやDODIISなどの操作上のサブネットワークで軍事利用をサポートするためにISOプロトコルの商業品質実装を得られて、示さなければなりません。 どちらの場合も、また、施設は詳細な推薦2で言及した変遷支援機材の開発とデモンストレーションに使用されるべきです。
(4). Procurements of new networks and major upgrades of existing networks should favor use of ISO TP-4 as rapidly as possible. If Option 1 is followed, RFPs may specify the new protocols immediately. If Option 2 is followed, this must await successful completion of the demonstration discussed in recommendation 3. Procurements for existing networks using TCP may continue to require TCP-based equipment until an appropriate conversion point is reached (see detailed recommendation 2).
(4). 新しいネットワークの調達と既存のネットワークの大きな更新は早急にISO TP-4の使用を支持するべきです。 Option1が続かれているなら、RFPsはすぐに、新しいプロトコルを指定するかもしれません。 Option2が続かれているなら、これは推薦3で議論したデモンストレーションの無事終了を待たなければなりません。 適切な変換ポイントに達するまで(詳細な推薦2を見てください)、TCPを使用する既存のネットワークへの調達はずっとTCPベースの設備を必要とするかもしれません。
The purpose of this recommendation is to minimize spending on new TCP implementations and their subsequent conversion to TP-4 where possible, while recognizing that some additions to TCP-based systems will also be needed. If Option 2 is followed, immediate requirements for new systems may force new implementations of TCP in these cases also because the demonstration is not completed at the time RFPs must be issued.
この推薦の目的はまた、TCPベースのシステムへのいくつかの追加が必要であると認めている間、可能であるところで新しいTCP実装と彼らのその後の変換への支出をTP-4に最小にすることです。 RFPsを発行しなければならないときデモンストレーションが終了していないので、Option2が続かれているなら、新しいシステムのための当座需要高はこれらの場合でもTCPの新しい実装を強制するかもしれません。
(5). As part of a transition plan, a transport service interface to higher-level protocols more like that of TP-4 should be developed for TCP and tested with existing higher-layer protocols.
(5). 変遷プランの一部として、さらにTP-4のもののような上位レベル・プロトコルへの輸送サービスインタフェースは、TCPのために開発されて、既存の上位層プロトコルでテストされるべきです。
This should serve as a rapid test of whether existing DOD protocols can make effective use of the somewhat different style of service that TP-4 provides. It should also allow higher-level protocols to be modified to make use of TP-4 in parallel with the implementation of TP-4 itself, making the ultimate transition to TP-4 more rapid and certain of success. Finally, it may allow use of a single version of the higher-level protocols to be used on both TCP and TP-4 equipment.
既存のDODプロトコルがいくらか異なったスタイルのサービスの有効な使用をそのTP-4にすることができるかどうかに関する迅速試験が提供されるとき、これは役立つべきです。 また、それは、上位レベル・プロトコルがTP-4自身の実装と平行してTP-4を利用するように変更されるのを許容するべきです、TP-4への究極の変遷を成功が、より急速で確かにして。 最終的に、それは、上位レベル・プロトコルのただ一つのバージョンの使用がTCPとTP-4設備の両方で使用されるのを許容するかもしれません。
(6). DOD should continue using existing DOD-specific, higher-level protocols for operational purposes (Telnet, FTP, and Simple Mail Transfer Protocol, for example) but minimize effort on their further development and plan to adopt suitable ISO protocols as they are developed. Research on protocols providing new services (multimedia mail, compressed video, and voice store-and-forward, for example) should continue. The committee is pleased to find that DOD is already pursuing this course of action.
(6). DODは、操作上の目的(例えば、telnet、FTP、およびシンプルメールトランスファプロトコル)に既存のDOD特有の、そして、よりハイレベルのプロトコルを使用し続けていますが、彼らのさらなる開発のときに取り組みを最小にして、それらが開発されているとき適当なISOプロトコルを採用するのを計画しているはずです。 新種業務(例えばメール、圧縮されたビデオ、および声が保存して、転送するマルチメディア)を提供するプロトコルの研究は続くべきです。 DODが既にこの行動を追求しているのがわかって、委員会は嬉しいです。
(7). The NBS Institute for Computer Sciences and Technology should maintain close liaison with DOD to ensure that DOD needs for new protocols and modifications to existing standards are effectively represented to appropriate standards bodies. This should include research areas such as multimedia mail where there is significant commercial as well as military interest.
(7). コンピューターサイエンシズとTechnologyのためのNBS Instituteは、事実上、新しいプロトコルのDODの必要性と既存の規格への変更が標準化団体を当てるために表されるのを保証するためにDODとの緊密な連携を維持するはずです。 これは重要な商業の、そして、軍事の関心があるマルチメディアメールなどの研究領域を含むべきです。
National Research Council [Page 63] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[63ページ]RFC942 1985年2月のレポート輸送
The committee is pleased to find that this is already being done through contracts from DOD for ICST to represent its interests in standardization activities. Further cooperation (in demonstrating and testing protocols, for example) could occur.
ICSTが標準化活動への関心を表すように契約法を通してDODからこれを既にしているのがわかって、委員会は嬉しいです。 さらなる協力(例えばプロトコルを示して、テストする際に)は起こることができました。
(8). The NBS and DOD should collaborate from the outset in the development of new protocols for use as federal standards. This will ensure early agreement on functions, features, and services of the protocols under development. The NBS should present the developing work early to the ISO standardization activities to expedite convergence on internationally acceptable standards.
(8). NBSとDODは使用のために連邦の規格として新しいプロトコルの開発における着手から共同するはずです。 これは開発中のプロトコルの機能、特徴、およびサービスの早めの協定を確実にするでしょう。 NBSは、国際的に許容できる規格で集合を速めるために早くISO標準化活動に展開している仕事を提示するはずです。
Such collaboration could help ensure that future protocol standards will be developed in a single, coordinated process that results in a single standard accommodating both DOD, other federal agencies, and commercial needs.
そのような共同は、将来のプロトコル標準がDOD、他の連邦機関と商業必要性の両方を収容しながら単本位制をもたらす単一の、そして、連携しているプロセスで開発されるのを確実にするのを助けるかもしれません。
(9). DOD and NBS should develop additions to protocol specifications to support preemption of limited resources by high-precedence users. Such capabilities are needed during high-load situations such as might develop during wartime or other crisis situations. They are not yet part of either the TCP or TP-4 specifications or existing implementations. This should be an example of the sort of collaboration mentioned in detailed recommendations 7 and 8.
(9). DODとNBSは、高先行ユーザによる限りある資源の先取りをサポートするために仕様を議定書の中で述べるために追加を開発するはずです。 そのような能力が戦時の間に展開するかもしれないような高負荷状況か他の危機的状況の間、必要です。 しかし、それらはTCPかTP-4仕様か既存の実装のどちらかの一部ではありません。 これは詳細な推薦7と8で言及した共同の種類に関する例であるべきです。
This is important to avoid possible incompatibilities between different implementations of the same specification as discussed in Section III. It is likely that vendors would welcome guidance on how to deal with open areas of the specifications, and early action by DOD could result in their mandated subset becoming the de facto standard for most commercial implementations as well, with consequent benefits to DOD. This is a good area for cooperation between DOD and NBS.
これは、セクションIIIの議論するのと同じ仕様の異なった実装の間の可能な非互換性を避けるために重要です。 ベンダーはどう仕様の空地に対処するかに関して指導を歓迎しそうでしょう、そして、DODによる早めの動作はまた、ほとんどの商業実装のためのデファクトスタンダードになるそれらの強制された部分集合をもたらすかもしれません、DODへの結果の利益で。 これはDODとNBSとの協力のための良い領域です。
ADDITIONAL CONSIDERATIONS
追加問題
Transition Plan
変遷プラン
This section describes the major elements of a transition plan from use of TCP to use of TP-4 in DOD systems. The plan will vary depending on the option chosen. Both Option 1 and Option 2 share a number of common elements that are discussed first, including development of a MIL-SPEC, protocol-testing facilities, and transition support equipment. If Option 2 is followed, a demonstration of TP-4 must also be undertaken.
このセクションはTCPの使用からDODシステムにおけるTP-4の使用まで変遷プランの多量栄養素について説明します。選ばれたオプションによって、プランは異なるでしょう。 Option1とOption2の両方が最初に議論する多くの一般的な要素を共有します、MIL規格、プロトコル試験施設、および変遷支援機材の開発を含んでいて。 また、Option2が続かれているなら、TP-4のデモンストレーションを引き受けなければなりません。
MIL-SPEC. As noted in recommendation 1, several open areas and options in the ISO TP-4 must be specified in order to have complete and compatible protocol implementations. Completion of this specification by the DOD should be a top priority objective.
MIL規格。 推薦1で注意されるように、完全でコンパチブルプロトコル実装を持つためにISO TP-4のいくつかの空地とオプションを指定しなければなりません。 DODによるこの仕様の完成は最優先目的であるべきです。
National Research Council [Page 64] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[64ページ]RFC942 1985年2月のレポート輸送
Protocol-Testing Facilities. As noted in recommendation 3, test facilities for protocol implementations are essential. Under Option 1, this facility should serve primarily to validate implementations of both old and new protocol sets. If Option 2 is followed, the facility should initially focus on demonstrating the suitability of the new protocols for use in a military environment as rapidly as possible, and provide for testing of commercially supplied protocol implementations.
プロトコル試験施設。 推薦3で注意されるように、プロトコル実装のためのテスト機能は不可欠です。 Option1の下では、この施設は、主として古いものと同様に新しいプロトコルセットの実装を有効にするのに役立つはずです。 Option2が続かれているなら、施設は、初めは軍事環境における使用のために早急に新しいプロトコルの適合を示すのは焦点を合わせて、商業的に供給されたプロトコル実装のテストに備えるはずです。
For validation purposes, the NBS protocol-testing facility developed for ISO protocols should serve as a good basis, but extensions to deal with any DOD-specific options for the ISO protocols, performance, and DOD protocols would be necessary. The DOD has stated that such a program has been started.
合法化目的のために、ISOプロトコルのために見いだされたNBSプロトコル試験施設は良い基礎として機能するはずですが、ISOプロトコルのためのどんなDOD特有のオプションにも対処する拡大、性能、およびDODプロトコルが必要でしょう。 DODは、そのようなプログラムが始動されたと述べました。
Transition Support Equipment. In any transition plan it must be assumed that the large body of systems with existing TCP implementations will take a substantial period of time to switch completely to the use of the ISO protocols. Some networks will include many different communities sharing a common communications backbone. Members of one community communicate primarily among themselves, but occasionally outside their community. While members of one community are likely to change over as a group, different communities will change to use the new protocols at different times.
変遷支援機材。 どんな変遷プランでも、既存のTCP実装があるシステムの大きいボディーが完全にISOプロトコルの使用に切り替わるにはかなりの期間でかかると思わなければなりません。 いくつかのネットワークが一般的なコミュニケーションバックボーンを共有する多くの異なった共同体を含むでしょう。 1つの共同体のメンバーは主として自分たち、しかし、時折彼らの共同体の外で交信します。 1つの共同体のメンバーがグループとして切り替わりそうな間、異なった共同体は、いろいろな時間に新しいプロトコルを使用するために変化するでしょう。
Hence an interim period must be anticipated when some systems are using the old protocols and others, the new protocols. The transition plan must provide some means of allowing interaction between old and new systems where required during this period. Toward this end, a number of relay hosts may need to be developed that support both old and new protocols. These will allow automatic-staged forwarding of electronic mail between old and new systems and manually set up file transfer or remote terminal access via the relays. Performance through these relays will not be as good as with direct connections, but the relays should provide an adequate level of service for occasional interactions among different communities of the internet system.
いくつかのシステムが古いプロトコルと他のものを使用する新しいプロトコルであるときに、したがって、暫時を予期しなければなりません。 変遷プランはこの期間、必要であるところに古くて新しいシステムの間の相互作用を許容するいくつかの手段を提供しなければなりません。 このような目的で両方が古くて新しいプロトコルであるとサポートするホストが開発されるために必要とするかもしれないリレーの数。 これらは、古くて新しいシステムの間で電子メールの自動に上演された推進を許して、リレーで手動でファイル転送か遠隔端末アクセスをセットアップするでしょう。 これらのリレーによるパフォーマンスはダイレクト接続ほど良くないでしょうが、リレーはインターネットシステムの異なった共同体での時々の相互作用のための適切なレベルのサービスを提供するはずです。
When more frequent interaction is anticipated and better service is needed, major service hosts should support both old and new protocol sets concurrently so they can provide service directly without requiring the use of relays. Such service hosts include widely used time-sharing machines, file servers, and special servers such as Network Information Centers, Network Operations Centers, and Administrator Machines (providing mailboxes of network administrators, for example). Some dual protocol servers may also act as relays where the load of both functions can be supported.
より頻繁な相互作用が予期されて、より良いサービスが必要であるときに、主要サービスホストは、直接リレーの使用を必要としないでサービスを提供できるように同時に両方が古くて新しいプロトコルセットであるとサポートするべきです。 そのようなサービス・ホストはNetwork Informationセンターズや、ネットワークオペレーションセンターズや、Administrator Machines(例えば、ネットワーク管理者のメールボックスを提供する)などの広く使用された時分割マシン、ファイルサーバー、および特別なサーバを入れます。 また、いくつかの二元的なプロトコルサーバが両方の負荷が機能するリレーを支えることができるように行動するかもしれません。
Terminal concentrators for general use must also support both protocol sets so that connections to both old and new hosts can be made directly.
また、一般的使用のための端末の集中装置は、直接古いものと同様に新しいホストとの接続を作ることができるように両方のプロトコルセットを支えなければなりません。
National Research Council [Page 65] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[65ページ]RFC942 1985年2月のレポート輸送
Gateways must support both old and new IPs so hosts using either one may send internet traffic. This requirement could be relaxed in the case of entire networks that will switch over simultaneously and hence will only need one type of IP traffic. Gateways should not have to translate between old and new IPs--it will be assumed that both source and destination hosts are using the same protocols or going through an explicit relay intermediate host.
ゲートウェイが、両方が古くて新しいIPsであるとサポートしなければならないので、どちらかを使用しているホストはインターネットトラフィックを送るかもしれません。 この要件は、同時の上で切り替わる全体のネットワークの場合でリラックスできて、したがって、1つのタイプのIPトラフィックを必要とするだけでしょう。 ゲートウェイは古くて新しいIPsの間で翻訳されるはずである必要はありません--ソースとあて先ホストの両方が同じプロトコルを使用するか、または明白なリレー中間的ホストを通っていると思われるでしょう。
This latter point requires some elaboration. If one type of IP packet arrives at a destination host or gateway that only handles the other type, it must be discarded. It would be good if, in addition, a suitable ICMP error packet could be returned in the unsupported protocol so it would be meaningful to the source. To avoid this situation the internet-host name table maintained by the Network Information Center should indicate which protocol(s) each host supports. Then when a source host looks up the address of a destination, it will also determine which type protocol to use or if a relay is required.
この後者のポイントはいくらかの労作を必要とします。 1つのタイプのIPパケットがもう片方のタイプを扱うだけであるあて先ホストかゲートウェイに到着するなら、それを捨てなければなりません。 サポートされないプロトコルでさらに、適当なICMP誤りパケットを返すことができるなら良いので、ソースに、それは重要でしょう。 この状況を避けるために、Networkインフォメーション・センターによって維持されたインターネットホスト名テーブルは、各ホストがどのプロトコルをサポートするかを示すはずです。 そして、また、送信元ホストが目的地のアドレスを調べると、それは、どのタイププロトコルを使用するか、そして、またはリレーが必要であるかどうか決定するでしょう。
Demonstration Plan
デモンストレーションプラン
If Option 2 is followed, a major demonstration of the ISO protocols in a military environment must be undertaken. Any such demonstration should proceed by stages beginning with the implementation of TP-4 in one network (15). Then the demonstration would be extended to include internetting (still with DOD IP) to validate the suitability of TP-4 as a replacement for TCP. The demonstration would then be further extended to employ the ISO IP in place of DOD IP.
Option2が続かれているなら、軍事環境における、ISOプロトコルの主要なデモンストレーションを引き受けなければなりません。 TP-4の実装で1つのネットワーク(15)で始まる段階に従って、どんなそのようなデモンストレーションも続くべきです。 そして、デモンストレーションは、TCPとの交換としてTP-4の適合を有効にするためにinternettingするのを(まだDOD IPと共に)含むように広げられるでしょう。 そして、デモンストレーションは、DOD IPに代わってISO IPを使うためにさらに広げられるでしょう。
Stand-Alone TP-4 Network Demonstration. The first stage of any transition plan must be to establish a demonstration network or subnetwork using TP-4 in place of TCP under existing higher-level protocols. This step will require selection of a suitable network (or subnetwork), procurement of TP-4 implementations for hosts and terminal access controllers on that network, and modification of higher-level protocols to use TP-4. The demonstration should include sufficient use of real applications to test the protocols in an operational environment.
スタンドアロンのTP-4はデモンストレーションをネットワークでつなぎます。 どんな変遷プランの第一段階も既存の上位レベル・プロトコルの下におけるTCPに代わってTP-4を使用することでデモンストレーションネットワークかサブネットワークを証明することでなければなりません。 このステップは、TP-4を使用するために適当なネットワーク(または、サブネットワーク)の選択、ホストのためのTP-4実装とそのネットワークの端末の入場管理者の調達、および上位レベル・プロトコルの変更を必要とするでしょう。 デモンストレーションは運用環境に実際のアプリケーションのプロトコルをテストできるくらいの使用を含むべきです。
To limit the amount of change attempted at one time, the DOD IP may be retained and used under TP-4. Alternatively, if ISO IP development status seems to warrant it, ISO IP may be installed along with TP-4.
DOD IPは、ひところ試みられた変化の量を制限するのに、TP-4の下で保有されて、使用されるかもしれません。 あるいはまた、ISO IP開発状態がそれを保証するように思えるなら、ISO IPはTP-4と共にインストールされるかもしれません。
----- (15) For the remainder of this chapter, the use of TCP and TP-4 to include their respective IPs will no longer hold. The four entities--Transmission Control Protocol (TCP) and its Internet Protocol (DOD IP) and the Transport Protocol (TP-4) and its Internetwork Protocol (ISO IP)--will be treated individually.
----- (15) 本章の残りのために、それらのそれぞれのIPsを含むTCPとTP-4の使用はもう当てはまらないでしょう。 4つの実体(通信制御プロトコル(TCP)、インターネットプロトコル(DOD IP)、Transportプロトコル(TP-4)、およびそのInternetworkプロトコル(ISO IP))が個別に扱われるでしょう。
National Research Council [Page 66] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[66ページ]RFC942 1985年2月のレポート輸送
In the latter case, all TP-4 hosts would be on the same network anyway, so that IP will only be used between hosts and no gateways will be involved and no gateway modifications will be needed.
後者の場合では、すべてのTP-4ホストがとにかく同じネットワークの一員でしょう、IPがホストの間で使用されるだけであり、ゲートウェイが全くかかわらないで、またゲートウェイ変更は全く必要でないように。
The hosts involved could be dedicated to the demonstration and hence only support TP-4 and only be able to interact with other demonstration network hosts or be concurrently supporting TCP and DOD IP for operational traffic to other "normal" hosts. In the latter case, no forwarding or relaying of traffic by hosts between normal and ISO logical networks would be allowed or performed (the demonstration network would be logically closed).
ホストは、デモンストレーションとしたがって、唯一のサポートTP-4に捧げることができて、他のデモンストレーションネットワークホストと対話できるか、または操作上のトラフィックのために同時にTCPとDOD IPをサポートしているだけであることを他の「正常な」ホストに伴いました。 標準とISOの間のホストによるトラフィックの後者の場合、推進またはリレーでないのでは、論理的なネットワークは、許容されているか、または実行されるでしょう(デモンストレーションネットワークは論理的に休業するでしょう)。
Stand-Alone TP-4 Internet Demonstration. The next step would be to expand the demonstration to include more than one network (at least logically) and hence involve gateways. If only TP-4 is involved, this is a simple extension to test TP-4 over longer internet paths with more variable performance. If ISO IP is also being tested at the same time, modification of the gateways involved will also be required as indicated in the next section.
スタンドアロンのTP-4インターネットデモンストレーション。 次のステップは1つ以上のネットワークを含んで(少なくとも論理的に)、したがって、ゲートウェイにかかわるためにデモンストレーションを広げるだろうことです。 TP-4だけがかかわるなら、これは、より長いインターネット経路にわたって、より可変な性能でTP-4をテストする単純拡大です。 また、また、ISO IPが同時にテストされる予定であると、かかわったゲートウェイの変更が次のセクションにみられるように必要でしょう。
Stand-Alone ISO IP Demonstration. Once TP-4 has been tested, introduction of the ISO IP to replace DOD IP may commence. In addition to simply replacing one IP with the other in hosts and gateways, this will require modification of the gateways to perform ICMP and GGP on top of the ISO IP.
スタンドアロンのISO IPデモンストレーション。 TP-4がいったんテストされると、DOD IPを取り替えるISO IPの導入は始まるかもしれません。 ホストとゲートウェイで単に1IPをもう片方に取り替えることに加えて、これは、ISO IPの上でICMPとGGPを実行するためにゲートウェイの変更を必要とするでしょう。
These gateways could either be dedicated to the demonstration and hence have only ISO IP, or could be concurrently supporting normal operational traffic via DOD IP. In the latter case, once again, no forwarding of traffic between ISO demonstration internet and normal systems would be allowed.
これらのゲートウェイは、デモンストレーションに捧げられて、したがって、ISO IPしか持つことができませんでしたし、また同時にDOD IPを通して正常な操作上のトラフィックをサポートしているかもしれません。 後者の場合では、もう一度、ISOデモンストレーションインターネットと正常なシステムの間のトラフィックを進めることは許されないでしょう。
At the conclusion of these three steps, the ISO TP-4 and IP could be deemed to have demonstrated their basic functional suitability in a military environment. The transition support equipment described above should have been developed in parallel, providing the capability to smoothly and successfully switch operational systems using the old protocols to use of the new protocols.
これらの3ステップの結論ときに、ISO TP-4とIPが軍事環境における彼らの基本的な機能的な適合を示したと考えることができました。 上で説明された変遷支援機材は平行で開発されるべきでした、新しいプロトコルの使用に古いプロトコルを使用することで基幹系システムをスムーズに首尾よく切り換える能力を提供して。
Switchover of User Systems
ユーザシステムの転換
Once the above preparations have been made and the demonstration completed, if Option 2 is being followed, the switchover of user systems can commence. Each network or community within a network should be able to switch at its convenience and maintain the ability to interact with other systems. The user systems will not be required to support operational use of both protocol sets simultaneously at any time unless they wish to do so for their own reliability purposes.
いったん上の準備をして、Option2が続かれるユーザシステムの転換であるなら終了するデモンストレーションがすることができた後、始まってください。 ネットワークの中のそれぞれのネットワークか共同体が、便利に切り替わって、他のシステムと対話する能力を維持できるべきです。それら自身の信頼性の目的のためにそうしたくないなら、ユーザシステムは、いつでも同時に両方のプロトコルセットの操作上の使用をサポートするのに必要でないでしょう。
National Research Council [Page 67] RFC 942 February 1985 Report Transport on Protocols
プロトコルにおける調査評議会の[67ページ]RFC942 1985年2月のレポート輸送
Switchover of user systems also requires a personnel-training effort. While earlier steps involved a relatively small number of specialists and support staff at major sites, this step will affect all user sites, and their network support staff must be trained in the new procedures.
また、ユーザシステムの転換は人材育成取り組みを必要とします。 以前のステップが主要なサイトで比較的少ない数の専門家と補助スタッフを伴っていた間、このステップはすべてのユーザの現場に影響するでしょう、そして、新しい手順で彼らのネットワーク補助スタッフを訓練しなければなりません。
Once switchover of all systems to the new protocol set is complete, support for the old protocols by TACS, service hosts, and gateways can be removed.
新しいプロトコルセットへのすべてのシステムの転換がいったん完全になると、TACS、サービス・ホスト、およびゲートウェイのそばの古いプロトコルのサポートを取り除くことができます。
Lessons Learned from the ARPANET NCP-to-TCP Transition
アルパネットNCPからTCPへの変遷から学習されたレッスン
The following points summarize some important lessons learned during the ARPANET transition from NCP to TCP (16).
以下のポイントはNCPからTCP(16)までのアルパネット変遷の間に学習されたいくつかの重要な教訓をまとめます。
Conversion of TACs and service hosts to support both protocols before the transition of user hosts starts is essential.
ユーザー・ホスト始めの変遷が不可欠になる前にTACsの、そして、サービスの変換は両方のプロトコルをサポートにホスティングします。
Relay capabilities were heavily used for mail, but used little for other purposes.
リレー能力は、メールに大いに使用されましたが、他の目的に少ししか使用されませんでした。
The Network Information Center was not ready to support the new protocols and this caused problems in distributing the host name table.
Networkインフォメーション・センターは新しいプロトコルをサポートする準備ができていませんでした、そして、これはテーブルというホスト名を分配する際に問題を起こしました。
There were significant performance problems that required careful analysis and parameter tuning after the transition. These were unavoidable because no service host had been stressed prior to the switchover, with a full user load over a long time period using the new protocols.
変遷の後に慎重な分析とパラメタチューニングを必要とした重要な性能問題がありました。 サービス・ホストが全く転換の前に圧力を加えられていなかったので、これらは避けられませんでした、長い期間にわたる完全なユーザ負荷が新しいプロトコルを使用していて。
----- (16) For additional information, see ARPANET Request for Comments: NCP/TCP Transition Plan, J. Postel, (Menlo Park, California: SRI International Telecommunications Sciences Center, November 1981).
----- (16) 追加情報に関しては、Commentsに関してアルパネットRequestを見てください: NCP/TCP変遷プラン、J.ポステル(メンローパーク(カリフォルニア): 科学が中心に置くSRIインターナショナルテレコミュニケーション、1981年11月)。
National Research Council [Page 68]
調査評議会[68ページ]
一覧
スポンサーリンク
