RFC898 日本語訳
0898 Gateway special interest group meeting notes. R.M. Hinden, J.Postel, M. Muuss, J.K. Reynolds. April 1 1984. (Format: TXT=42112 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Hinden (BBN)
Request for Comments: 898 J. Postel (ISI)
M. Muuss (BRL)
J. Reynolds (ISI)
April 1984
Hinden(BBN)がコメントのために要求するワーキンググループR.をネットワークでつないでください: 898 J.ポステル(ISI)M.Muuss(BRL)J.レイノルズ(ISI)1984年4月
GATEWAY SPECIAL INTEREST GROUP MEETING NOTES
ゲートウェイ特殊利益集団ミーティング注意
STATUS OF THIS MEMO
このメモの状態
This memo is a report on a meeting. No conclusions, decisions, or policy statements are documented in this note.
このメモはミーティングに関するレポートです。 どんな結論、決定も、または施政方針もこの注意に記録されません。
INTRODUCTION
序論
This memo is a report on the Gateway Special Interest Group Meeting that was held at ISI in Marina del Rey, California on 28 and 29 February 1984. Robert Hinden of BBNCC chaired, and Jon Postel of ISI hosted the conference. Approximately 35 gateway designers and implementors attended. These notes are based on the recollections of Jon Postel and Mike Muuss. Under each topic area are Jon Postel's brief notes, and additional details from Mike Muuss.
このメモはマリナデルレイのISI、28のカリフォルニア、および1984年2月29日に持たれていたゲートウェイ特別利益団体Group Meetingに関するレポートです。 ロバートHinden、BBNCCでは、ISIのまとめられるのとジョン・ポステルは会議を主催しました。 およそ35人のゲートウェイデザイナーと作成者が出席しました。 これらの注意はジョン・ポステルとマイクMuussの回想に基づいています。 それぞれの話題領域の下では、ジョン・ポステルの短信、およびマイクMuussから追加詳細があります。
The rest of this memo has three sections: the agenda, notes on the talks, and the attendees list.
このメモの残りには、3つのセクションがあります: 議題、会談に関する注、および出席者は記載します。
MEETING AGENDA
会議の議題
Tuesday, February 28
2月28日火曜日
9:00 Opening Remarks -- BBN - Hinden
9:15 Opening Remarks -- ISI - Postel
9:30 The MIT C Gateway -- MIT - Martin
10:00 The Butterfly Gateway -- BBN - Hinden
10:30 Break
11:00 The EGP C Gateway -- ISI - Kirton
11:20 The BRL Gateway -- BRL - Natalie
11:40 The CMU Gateway -- CMU - Accetta
12:00 Lunch
1:30 The Wisconsin BITNET/CSNET Gateway -- UWisc - Solomon
2:00 LAN to X.25 Gateway -- Computer Gateways Inc. - Buhr
2:20 ISI-UCI Gateway -- UCI - Rose
2:40 FACC Gateway -- FACC - Holkenbrink
3:00 Break
3:30 Lincoln IP/ST Gateway -- LL - Forgie/Kantrowitz
3:50 Minimal Stub Gateways -- MITRE - Nabielsky
4:10 Discussion
9:00 所見--ISI--ポステル9:30を開きながら所見--BBN--Hinden9:15を開いて、MIT Cゲートウェイ--MIT--マーチン10:00Butterflyゲートウェイ--BBN--Hinden10:30はEGP Cゲートウェイ--ISI--BRLゲートウェイ--BRL--11:00カートン11:20ナタリー11:40米カーネギーメロン大学ゲートウェイ--米カーネギーメロン大学--Accetta12:00昼食1:30ウィスコンシンBitnet/CSNETゲートウェイを壊します; UWisc--X.25ゲートウェイへのソロモン2:00LAN--コンピュータゲートウェイ株式会社--Buhr2:20ISI-UCIゲートウェイ--UCI--バラ2:40FACCゲートウェイ--FACC--Holkenbrink3:00は第Gateway(LL)Forgie/カントロウィッツ3:50リンカーンIP/最小量の3:30スタッブ門--斜め継ぎ--Nabielsky4:10議論を壊します。
Hinden, Postel, Muuss, & Reynolds [Page 1]
Hinden、ポステル、Muuss、およびレイノルズ[1ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
Wednesday, February 29
2月29日水曜日
9:00 Opening Remarks -- BBN - Hinden
9:10 SPF routing -- BBN - Seamonson
9:35 Multiple Constraint Routing -- SRI - Shacham
10:00 FACC Multinet Gateway Routing -- FACC - Cook
10:30 Break
11:00 Metanet Gateway -- SRI - Denny
11:20 Address Mapping and Translation -- UCL - Crowcroft
11:40 Design of the FACC Multinet Gateway -- FACC - Cook
12:00 Lunch
1:30 SAC Gateway -- SRI - Su/Lewis
2:00 EGP -- Linkabit - Mills
2:30 Congestion Control -- FACC - Nagle
3:00 Break
3:30 A Gateway Congestion Control Policy--NW Systems - Niznik
4:00 Discussion
9:00初めのRemarks--BBN--Hinden9:10SPFルーティング--BBN--Seamonson9:35Multiple Constraintルート設定--SRI--Shacham10:00FACC Multinetゲートウェイのルート設定(FACC)は10:30のBreak11:00Metanetゲートウェイ(SRI)デニー11:20Address MappingとTranslationを料理します; UCL--FACC Multinetゲートウェイのクロウクロフト11:40デザイン--FACC--クック12:00昼食1:30嚢のゲートウェイ--様--Su/ルイス2:00EGP(Linkabit)はゲートウェイ輻輳制御方針あたり輻輳制御--FACC--ネーグル3:00Break2:30 3:30--NWシステム--Niznik4:00議論を製粉します。
NOTES ON THE MEETING
ミーティングに関する注
The MIT C Gateway -- MIT - Martin
MIT Cゲートウェイ--MIT--マーチン
Postel: A description of the gateway implemented at MIT. The
gateway was first developed by Noel Chiappa. It is written in C.
The MIT environment has 32 internal networks which are treated as
subnets of the MITNET on the Internet. The MIT gateways then do
subnet routing in their interior protocol. The subnet routing
scheme is similar to GGP. Liza has added an EGP implementation to
this gateway.
ポステル: MITで実行されたゲートウェイの記述。 ゲートウェイは最初に、クリスマスChiappaによって開発されました。 それはC.に書かれています。MIT環境はインターネットにMITNETのサブネットとして扱われる32の内部のネットワークを持っています。 そして、MITゲートウェイはそれらの内部のプロトコルでのサブネットルーティングをします。 サブネットルーティング計画はGGPと同様です。 ライザはこのゲートウェイにEGP実現を加えました。
Muuss:
Muuss:
Campus network/project Athena
Dynamic routing
Congestion control - grad student
+---------------+---+
Class A net : | 18|subnet|res|host|
+---------------+---+
キャンパスネットワーク/プロジェクトアティナDynamicルーティングCongestionコントロール--大学院生+---------------+---+ クラスAネット: | 18|サブネット|res|ホスト| +---------------+---+
"Bridges" forward between subnets.
サブネットの間に前方に「橋を架けます」。
Campus Network and Project Athena 65 VAX 750s, 200 IBM PCs.
キャンパスネットワークとプロジェクトアティナ65VAX750、200IBM PC。
Hosts: Now = 400, 1986 = 3,000, 1990 = 10,000
ホスト: 現在、400、1986 = 3,000、1990 = 10,000と等しいです。
Subnets: Now = 42, 1985 = 60, 1990 = 200, (4 subnets/building)
サブネット: 現在の1985 = 60と、1990 = 200に=42(4つのサブネット/ビル)
Protocols: Internet, DECnet, Chaosnet
プロトコル: インターネット、DECnet、Chaosnet
Hinden, Postel, Muuss, & Reynolds [Page 2]
Hinden、ポステル、Muuss、およびレイノルズ[2ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
FiberOptic spine between campus buildings.
キャンパスビルの間のFiberOptic背骨。
MIT gateways:
MITゲートウェイ:
11/03s and 11/23s
68000 on Abus
6800 on Multibus (Bridge communications)
11/03と11/23、マルチバスのAbus6800の上の68000(橋のコミュニケーション)
MIT C gateway -
Runs under MOS, bridge OS, homegrown OS. Multiple protocols,
multiple interfaces.
MIT Cゲートウェイ--MOSの下の走行、橋のOS、国産のOS。 複数のプロトコルであり、倍数は連結します。
11/03 - 100 packets/sec.
11/23 - 180 packets/sec.
11/03--100パケット/秒 11/23--180パケット/秒
GGP - Gw/Gw
EGP - Exterior Gw
IGP - Interior Gw
GGP--Gw/Gw EGP--外のGw IGP--内部のGw
EGP: Autonomous systems
EGP: 自律システム
EGP:
Neighbor acquisition
Hello/I heard you
Net reachability poll
Net reachability message
EGP: 隣人獲得Hello/私があなたの声を聞いた、ネット可到達性投票ネット可到達性メッセージ
MIT IGP:
MIT IGP:
IP header on EGP protocol
Dest: net number, subnet number, 0, 0377 (broadcast address)
EGPプロトコルDestの上のIPヘッダー: 数、サブネット番号に0、0377を網で覆ってください。(放送演説)
IGP header:
IGPヘッダー:
Autonomous system number
Sequence number
Tasks:
Propagate exterior and subnet routing.
自律システム数のSequence番号Tasks: 外部とサブネットルーティングを伝播してください。
Packets
Ext route request, and update Routing server
Default gateway
Exceptional gateways
Nets reached
Extが発送するパケットは、ネットが達したルート設定サーバDefaultゲートウェイExceptionalゲートウェイを要求して、アップデートします。
MIT - Gw broadcasts initial routings when it comes up, and again
on each change, net is flooded on each change several times. Each
bridge can ask for help.
MIT--来るとき、Gwは初期のroutingsを放送して、ネットは各変化で再び各変化では、何度か水につかっています。 各橋は助けを求めることができます。
Hinden, Postel, Muuss, & Reynolds [Page 3]
Hinden、ポステル、Muuss、およびレイノルズ[3ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
Future: Wideband net gateway from BBN will also sit on net 18,
and an MIT routing server to acquire routing information. Trick -
BBN-Gw will be on an Ethernet, and a modified ARP will be used by
the bridges to "fool" the BBN gateway into acquiring the routes.
未来: また、ルーティング情報を取得するために、BBNからの広帯域のネットのゲートウェイはネットの18、MITルーティングサーバにあるでしょう。 だましてください--BBN-Gwがイーサネットにあるでしょう、そして、変更されたARPは橋によって使用されます。「だまし」て、ルートを入手することへのBBNゲートウェイ。
Subnet Routing - inspired by PUP and CHAOS
Neighbor Bridge
Net I/F
Bridge address
Latest seq number
Aging value
Route to subnet
Distance
サブネットルート設定--PUPとCHAOS Neighbor BridgeネットI/F BridgeアドレスLatest seq番号Aging値のRouteによってサブネットDistanceに奮い立たせられます。
Packets
Request
I'm up
パケットは、私が起きているよう要求します。
Route update
Distance vector (256 bytes)
0 - Direct
1 -127 - hop count
128-255 - "Interface used for next hop" to subnet
and hop count
255 - Unreachable
ルートアップデートDistanceベクトル(256バイト)0(ダイレクト1 -127)ホップカウント128-255(サブネットとホップカウント255へ「次にに使用されるインタフェースは跳ぶ」)手が届きません。
Problem -
Many neighbors --> too much time and traffic needed for
processing.
問題--多くの隣人--あまりに多くの時間と交通が処理に必要とした>。
3 level addressing and routing strategy
Ext Gw:
Routing server
Default Gw
Subnet routing
Small but rich subnet routing updates.
3 アドレシングとルーティング戦略Ext Gwを平らにしてください: サーバDefault Gw SubnetルーティングSmallにもかかわらず、豊かなサブネットルーティングアップデートを発送します。
The Butterfly Gateway -- BBN - Hinden
Butterflyゲートウェイ--BBN--Hinden
Postel: A description of the butterfly hardware and a discussion
of the plans for the new gateway software to be implemented on it.
The butterfly machine is a multiprocessor (MC68000's)
interconnected with a funny switch. The new software will
incorporate the so called "Shortest Path First" or SPF routing
algorithm.
ポステル: 蝶のハードウェアの記述と新しいゲートウェイソフトウェアがそれで実行される計画の議論。 蝶のマシンは(MC68000のもの)がおかしいスイッチでインタコネクトしたマルチプロセッサです。 新しいソフトウェアはいわゆる「最短パス1番目」かSPFルーティング・アルゴリズムを取り入れるでしょう。
Hinden, Postel, Muuss, & Reynolds [Page 4]
Hinden、ポステル、Muuss、およびレイノルズ[4ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
Muuss:
Muuss:
Replacement for existing 30 PDP-11 "core" gateways.
Problems to be solved.
既存の30PDP-11「コア」門との交換。 解決するべき問題。
o Replace GGP
- Routing updates filling up
- Neighbor probes (N**2)
- Few buffers
o GGPを取り替えてください--ルート設定は満たします--隣人徹底的調査(N**2)--わずかなバッファしかアップデートしません。
o Present GGP updates only hold 70 net numbers, repacking
data will increase that to approximately 100 nets, but
this is just short term.
o 現在のGGPアップデートは70のネットの番号しか保持しませんが、再梱包データはそれをおよそ100のネットまで増加させるでしょうが、これはただ短期間です。
Features of Butterfly -
o 1000's of nets
o Partitioned nets
o Type of service routing, access control
o Flow control
o Large and small gateway configurations
Butterflyの特徴--○ Partitionedがサービスルーティングのo Type、アクセス管理o Flow制御装置o Large、および小さいゲートウェイ構成を網で覆う1000のネットoのもの
New functions -
o Routing
o Neighbor discovery
o Reduce neighbor pinging
o Access/departure model
o Connect gateways with point-to-point lines
新しい機能--二地点間線があるoルート設定o Neighbor発見o Reduce隣人ノッキングo Access/出発モデルo Connectゲートウェイ
Routing -
o SPF - shortest path first
o Gateway based routing (opposed to network routing)
o Routing updates
Gw ID
<nets directly connected>
<neighbor, distance>
o Updates flooded to other gateways
ルート設定--o SPF--Gw ID<が網で覆う最短パス最初oのゲートウェイのベースのルーティング(ネットワークルーティングに反対される)oルート設定アップデートは直接><隣人に接しました、と距離>o Updatesが他のゲートウェイへあふれさせました。
Next-door - Neighbors
o Neighbor gateways closest to gateway
o Ping next-door-neighbors only
o For up/down acquisition, partition into rings. Reduces
pinging.
隣、--ゲートウェイo Ping隣の人oだけForの最も近くで/下に獲得、リングへのパーティションにo Neighborゲートウェイを近所付き合いさせます。 ノッキングを減少させます。
Access/departure model
アクセス/出発モデル
First Gw (entrance) picks exit gateway
まず最初に、Gw(入り口)は出口ゲートウェイを選びます。
Hinden, Postel, Muuss, & Reynolds [Page 5]
Hinden、ポステル、Muuss、およびレイノルズ[5ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
First Gw adds Gw - Gw header
まず最初に、GwはGwを加えます--、Gwヘッダー
Butterfly gateway
Butterflyゲートウェイ
Processor nodes and switch nodes
プロセッサノードとスイッチノード
4-legged switch nodes, decision is simply UP or DOWN. 2
inputs
and 2 outputs.
4脚をしたスイッチノード、決定は、単にUPかDOWNです。 2つの入力と2回の出力。
Processor: MC 68000
Memory management Unit
Processor node controller - 2901 bit slice
PVC is the memory controller.
プロセッサ: Memory管理Unit ProcessorノードコントローラM.C.68000--2901年のビットスライスPVCはメモリ制御器です。
Butterfly -
32 M bps/path
Bandwith: approximately N - speed
Size: approximately N/2 log N 2
Butterfly--32Mのビーピーエス/経路Bandwith: およそN--Sizeを促進してください: およそ分のN2はN2を登録します。
Butterfly will support multibus interface; 1822, HDLC,
Ethernet, Ring
Butterflyはマルチバスインタフェースを支持するでしょう。 1822(HDLC、イーサネット)は鳴ります。
Terminal and load device will be a personal computer
端末と負荷装置はパーソナルコンピュータになるでしょう。
Small Gw for ARPA is approximately $20K
ARPAのための小さいGwはおよそ20ドルのKです。
New Gw processor structure
新しいGwプロセッサ構造
Buffer Management
o Scatter/gather buffers minimum size and extensions
o Buffer pool on processors with I/O
o Primary and secondary collections per device
==> guaranteed minimum service per device
(implemented w/counts)
Scatter/が集めるバッファManagement oはBufferがプロセッサの上で装置=>最低保証額サービスあたりの入出力o Primaryと二次収集で装置単位でプールする最小規模と拡大oをバッファリングします。(カウントで、実行されます)
The EGP C Gateway -- ISI - Kirton
EGP Cゲートウェイ--ISI--カートン
Postel: A user process was installed in Berkeley 4.2 Unix to do
EGP protocol functions leaving the normal router kernel function
in charge of forwarding datagrams. The EGP user process may do
system calls to update the kernel routing data. Based on the work
of Liza Martin.
ポステル: ユーザ・プロセスは、データグラムを進めることを担当して正常なルータ核の機能を残して、EGPにプロトコル機能をするためにバークレー4.2Unixにインストールされました。EGPユーザ・プロセスは、カーネルルーティングデータをアップデートするためにシステムコールをするかもしれません。 ライザ・マーチンの仕事に基づいて。
Hinden, Postel, Muuss, & Reynolds [Page 6]
Hinden、ポステル、Muuss、およびレイノルズ[6ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
Muuss:
Muuss:
EGP under 4.2
EGP4.2
Elimination of nonrouting gateways
非発送ゲートウェイの除去
Design -
Forwarding done in kernel
Kernel does not send redirects
EGP user process for route updates
Written in C
EGP based on Liza Martin's code
デザイン--Kernelが送らないカーネルで行われた推進はC EGPのWrittenがライザ・マーチンのコードに基礎づけたルートアップデートのためのEGPユーザ・プロセスを向け直します。
Routing Tables
o Kernel
o EGP Process
ルート設定Tables o Kernel o EGP Process
EGP Process Table -
o External updates
o Internal information
EGP Process Table--o Externalはo Internal情報をアップデートします。
Facilities -
施設、-
Configuration file-
o Trusted neighbors
o Internal non - routing gateways
構成ファイルo Trusted隣人○Internal、非、--、ルーティングゲートウェイ
Acquisition -
o Predetermined number of core gateways are EGP'd to
o Only accept from trusted neighbors
o Cannot acquire neighbors indirectly, for now
o Predetermined番号のコアゲートウェイによるEGPが信じられるのからo Onlyに受け入れるだろうということです。獲得--、隣人o Cannotが間接的に隣人を取得する、当分。
Unix Interfaces -
Reuse IP socket (problem with protocol number)
Listening to ICMP for redirects
System calls for -
o Route updates
o I/F config reading
o I/F status check
unix Interfaces--ICMPのIPソケット(プロトコル番号に関する問題)聴取を再利用してください、o Routeアップデートo I/Fコンフィグがo I/F状態チェックを読んで、System呼び出しを向け直します。
Performance -
o 60 ms/packet pair (CPU time)
o Typically 1% of CPU for 1 minute polling
パフォーマンス--o60ms/パケットは1分間の世論調査のために(CPU時間)○Typically1%のCPUを対にします。
Protocol function going
Routing updates being implemented
ルート設定がアップデートする実行されるプロトコル機能の行くこと
Should be all going in April.
すべて入っている4月であるべきです。
Hinden, Postel, Muuss, & Reynolds [Page 7]
Hinden、ポステル、Muuss、およびレイノルズ[7ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
The BRL Gateway -- BRL - Natalie
BRLゲートウェイ--BRL--ナタリー
Postel: This was a description of the BRL dumb gateway. More
interesting was the description of the BRL complex and the
inteconnections between machines. The gateway is written in C
(and derived from the MIT C-Gateway) and based on a simple
multiprocess operating system called LOS.
ポステル: これはBRLの馬鹿なゲートウェイの記述でした。 よりおもしろいのは、BRL複合体とマシンの間のinteconnectionsの記述でした。 ゲートウェイはC(そして、MIT C-ゲートウェイから、派生する)に書いて、a簡単に基づいてLOSと呼ばれるオペレーティングシステムを多重処理することです。
Muuss:
Muuss:
BRL history
BRL歴史
LOS design
Message passing
Memory Management
No copying of data, buffer size
データ、バッファサイズのコピーでないのをMemory Managementに通過するLOSデザインMessage
The CMU Gateway -- CMU - Accetta
米カーネギーメロン大学ゲートウェイ--米カーネギーメロン大学--Accetta
Postel: This was a description of the CMU dumb gateway.
ポステル: これは米カーネギーメロン大学の馬鹿なゲートウェイの記述でした。
Muuss:
Muuss:
History -
o "Logical-Host" multiplexor (March 81)
o Gateway (Oct 82) remote debugger and monitor
o Router (Oct 83)
- Modular device and protocol support
- Stub IP dynamic routing
- Local inter-network cable routing.
o Written in "C"
「C」の歴史--o「論理的なホスト」マルチプレクサー(3月81日)oゲートウェイ(10月82日)のリモートデバッガとモニターo Router(10月83日)--モジュールの装置とプロトコルサポート--スタッブIPダイナミックルーティング--ローカルのインターネットワークケーブルルーティングo Written
Uses low memory for buffers (maximum 32K)!
(autoboot of 3M bps Ethernet)
Auto-configuration of devices
Individual stack contents
Round-robin scheduler
Dynamic memory allocation
バッファ(最大の32K)に少ない記憶を使用します! (3Mのビーピーエスイーサネットのautoboot) 装置IndividualスタックコンテンツRound-コマドリスケジューラDynamicメモリアロケーションの自動構成
Device driver
Network interfaces
Auxiliary support devices
デバイスドライバNetworkはAuxiliaryサポート装置を連結します。
Does IP, ICMP, UDP
IP、ICMP、UDPをします。
Splicing through of PUP and CHAOS on chaos net, uses ARP.
カオスネット、用途ARPの上のPUPとCHAOSで突き抜けた状態で、継ぎます。
Configuration testing protocol (as in Ethernet Spec).
構成テストプロトコル(イーサネットSpecのように)。
Hinden, Postel, Muuss, & Reynolds [Page 8]
Hinden、ポステル、Muuss、およびレイノルズ[8ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
IP Processing-
IP処理
o Consistency checks
o Redirects does not forward misrouted packets
o Fragmentation - ICMP dest unreach If DF Set
o Access list for who can pass through
o 一貫性チェックo Redirectsはmisroutedパケットo Fragmentationを進めません--だれが通り抜けることができるように、ICMP dest unreach If DF Set o Accessは記載するか。
No GGP, no EGP, Uses known gateways
GGPがない、EGPがない、知られているUses、ゲートウェイ
Ordinary devices and PDP-10 and PDP-20
普通の装置、PDP-10、およびPDP-20
The Wisconsin BITNET/CSNET Gateway -- UWisc - Solomon
ウィスコンシンBitnet/CSNETゲートウェイ--UWisc--ソロモン
Postel: This was a discussion of a mail relay between the
Internet and BITNET to be installed at Wisconsin.
ポステル: これはウィスコンシンにインストールされるべきインターネットとBitnetの間のメール中継の議論でした。
Muuss:
Muuss:
WISC-IBM (192.5.2.24) will connect to BITNET
WISC-IBM、(192.5に、.24が)望んでいる.2はBitnetに接続します。
Mail gateway, BITNET uses RFC 822 headers!
ゲートウェイを郵送してください、そして、BitnetはRFC822ヘッダーを使用します!
LAN to X.25 Gateway -- Computer Gateways Inc. - Buhr
X.25ゲートウェイへのLAN--コンピュータゲートウェイ株式会社--Buhr
Postel: This was a description of a protocol translation device
between an X.25 world and the DATAPOINT ARCNET world.
ポステル: これはX.25世界とDATAPOINT ARCNET世界の間のプロトコル変換装置の記述でした。
Muuss:
Muuss:
ARCNET to X.25 Bridge
X.25橋へのARCNET
ARCNET - from Datapoint,
Baseband coax, 2.5 mbps
Token passing
Reserve/send/wait/ack protocol
RIM chip implements this
ARCNET--Datapointからおだてる、2.5mbps Tokenが/が/待ち/ackなプロトコルRIMチップ道具を送るReserveにこれを通過して、Basebandはおだてます。
"The OSI models seem less clear than the Internet models, perhaps
because they are less well developed."
「恐らく彼らがそれほどよくない開発されないので、OSIモデルはそれほどインターネットがモデル化されるよりはっきりとない見えません。」
Wraps the subnetwork in an enhanced subnetwork layer.
高められたサブネットワーク層の中でサブネットワークを包装します。
Every pair of subnetworks must be connected in this design - hence
a bridge not a gateway.
このデザインですべての組のサブネットワークを接続しなければなりません--したがって、ゲートウェイではなく、橋。
Bridge is a network layer RELAY.
橋はネットワーク層RELAYです。
ARCNET address is sent as X.25 data
X.25データとしてARCNETアドレスを送ります。
Hinden, Postel, Muuss, & Reynolds [Page 9]
Hinden、ポステル、Muuss、およびレイノルズ[9ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
RFC 898 April 1984 Gateway SIG Meeting Notes
ISI-UCI Gateway -- UCI - Rose
ISI-UCI Gateway -- UCI - Rose
Postel: This was a description of the UCI dumb gateway. This one
is made up of two hosts (VAX 750s) 50 miles apart. The VAXs are
connected via a 9.6 Kbs leased line. One is interfaced to the
ISI-NET (an Ethernet) and the other to UCIICS net (also an
Ethernet). The VAXs run Berkeley Unix 4.1. These VAXs run as
regular hosts too.
Postel: This was a description of the UCI dumb gateway. This one is made up of two hosts (VAX 750s) 50 miles apart. The VAXs are connected via a 9.6 Kbs leased line. One is interfaced to the ISI-NET (an Ethernet) and the other to UCIICS net (also an Ethernet). The VAXs run Berkeley Unix 4.1. These VAXs run as regular hosts too.
Muuss:
Muuss:
MTU is 512. Effective bandwidth of approximately 6000 baud over
9600 baud line.
MTU is 512. Effective bandwidth of approximately 6000 baud over 9600 baud line.
FACC Gateway -- FACC - Holkenbrink
FACC Gateway -- FACC - Holkenbrink
Postel: A description of a gateway designed by Ford. The gateway
is based on a MC68000 multiprocessor and a VME bus. An
interesting question that came up during this presentation was
"What is the least information a host (or gateway) must have when
it comes up, and how can it acquire the rest of what it needs to
go into full operation from the environment?"
Postel: A description of a gateway designed by Ford. The gateway is based on a MC68000 multiprocessor and a VME bus. An interesting question that came up during this presentation was "What is the least information a host (or gateway) must have when it comes up, and how can it acquire the rest of what it needs to go into full operation from the environment?"
Muuss:
Muuss:
Inter-segment Processor. M68000 CPU with various co-processors.
68000 IOPS, 1822, IOP Ethernet IOP. 1 cpu does IP, routing.
Multi-cpu version of MOS
Inter-segment Processor. M68000 CPU with various co-processors. 68000 IOPS, 1822, IOP Ethernet IOP. 1 cpu does IP, routing. Multi-cpu version of MOS
Lincoln IP/ST Gateway -- LL - Forgie/Kantrowitz
Lincoln IP/ST Gateway -- LL - Forgie/Kantrowitz
Postel: This was a discussion of the design of the Lincoln
gateways used primarily in the WBCNET for speech transmission
research. This gateway uses special I/O interfaces to promote a
high packet processing rate. The gateway implements both the
regular IP, and the ST protocol which permits resource
reservations to minimize the variation in transmission delay.
These gateways can, of course, act as regular internet gateways,
and have achieved very good performance in terms of datagrams per
second.
Postel: This was a discussion of the design of the Lincoln gateways used primarily in the WBCNET for speech transmission research. This gateway uses special I/O interfaces to promote a high packet processing rate. The gateway implements both the regular IP, and the ST protocol which permits resource reservations to minimize the variation in transmission delay. These gateways can, of course, act as regular internet gateways, and have achieved very good performance in terms of datagrams per second.
Muuss:
Muuss:
Packet voice experiments, wideband SATNET. Concentrate traffic
from local nets to trunk net. Needed enough performance to load
WBSATNET. 11/44 and ACC IF11 (Z-80). T1 trunk protocol converter.
(voice T1 <--> datagram)
Packet voice experiments, wideband SATNET. Concentrate traffic from local nets to trunk net. Needed enough performance to load WBSATNET. 11/44 and ACC IF11 (Z-80). T1 trunk protocol converter. (voice T1 <--> datagram)
Hinden, Postel, Muuss, & Reynolds [Page 10]
Hinden, Postel, Muuss, & Reynolds [Page 10]
RFC 898 April 1984 Gateway SIG Meeting Notes
RFC 898 April 1984 Gateway SIG Meeting Notes
IP problems -
o Congestion
o High packet header overhead
o No support for conference call
IP problems - o Congestion o High packet header overhead o No support for conference call
ST -
o Virtual circuit
o Know capacity in advance, schedule channel
o Abbreviated header
ST - o Virtual circuit o Know capacity in advance, schedule channel o Abbreviated header
11/44 - 900 to 1000 pkts/sec.
11/44 - 900 to 1000 pkts/sec.
Port processor:
Sync low speed: 600K bits/sec.
Packet processing: 500 pkts/sec. average
20-talker LPC voice loop, 28 data
bytes/pkt, 50% duty cycle
Data handling
4 pcm voice stream loop 64K bps
184 data bytes/pkt, 100% duty cycle
Port processor: Sync low speed: 600K bits/sec. Packet processing: 500 pkts/sec. average 20-talker LPC voice loop, 28 data bytes/pkt, 50% duty cycle Data handling 4 pcm voice stream loop 64K bps 184 data bytes/pkt, 100% duty cycle
Dispatcher Requirements
o Timely do ST
o Utilize rest of circuit for IP
o Performance measurement
Dispatcher Requirements o Timely do ST o Utilize rest of circuit for IP o Performance measurement
Reservations on the SATNET: Each host makes a reservation for
Nbytes of M messages every INTERVAL. Reservations are absolute.
Reservations on the SATNET: Each host makes a reservation for Nbytes of M messages every INTERVAL. Reservations are absolute.
ST and IP for each distant run = MPP multipurpose packets.
ST and IP for each distant run = MPP multipurpose packets.
12,000 lines of C code in 11/44 portion.
12,000 lines of C code in 11/44 portion.
Minimal Stub Gateways -- MITRE - Nabielsky
Minimal Stub Gateways -- MITRE - Nabielsky
Postel: This was a more abstract discussion of how stub gateways
could interact and acquire information about the topology of the
Internet.
Postel: This was a more abstract discussion of how stub gateways could interact and acquire information about the topology of the Internet.
Muuss:
Muuss:
Ethernet stub to Internet
Inexpensive, single-band ISBC 186/51 Intel @ $3000
High performance. EGP?
Ethernet stub to Internet Inexpensive, single-band ISBC 186/51 Intel @ $3000 High performance. EGP?
128K bytes/board
128K bytes/board
The Internet forest
The Internet forest
Hinden, Postel, Muuss, & Reynolds [Page 11]
Hinden, Postel, Muuss, & Reynolds [Page 11]
RFC 898 April 1984 Gateway SIG Meeting Notes
RFC 898 April 1984 Gateway SIG Meeting Notes
Alternative to ARP using Multicast
Alternative to ARP using Multicast
SPF routing -- BBN - Seamonson
SPF routing -- BBN - Seamonson
Postel: This was a fine presentation of the principles of the
"Shortest Path First" (SPF) routing procedures with some remarks
on how it is tailored to the Internet gateway situation. One
point that was impressed on me was that when using SPF in a set of
gateways (say, the core autonomous system) the procedure will do
routing to an "exit" gateway. Somehow I had not thought about it
in those terms before, but (obviously) just as there is a source
and a destination IMP in the ARPANET there will be an entrance and
an exit gateway in an SPF autonomous system.
Postel: This was a fine presentation of the principles of the "Shortest Path First" (SPF) routing procedures with some remarks on how it is tailored to the Internet gateway situation. One point that was impressed on me was that when using SPF in a set of gateways (say, the core autonomous system) the procedure will do routing to an "exit" gateway. Somehow I had not thought about it in those terms before, but (obviously) just as there is a source and a destination IMP in the ARPANET there will be an entrance and an exit gateway in an SPF autonomous system.
Muuss:
Muuss:
Features -
Metric, update procedures, path calculation, forwarding
Features - Metric, update procedures, path calculation, forwarding
Current GGP problems -
o Counting to infinity
o Not enough topology information in each Gw
o Updates potentially very large
Current GGP problems - o Counting to infinity o Not enough topology information in each Gw o Updates potentially very large
SPF in ARPANET
o Single path (not optimal) - no split of flow
o Delay based, to minimize delay
o Global knowledge of connection topology and delays
SPF in ARPANET o Single path (not optimal) - no split of flow o Delay based, to minimize delay o Global knowledge of connection topology and delays
Metric used -
o Delay, delay of each packet averaged
(queueing plus transmission plus propagation)
arrival-to-arrival time.
o Average delay on each trunk computed every 9.6 seconds.
Report large changes in delay, fast
Metric used - o Delay, delay of each packet averaged (queueing plus transmission plus propagation) arrival-to-arrival time. o Average delay on each trunk computed every 9.6 seconds. Report large changes in delay, fast
Update procedure -
o Updates report delay to each neighbor
o Update triggered by topology change, significant delay
change, or 1 time/minute.
Decay of threshold to direct to send update
o Sequence numbers
o Flooding on all trunks sent out on all lines
o Receipt of echo is acknowledgement
o Retransmission
o Aging of information
o Updates are 2*n*l packet growth. n = number imps,
l = number lines
Update procedure - o Updates report delay to each neighbor o Update triggered by topology change, significant delay change, or 1 time/minute. Decay of threshold to direct to send update o Sequence numbers o Flooding on all trunks sent out on all lines o Receipt of echo is acknowledgement o Retransmission o Aging of information o Updates are 2*n*l packet growth. n = number imps, l = number lines
Hinden, Postel, Muuss, & Reynolds [Page 12]
Hinden, Postel, Muuss, & Reynolds [Page 12]
RFC 898 April 1984 Gateway SIG Meeting Notes
RFC 898 April 1984 Gateway SIG Meeting Notes
- When lines goes up, rather than dumping routing
table,just waits one minute until all updates have
been heard.
- When lines goes up, rather than dumping routing table,just waits one minute until all updates have been heard.
Path calculation
o Dijkstras Algorithm
Path calculation o Dijkstras Algorithm
20
A _______________ F
/ \ \
3 / \10\15
/ \ \
B/___5___\D \E
\ / /
\ / /
1 \ / /5
\/ /
C /
20 A _______________ F / \ \ 3 / \10\15 / \ \ B/___5___\D \E \ / / \ / / 1 \ / /5 \/ / C /
1. A B(A, 3), D(A, 10), E(A, 15). F(A, 20)
1. A B(A, 3), D(A, 10), E(A, 15). F(A, 20)
2. A C(B, 4), D(B, 8), E(A, 15), F(A, 20)
|
B
2. A C(B, 4), D(B, 8), E(A, 15), F(A, 20) | B
4. A E(C, 9), F(A,20)
|
B
/ \
C D
4. A E(C, 9), F(A,20) | B / \ C D
5. A
|
B
|
C
/
E
5. A | B | C / E
Then tree is inverted into a "go here to get to this destination."
Then tree is inverted into a "go here to get to this destination."
For Internet -
For Internet -
Similar algorithm, needs special packet header to
indicate "exit" gateway to get to destination network.
Similar algorithm, needs special packet header to indicate "exit" gateway to get to destination network.
Update procedure -
Neighbor interface, neighbors, and delay to neighbor.
Update procedure - Neighbor interface, neighbors, and delay to neighbor.
Hinden, Postel, Muuss, & Reynolds [Page 13]
Hinden, Postel, Muuss, & Reynolds [Page 13]
RFC 898 April 1984 Gateway SIG Meeting Notes
RFC 898 April 1984 Gateway SIG Meeting Notes
"Next door neighbors" for minimizing traffic.
Ability to package multiple updates in one average
explicit Acks.
"Next door neighbors" for minimizing traffic. Ability to package multiple updates in one average explicit Acks.
Path calculation -
o Possible to build different trees based on type of
service.
Path calculation - o Possible to build different trees based on type of service.
Forwarding -
o Exit Gw
o Consistent databases are important.
Forwarding - o Exit Gw o Consistent databases are important.
Multiple Constraint Routing -- SRI - Shacham
Multiple Constraint Routing -- SRI - Shacham
Postel: This was a clear presentation of some of the consequences
of the idea of type of service routing. The level of complexity
of the routing procedure is determined to depend on how many
catagories of service there are and how many selections there are
in each catagory. A few examples were discussed including the
current type of service parameters of IP.
Postel: This was a clear presentation of some of the consequences of the idea of type of service routing. The level of complexity of the routing procedure is determined to depend on how many catagories of service there are and how many selections there are in each catagory. A few examples were discussed including the current type of service parameters of IP.
Muuss:
Muuss:
Both current and proposed ARPANET algorithms provide "best" path
under single constraint (number of hops, delay).
Internet will have diverse characteristics, it would be nice to
consider more than one constraint.
Both current and proposed ARPANET algorithms provide "best" path under single constraint (number of hops, delay). Internet will have diverse characteristics, it would be nice to consider more than one constraint.
o Determine a set of measures.
o Represent each measure as a single number.
o Determine range of values. (complexity 0(c**n) range of n)
o Define path measure as a function of measure of length.
sum (delay, cost)
min/capacity, length, security)
o Determine a set of measures. o Represent each measure as a single number. o Determine range of values. (complexity 0(c**n) range of n) o Define path measure as a function of measure of length. sum (delay, cost) min/capacity, length, security)
If just one cost is used, then SPF (or whatever) can be used for
each cost. However, under multiple constraints there is a more
difficult problem. e.g.: minimum delay with packet size of at
least 1000 bytes.
If just one cost is used, then SPF (or whatever) can be used for each cost. However, under multiple constraints there is a more difficult problem. e.g.: minimum delay with packet size of at least 1000 bytes.
RUMC has been shown to be in the NP complete family.
RUMC has been shown to be in the NP complete family.
RUMC needs bigger tables, more processing and routing overhead.
Its not awful for 2-choice TOS, like in IP.
RUMC needs bigger tables, more processing and routing overhead. Its not awful for 2-choice TOS, like in IP.
Table size is random, we have to be prepared for the worst case.
Table size is random, we have to be prepared for the worst case.
Possible strategies: flood a "search packet," dropped when
Possible strategies: flood a "search packet," dropped when
Hinden, Postel, Muuss, & Reynolds [Page 14]
Hinden, Postel, Muuss, & Reynolds [Page 14]
RFC 898 April 1984 Gateway SIG Meeting Notes
RFC 898 April 1984 Gateway SIG Meeting Notes
constraints are not met, see if it makes it though. Good only for
virtual circuit. Weighted sum (VC only) works only with some
probability.
constraints are not met, see if it makes it though. Good only for virtual circuit. Weighted sum (VC only) works only with some probability.
TOS is needed for Internet, but the algorithms are costly.
Complexity for providing TOS IP style is not too high.
TOS is needed for Internet, but the algorithms are costly. Complexity for providing TOS IP style is not too high.
FACC Multinet Gateway Routing -- FACC - Cook
FACC Multinet Gateway Routing -- FACC - Cook
Postel: This approach considered hop count to be an inadequate
metric for routing decsions in a system of different types of
networks (e.g., Ethernets, ARPANETs, 2.4Kb lines). Delay was
selected as the metric to use. There are some interesting issues
in the measurement of delay for some types of networks. Also, the
design considers the use of multiple paths when they are avaiable,
and routing to provide connectivty between the parts of
partitioned networks.
Postel: This approach considered hop count to be an inadequate metric for routing decsions in a system of different types of networks (e.g., Ethernets, ARPANETs, 2.4Kb lines). Delay was selected as the metric to use. There are some interesting issues in the measurement of delay for some types of networks. Also, the design considers the use of multiple paths when they are avaiable, and routing to provide connectivty between the parts of partitioned networks.
Muuss:
Muuss:
Routing with a single constraint.
A network of gateways Access, Transport, or Dual networks.
Some networks are used as backbones between gateways only.
Routing with a single constraint. A network of gateways Access, Transport, or Dual networks. Some networks are used as backbones between gateways only.
Routing updates
Variable length
Broadcast routing updates
Routing updates Variable length Broadcast routing updates
Unitary ends - A - Gw - B - Rest
Routing for A is really just routing to B
Neighbor Gws, nets
Lots and lots of tables
Unitary ends - A - Gw - B - Rest Routing for A is really just routing to B Neighbor Gws, nets Lots and lots of tables
Metanet Gateway -- SRI - Denny
Metanet Gateway -- SRI - Denny
Postel: This is a project to invent several new addressing
features for gateways. In particular, there is a scheme to use an
option much like the source route option to do multi-addressing of
IP datagrams. It seems as if the gateways that implement this
option will have to know which other gateways do and don't
implement it. Also, there was discussion of a gateway to a
network that is in radio silence, and how to keep TCP connections
going with hosts that can't talk. This project is also concerned
about network reconstitution, security, survivability, congestion
control, and supporting multimedia data (voice, bitmaps, etc.) in
applications. A gateway is being developed in ADA for a MC68000
machine (SUN), and the initial version of the gateway is to be up
in May 84.
Postel: This is a project to invent several new addressing features for gateways. In particular, there is a scheme to use an option much like the source route option to do multi-addressing of IP datagrams. It seems as if the gateways that implement this option will have to know which other gateways do and don't implement it. Also, there was discussion of a gateway to a network that is in radio silence, and how to keep TCP connections going with hosts that can't talk. This project is also concerned about network reconstitution, security, survivability, congestion control, and supporting multimedia data (voice, bitmaps, etc.) in applications. A gateway is being developed in ADA for a MC68000 machine (SUN), and the initial version of the gateway is to be up in May 84.
Hinden, Postel, Muuss, & Reynolds [Page 15]
Hinden, Postel, Muuss, & Reynolds [Page 15]
RFC 898 April 1984 Gateway SIG Meeting Notes
RFC 898 April 1984 Gateway SIG Meeting Notes
Muuss:
Muuss:
Navy internet
Multimedia mail and conf.
Radio silence (EMCON)
Security and Survivability.
Navy internet Multimedia mail and conf. Radio silence (EMCON) Security and Survivability.
EMCON - Causes special problems for EGP and IGP one way nonTCP
mail delivery. No Acks. Uses name screen to redirect mail to
special one-way mail catcher, who then forwards using ordinary
methods.
EMCON - Causes special problems for EGP and IGP one way nonTCP mail delivery. No Acks. Uses name screen to redirect mail to special one-way mail catcher, who then forwards using ordinary methods.
Security and survivability
Access control - "capability" - 32/64 bit key which changes
frequently (every hour or so)
Security and survivability Access control - "capability" - 32/64 bit key which changes frequently (every hour or so)
Reconstitution - Partitioning, coalescing, mobile host
Test and monitoring - HMP
Reconstitution - Partitioning, coalescing, mobile host Test and monitoring - HMP
Gateway target - 68000 in ADA. Telesoft compiler
Gateway target - 68000 in ADA. Telesoft compiler
Address Mapping and Translation -- UCL - Crowcroft
Address Mapping and Translation -- UCL - Crowcroft
Postel: This was a discussion of some of the issues in
interconnecting networks of different types including the Internet
and networks in England such as the Universe network. The
Universe network is made up of Cambridge Rings at several sites
linked via a satellite channel.
Postel: This was a discussion of some of the issues in interconnecting networks of different types including the Internet and networks in England such as the Universe network. The Universe network is made up of Cambridge Rings at several sites linked via a satellite channel.
Muuss:
Muuss:
ARPA - SATNET - NULLNET - UCLNET UNIVERSE Satellite, 3 UCL rings
ARPA - SATNET - NULLNET - UCLNET UNIVERSE Satellite, 3 UCL rings
SAM -
o IP switch to several 1822 hosts
o IP/universe mapper, overlays UCLNET on universe
o Mask and match
128. 11. code. host
SAM - o IP switch to several 1822 hosts o IP/universe mapper, overlays UCLNET on universe o Mask and match 128. 11. code. host
Three types:
Three types:
1. Direct: code --> subnet
2. Redirect: 2nd lookup (for multihoming)
3. Logical: Logical address into a table of universe
names.
Name lookups give addresses and routes.
1. Direct: code --> subnet 2. Redirect: 2nd lookup (for multihoming) 3. Logical: Logical address into a table of universe names. Name lookups give addresses and routes.
IP tunnels through X.25
IP tunnels through X.25
Hinden, Postel, Muuss, & Reynolds [Page 16]
Hinden, Postel, Muuss, & Reynolds [Page 16]
RFC 898 April 1984 Gateway SIG Meeting Notes
RFC 898 April 1984 Gateway SIG Meeting Notes
BBN Van gateway PSS - IPSS -Telenet - for hosts that can't use
SATNET.
BBN Van gateway PSS - IPSS -Telenet - for hosts that can't use SATNET.
SAM does access control and multihoming. Clever Multihoming gives
host a second address and sends an ICMP/Redirect to force TCP
connection to go through a different route, but wind up at same
place!!!
SAM does access control and multihoming. Clever Multihoming gives host a second address and sends an ICMP/Redirect to force TCP connection to go through a different route, but wind up at same place!!!
Wrote EGP in ADA. It didn't help at all.
Wrote EGP in ADA. It didn't help at all.
Design of the FACC Multinet Gateway -- FACC - Cook
Design of the FACC Multinet Gateway -- FACC - Cook
Postel: This is a distributed multiprocessor machine using a
special bus network for the interprocessor communication. The
softaware is written in C. The gateways is in an early test
phase.
Postel: This is a distributed multiprocessor machine using a special bus network for the interprocessor communication. The softaware is written in C. The gateways is in an early test phase.
Muuss:
Muuss:
RADC program
RADC program
Started with AUTODIN II, switched to DDN.
Small to large switching devices.
DoD uses of PDNs, and partitioned network problems.
Started with AUTODIN II, switched to DDN. Small to large switching devices. DoD uses of PDNs, and partitioned network problems.
Distributed processing architecture -
Parallel contention, 90M bps bus, 22 wires. Each node has cpu,
memory, optimal comm line. Wire - OR presentation of address,
contention happens each time bus becomes free, all requestors
put out type of msg, pri, and address. Reads back wire - OR of
result, and highest gwy wins, sorted by (pri, type, higher
addr).
Bus was originally designed for our FAA fail-soft application
Z-800l w/MMU. Not binary addressing, but unitary (base1)
One element resolved per bus transaction.
Boards may be plugged in while running.
Inherent parallelism in layered protocols.
分散処理構造--主張、90Mのビーピーエスバス、22ワイヤに沿ってください。 各ノードには、cpu、メモリ、最適のcomm線があります。 ワイヤ--アドレスのORプレゼンテーション、バスが自由になって、すべての要請者がmsg、pri、およびアドレスのタイプを出すたびに主張は起こります。 読書はワイヤを支持します--結果、および(pri、タイプ、より高いaddr)によって分類された中で最も高いgwy勝利のOR。 バスは元々、私たちのFAAフェイルソフトアプリケーションのためにMMUと共にZ-800l設計されました。 2進のアドレシングではなく、バス取引単位で分解された単一(base1)の1つの要素。 板は走っている間、プラグを差し込まれるかもしれません。 層にされたプロトコルの固有の平行関係。
Interface connector clues board to modem levels and date rate. Up
to 100K bps now, soon up to T1 rate.
インタフェースコネクタ手がかりはモデムレベルと日付のレートに入ります。 T1に、現在の100Kのビーピーエスまで、評価してください。
Multiprocessor approach allows routing calculation to take place
out-of-band from the measurement of delay and traffic, and allows
use of more compute power for routing.
アプローチがバンドの外で遅れと交通の測定から行われるのをルーティング計算を許容して、以上の使用を許すマルチプロセッサはルーティングのためにパワーを計算します。
Mostly written in C, with some assembler. Multiprocessor
operating system, designed from scratch.
何らかのアセンブラでCにほとんど書かれています。 最初から設計されたマルチプロセッサオペレーティングシステム。
Hinden, Postel, Muuss, & Reynolds [Page 17]
Hinden、ポステル、Muuss、およびレイノルズ[17ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
SAC Gateway -- SRI - Su/Lewis
嚢のゲートウェイ--様--Su/ルイス
Postel: This was a presentation of the design for the gateways to
be used in the advanced SAC demo experiments on network
partitioning and reconstitution, and communication between
intermingiling mobile networks. Much of these demonstrations will
be done with packet radio units and networks. Some of the ideas
are to use a gateway-centered type of addressing and double
encapsulation (i.e., an extra IP header) to route datagrams.
ポステル: これはゲートウェイがネットワーク仕切りと再構成の高度なSACデモ実験、およびモバイルネットワークをintermingilingするところのコミュニケーションで使用されるデザインのプレゼンテーションでした。 パケットラジオユニットとネットワークと共にこれらのデモンストレーションの多くのことをするでしょう。 考えのいくつかはデータグラムを発送するのに、ゲートウェイ中心のタイプのアドレシングと二重カプセル化(すなわち、余分なIPヘッダー)を使用することです。
Muuss:
Muuss:
Network dynamics due to component mobility or failure.
Mobile host, reconstitution, partitioning.
H/W: 11/23
S/W: Some "C" gateway
OS: VMOS (SRI)
コンポーネントの移動性か失敗のため力学をネットワークでつないでください。 モバイルホスト、再構成、仕切り。 H/W: 11/23秒間/W: 何らかの「C」ゲートウェイOS: VMOS(様)
Gateway-centered addressing, rather than network.
Gw host instead of net.host.
Double encapsulation: additional IP header.
TCP uses addr as an ID, IP uses it as an ADDRESS (-> route)
Need to separate these dual uses of this address field.
Incremental Routing (next-hop indication)
ネットワークよりむしろゲートウェイ中心のアドレシング。 net.hostの代わりにGwホスト。 カプセル化を倍にしてください: 追加IPヘッダー。 TCPはIDとしてaddrを使用して、ADDRESS(->ルート)が、このアドレス・フィールドのこれらの二元的な用途を切り離す必要があるとき、IPはそれを使用します。 増加のルート設定(次のホップ指示)
EGP -- Linkabit - Mills
EGP--Linkabit--工場
Postel: A presentation of the EGP design. EGP has three major
aspects, neighbor acquisition, neighbor reachability, and network
reachability. The autonomous system concept was discussed.
ポステル: EGPデザインのプレゼンテーション。 EGPには、3つの主要な局面、隣人獲得、隣人の可到達性、およびネットワークの可到達性があります。 自律システム概念について議論しました。
Muuss:
Muuss:
Background, Implementation, Experience, Disparaging Remarks
バックグラウンド、実現、所見をこきおろすという経験
Design goals -
o Established demarcations
o Decouple implementations
o Confine routing loops
o Exchange reachability information
o Provide flow control for connectivity information
o Medium-term lifetime
デザイン目標--o Established画定o Decouple実現o Confineルーティングは接続性情報o Medium-用語生涯のためのo Exchange可到達性情報o Provideフロー制御を輪にします。
Non goals Not trying to do these!
o Flexibility of topology
o Rapid response Very slow update
トポロジーo Rapid応答Veryのo Flexibilityが遅くするこれらをしようとする非目標Not、アップデート
Hinden, Postel, Muuss, & Reynolds [Page 18]
Hinden、ポステル、Muuss、およびレイノルズ[18ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
o Adaptive routing
o Common routing metric No agreement at all
o Load sharing or splitting
o すべてのo Load共有のときにメートル法のいいえ協定を発送する最適経路指定o Commonか分かれること
"Good news travels fast and bad news travels forever."
Not for routing, but only provides reachability
「朗報が速く移動して、悪いニュースは、いつまでもルーティングのために. 」 Notを旅行しますが、可到達性を提供するだけです。
RFC827 initial mode, RFC888 stub protocol
RFC827の初期のモード、RFC888スタッブプロトコル
Neighbor acquisition protocol
o 2-way shake
o Flow - rates
o Explicit acquisition/cause
隣人獲得はo2ウェイ震動o Flowについて議定書の中で述べます--oがExplicit獲得/原因であると評定します。
Neighbor reachability protocol
o Periodic polling
o Parasitic information
o Reachability algorithm Network reachability
protocol
o Periodic pulling
o Remote information
o Direct and indirect neighbors
o Indirect internal and indirect external
neighbors
o Distance information
o Remote情報o Directを引く隣人可到達性プロトコルo Periodic世論調査o Parasitic情報o ReachabilityアルゴリズムNetwork可到達性プロトコルo Periodicと間接的な隣人○Indirect内部的、そして、間接的な外部の隣人o Distance情報
EGP neighbors do not need to peer with more than one
CORE gateway, but you may peer with anybody you wish.
EGP隣人は1CORE門以上でじっと見る必要はありませんが、あなたは願っている人はだれと共にもじっと見ることができます。
Shortcomings -
o Slow reaction due polling
o Tree-structured routing constraint
- Rigid topology
- Administrative resistance to odering
- Lack of adaptive connectivity
o Neighbor acquisition incomplete.
短所--o Slow反応支払われるべきもの世論調査oは不完全な状態で規制--堅いトポロジーを発送します--oderingへの管理抵抗--適応型の接続性o Neighbor獲得の不足をTree構造化しました。
Loops between autonomous systems will last a long
time, and are a real no-no.
自律システムの間の輪は、長く持って、本当のやってはいけないことです。
System models -
o "Appropriate first hop" criterion
- Not useful for implementation
- Requires global information
- Inadequate for verification
o Graph models
- N-graph shows net connectivity
- T-graph shows system connectivity
システムモデル--o「適切な最初のホップ」評価基準(実現の役に立たない)はN-グラフがネットの接続性を示している検証o Graphモデルに不十分なグローバルな情報を必要とします--T-グラフはシステムの接続性を示しています。
Hinden, Postel, Muuss, & Reynolds [Page 19]
Hinden、ポステル、Muuss、およびレイノルズ[19ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
- T-acycloc criterion insures loop-free
o Derived features
- Induces spanning tree
- T-acycloc評価基準は無輪のo Derivedの特徴を保障します--スパニングツリーを引き起こします。
N-graph
N-グラフ
G1
A_______________B
/ \ /\
G2 / \ G3 G4 / \ G5
/ \ / \
C------D E-----F G6
G1A_______________B/\/\G2/\G3 G4/\5ヵ国蔵相会議/\/\C------D E-----F G6
AS1 = G2, G3, G6 A B
AS2 = G1
AS3 = G4, G5 AS1 ----- AS2 ----- AS3
AS1がG2、G3と等しく、G6がB AS2=G1 AS3=G4であり、5ヵ国蔵相会議はAS1です。----- AS2----- AS3
T-graph
T-グラフ
Test: to ensure that there are no cycles
テスト: サイクルが全くないのを確実にするために
Spanning subtree
下位木にかかっています。
Specification effort - Status report State machine designed
仕様の努力--州マシンが設計した現状報告
Remaining issues -
o Remove extra hop in core system
o Expand tables
o Test backdoor "GGP"
o Resolve specification issues
o Resolve full gateway configuration
- Back door connectivity guidance
- can only advertise 1 path at a time.
- APF rule guidancee
- Self organization issues
o Implement and distribute for operational systems.
残された問題--コア・システムo Expandテーブルo Testの裏口の"GGP"o決心仕様によるo Removeの余分なホップは完全なゲートウェイ構成(裏口接続性指導)が広告を出すことができるだけであるo決心に一度に1つの経路を発行します。 - そして、APFはguidanceeを統治します--自己組織がo Implementを発行する、基幹系システムのために、分配します。
Congestion Control -- FACC - Nagle
輻輳制御--FACC--ネーグル
Postel: This was a discussion of the situation leading to the
ideas presented in RFC 896, and how the policies described there
improved overall performance.
ポステル: これは状況がRFC896に提示された考えと、方針がそこでどう向上した総合的な性能について説明したかとつながる議論でした。
Hinden, Postel, Muuss, & Reynolds [Page 20]
Hinden、ポステル、Muuss、およびレイノルズ[20ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
Muuss:
Muuss:
First principle of congestion control:
輻輳制御の原則:
DON'T DROP PACKETS (unless absolutely necessary)
パケットを落とさないでください。(絶対に必要でない場合)
Second principle:
2番目の原則:
Hosts must behave themselves (or else)
ホストは行儀よくしなければなりません。(or else)
Enemies list -
政敵リスト、-
1. TOPS-20 TCP from DEC
2. VAX/UNIX 4.2 from Berkeley
1. 12月2日からの先端-20TCP。 バークレーからのバックス/UNIX4.2
Third principle:
3番目の原則:
Memory won't help (beyond a certain point).
メモリは助けないでしょう(一旦ある線を越えると)。
The small packet problem: Big packets are good, small are bad
(big = 576).
小型小包問題: 大きいパケットが良くて、小さい、悪いです(大きい=576)。
Suggested fix: Rule: When the user writes to TCP, initiate a send
only if there are NO outstanding packets on the connection. [good
for TELNET, at least] (or if you fill a segment). No change when
Acks come back. Assumption is that there is a pipe-like buffer
between the user and the TCP.
提案されたフィックス: 以下を統治してください。 ユーザがTCPに書くとき、接続にどんな傑出しているパケットもない場合にだけaが送る開始します。 [TELNETが少なくともいいぞ] (あなたがセグメントをいっぱいにするなら。) Acksが戻るときの変化がありません。 仮定はユーザとTCPの間には、パイプのようなバッファがあるということです。
The source quench problem Rule: When a TCP gets an ICMP Source
Quench, it must reduce the number of outstanding datagrams on
relevant TCP connections.
ソース焼き入れ問題Rule: TCPが関連TCP接続のときにICMP Source Quenchを手に入れるとき、それは傑出しているデータグラムの数を減少させなければなりません。
Rule: When a gateway nears overload, before starting to drop
packets, send a Source Quench.
以下を統治してください。 パケットを落とし始める前にゲートウェイがオーバーロードに近づくときには、Source Quenchを送ってください。
Node capacity: Each node ought to have one buffer for each TCP
connection, plus some for overload.
ノード容量: 各ノードは、それぞれのTCP接続のために1つのバッファを持っていて、オーバーロードのためにいくつかを持つべきです。
Both fixes really need to be done together, although the first one
is often helpful by itself. Side effect: FTPs start off "slowly,"
until the first Ack comes back Dave Mills thinks this will
increase the mean delay for medium-size interactions. This
probably will not work so well for SATNET.
最初のものはしばしばそれ自体で役立っていますが、両方のフィックスは、本当に一緒にする必要があります。 副作用: FTPは「ゆっくり」始められて、最初のAckが戻るまで、デーヴ・ミルズは、これが中型相互作用のために意地悪な遅れを増加させると考えます。 これはSATNETのためにたぶんあまりによく働かないでしょう。
Problems about propagation time of links biasing the validity of
this result!!
リンクの伝播およそ時間のこの結果の正当性に偏ることにおける問題!
Hinden, Postel, Muuss, & Reynolds [Page 21]
Hinden、ポステル、Muuss、およびレイノルズ[21ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
A Gateway Congestion Control Policy--NW Systems - Niznik
ゲートウェイ輻輳制御方針--NWシステム--Niznik
Postel: This talk was (for Postel) hard to follow. There were a
number of references to well known results in queuing theory etc,
but I could not follow how they were being used.
ポステル: この話はこと(ポステルのために)でした。続きにくいです。 待ち行列などにはよく知られている結果の多くの参照がありましたが、私は、それらがどう使用されていたかということになることができませんでした。
Muuss:
Muuss:
Replacements for IMP SPF
Topological observations
Nodal congestion control policy
GMD - control application [from German network]
RPN - relational Petri net
DCT - dynamic congestion table
NCCP performance evaluation
Planned GCCP: Gateway congestion control policy
IMP SPF Topological観測Nodal輻輳制御方針GMDのためのリプレイスメント--アプリケーション[ドイツのネットワークからの]RPN--関係ペトリネットDCT--ダイナミックな混雑テーブルNCCP業績評価Planned GCCPを制御してください: ゲートウェイ輻輳制御方針
Lots of diagrams and figures.
多くのダイヤグラムと図形。
Better throughput than SPF, but somewhat higher delay.
しかし、SPFより良い効率、いくらか高い遅れ。
Cubic structure of table.
テーブルの立方構造。
DISCUSSION (Postel's personal comments)
議論(ポステルの所感)
There was very little organized discussion during the meeting and
not really very much question and answer interaction during the
presentation. There was a lot of discussion during the breaks,
and at lunch time, and at the end of each day.
本当に非常に多くの質疑応答相互作用ではなく、プレゼンテーションのミーティングの間の議論が非常に少ししか計画されませんでした。 中断、昼食時、および毎日の終わりに、多くの議論がありました。
Some things that occured to me during the meeting that may have
been triggered by something someone said (or maybe by the view out
the window):
だれかが言った(または多分窓からの視点で)ことによって引き起こされたかもしれないミーティングの間に私にoccuredされたいくつかのもの:
Don't design a protocol where you expect to get a lot of
messages from a lot of sources at the same time. For example,
don't ask all the hosts on an Ethernet to send you an ack to a
broadcast packet.
あなたが同時に多くのソースから多くのメッセージを得ると予想するプロトコルを設計しないでください。 例えば、放送パケットへのackを送るようにイーサネットのすべてのホストに頼まないでください。
Has anyone worked out in detail the routing traffic costs for
the GGP vs the SPF procedures for the actual case of the
Internet?
だれかGGPのために詳細にインターネットの実際のケースのためのSPF手順に対してルーティング交通コストを解決しましたか?
How will the fact that thinking of the routing in the core
autonomous system is cast in terms of an entry and an exit
gateway effect other things? Will there be special
コア自律システムでルーティングを考えるのがエントリーで投げかけられるという事実と出口ゲートウェイはどのように他のものに作用するでしょうか? 特別番組があるでしょうか?
Hinden, Postel, Muuss, & Reynolds [Page 22]
Hinden、ポステル、Muuss、およびレイノルズ[22ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
arrangements between the entry and exit gateway? Will an
autonomous system become a circuit switch connecting pairs of
entry/exit gateways?
エントリーと出口ゲートウェイの間のアレンジメント? 自律システムは組のエントリー/出口ゲートウェイを接続する回線交換機になるでしょうか?
Is TOS routing worth the cost?
TOSルーティングは費用の価値がありますか?
Should we allow (as a new type of ICMP message) redirects to
Gateways?
私たちが許すべきである、(ICMPの新しいタイプが通信するように) Gatewaysに向け直しますか?
Does making memory larger ever hurt? If a gateway's memory is
full of inappropriately retransmitted TCP segments would it be
better if there were less memory?
メモリをより大きくするのは痛みますか? ゲートウェイのメモリが不適当に再送されたTCPセグメントでいっぱいであるなら、より少ないメモリがあれば、より良いでしょうか?
Is there something reasonable to do with source quench at the
TCP? Re: RFC-896.
ソース焼き入れをTCPに処理するために、何か妥当なものはありますか? Re: RFC-896。
If there are links (or networks) of vastly differing delay and
thruput characteristics what impact would an IP level load
splitting (say by gateways) have on TCP connections (some of
the segments of the connection go one path and others go a
different path)?
広大に異なった遅れとスループットの特性のリンク(または、ネットワーク)があればTCP接続のときに、IPの平らな負荷の分かれること(ゲートウェイのそばで言う)ではどんな影響力があるだろうか、(いくつか、接続のセグメントでは、順調な1つの経路と他のものが行く、異なった経路)、--
Are any problems avoided (either way) by using double IP
headers vs a "source route like" IP option to separate the IP
level addressing and routing function from the TCP level
end-point naming function of the IP addresses.
IPの平らなアドレシングを切り離すのに(いずれにせよ)「送信元経路同様」のIPオプションに対して二重IPヘッダーを使用することによって避けられたどんな問題でありも、IPアドレスのTCPの平らなエンドポイント命名機能から機能を発送していること。
What bad things could happen from the proposed IP
multidestination routing option?
どんな悪いことが提案されたIP「マルチ-目的地」ルーティングオプションから起こることができますか?
Hinden, Postel, Muuss, & Reynolds [Page 23]
Hinden、ポステル、Muuss、およびレイノルズ[23ページ]
RFC 898 April 1984 Gateway SIG Meeting Notes
注意を満たすRFC898 1984年4月のゲートウェイSIG
MEETING ATTENDEES
ミーティング出席者
Mike Accetta - CMU R. Buhr - Canada J. Noel Chiappa - MIT Paul Cook - Ford Jon Crowcroft - UCL Barbara Denny - SRI Jim Forgie - LL Steve Groff - BBN Phill Gross - Linkabit Kjell Hermansen - NTA Robert Hinden - BBN Patrick Holkenbrink - FACC Ruth Hough - AIRINC Willie Kantrowitz - LL Paul Kirton -ISI Mark Lewis -SRI Liza Martin - MIT Doug Miller - MITRE Dave Mills - Linkabit Mike Muuss - BRL Jose Nabielsky - MITRE Ron Natalie - BRL John Nagle - Ford Carol Niznick NW Systems Jon Postel - ISI Joyce Reynolds -ISI Marshall Rose - UCI Joe Sciortino - AIRINC Linda Seamonson - BBN Nachum Shacham - SRI Alan Sheltzer - UCLA Marvin Solomon - WISC Zaw-Sing Su - SRI Mitch Tasman - BBN
マイクAccetta--米カーネギーメロン大学R.Buhr--カナダJ; クリスマスChiappa--MITのポール・クック--フォード・ジョン・クロウクロフト--UCLバーバラ・デニー--様のジムForgie--LLスティーブ・グルフ--BBNフィルGross--LinkabitチェルHermansen--NTAロバートHinden--BBNパトリックHolkenbrink--FACCルース・ハフ--AIRINCウィリー・カントロウィッツ--LLポールカートン-ISIマーク・ルイスSRIライザ・マーチン--MITのダグ・ミラー--MITREデーヴ; 工場--LinkabitマイクMuuss--BRLホセNabielsky--斜め継ぎロンナタリー--BRLジョン・ネーグル--フォードキャロルNiznick NWシステムジョン・ポステル(ISIジョイス・レイノルズ・-ISIマーシャル・ローズ)UCIジョーSciortino--AIRINCリンダSeamonson--BBNナッハムShacham--様のアランSheltzer(UCLAマーヴィン・ソロモン)はSu--様のミッチ・タスマン--BBNをWISC Zaw歌います。
Hinden, Postel, Muuss, & Reynolds [Page 24]
Hinden、ポステル、Muuss、およびレイノルズ[24ページ]
一覧
スポンサーリンク
