RFC911 日本語訳

0911 EGP Gateway under Berkeley UNIX 4.2. P. Kirton. August 1984. (Format: TXT=55908 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group
Request for Comments: 911

コメントを求めるワーキンググループ要求をネットワークでつないでください: 911

                      EGP GATEWAY UNDER BERKELEY UNIX 4.2

バークレーUNIX4.2の下におけるEGPゲートウェイ

                                  PAUL KIRTON

ポール・カートン

       University of Southern California, Information Sciences Institute
     Visiting Research Fellow from Telecom Australia Research Laboratories

南カリフォルニア大学、オーストラリア電信電話公社研究所から大学の研究員を訪問する科学が設ける情報

                                22 August 1984

1984年8月22日

                                   ABSTRACT

要約

This  report  describes an implementation of the Exterior Gateway Protocol that
runs under the Unix 4.2 BSD operating system.  Some  issues  related  to  local
network configurations are also discussed.

このレポートはUnix4.2BSDオペレーティングシステムで実行されるExteriorゲートウェイプロトコルの実装について説明します。 また、企業内情報通信網構成に関連するいくつかの問題について議論します。

Status of this Memo:

このMemoの状態:

This  memo describes  an implementation of the Exterior Gateway Protocol  (EGP)
(in that sense it is a status report).  The memo also discusses  some  possible
extentions  and  some  design  issues   (in that sense it is an invitation  for
further discussion).  Distribution of this memo is unlimited.

このメモはExteriorゲートウェイプロトコル(EGP)の実装について説明します(その意味で、それは現状報告です)。 また、メモはいくつかの可能なextentionsといくつかのデザイン問題について議論します(その意味で、それはさらなる議論のための招待状です)。 このメモの分配は無制限です。

    Funding for this research was provided by DARPA and Telecom Australia.

RFC 911                                                                       i

この調査のための基金はDARPAとオーストラリア電信電話公社によって提供されました。 RFC911i

                               Table of Contents

目次

1. INTRODUCTION                                                               1

1. 序論1

1.1 Motivation for Development                                                1
1.2 Overview of EGP                                                           2

1.1 EGP2の開発1 1.2概要に関する動機

2. GATEWAY DESIGN                                                             4

2. ゲートウェイデザイン4

2.1 Routing Tables                                                            4
     2.1.1 Incoming Updates                                                   5
     2.1.2 Outgoing Updates                                                   5
2.2 Neighbor Acquisition                                                      6
2.3 Hello and Poll Intervals                                                  6
2.4 Neighbor Cease                                                            7
2.5 Neighbor Reachability                                                     7
2.6 Sequence Numbers                                                          8
2.7 Treatment of Excess Commands                                              8
2.8 Inappropriate Messages                                                    8
2.9 Default Gateway                                                           9

2.1個の経路指定テーブル4 2.1.1の入って来るアップデート5 2.1.2の外向的なアップデート5 2.2隣人獲得6 2.3、こんにちは、投票間隔6 2.4隣人が7 2.5隣人の可到達性7 2.6の一連番号をやめる、8、2.7処理、余分なコマンド8 2.8の不適当なメッセージ8 2.9デフォルトゲートウェイ9

3. TESTING                                                                   10

3. テスト10

4. FUTURE ENHANCEMENTS                                                       11

4. 今後の増進11

4.1 Multiple Autonomous Systems                                              11
4.2 Interface Monitoring                                                     11
4.3 Network Level Status Information                                         11
4.4 Interior Gateway Protocol Interface                                      12

4.1 11 4.2インタフェースモニターしている11 4.3がネットワークでつなぐ複数の自律システムが状態情報11 4.4の内部のゲートウェイプロトコルインタフェース12を平らにします。

5. TOPOLOGY ISSUES                                                           13

5. トポロジー問題13

5.1 Topology Restrictions and Routing Loops                                  13
     5.1.1 Background                                                        13
     5.1.2 Current Policy                                                    14
5.2 Present ISI Configuration                                                15
     5.2.1 EGP Across ARPANET                                                17
     5.2.2 EGP Across ISI-NET                                                17
     5.2.3 Potential Routing Loop                                            18
5.3 Possible Future Configuration                                            18
     5.3.1 Gateway to UCI-ICS                                                18
     5.3.2 Dynamic Switch to Backup Gateway                                  19
          5.3.2.1 Usual Operation                                            19
          5.3.2.2 Host Initialization                                        19
          5.3.2.3 When Both the Primary and Backup are Down                  20
          5.3.2.4 Unix 4.2 BSD                                               20

UCI-ICS18 5.3への5.1トポロジーRestrictionsとルート設定Loops13 5.1.1Background13 5.1.2Current Policy14 5.2Present ISI Configuration15 5.2.1EGP Acrossアルパネット17 5.2.2EGP Across ISI-NET17 5.2.3Potentialルート設定Loop18 5.3Possible Future Configuration18 5.3.1ゲートウェイ、.2Dynamic Switch、Backupゲートウェイ19 5.3.2.1Usual Operation19 5.3.2.2Host初期設定19 5.3.2に、.3When BothのPrimaryとBackupはDown20 5.3.2.4Unix4.2BSD20です。

6. ACKNOWLEDGEMENT                                                           21

6. 承認21

7. REFERENCES                                                                22

RFC 911                                                                       1

7. 参照22RFC911 1

1. INTRODUCTION

1. 序論

The Exterior Gateway Protocol (EGP) [Rosen 82; Seamonson & Rosen 84; Mills 84a]
has been specified to allow autonomous development of different gateway systems
while  still  maintaining  global distribution of internet routing information.
EGP provides a means for  different  autonomous  gateway  systems  to  exchange
information about the networks that are reachable via them.

Exteriorゲートウェイプロトコル(EGP)[ローゼン82; Seamonsonとローゼン84;は84aを製粉する]は、まだインターネットルーティング情報のグローバルな分配を維持している間、異なったゲートウェイシステムの自動開発を許すために指定されました。 EGPは異なった自動ゲートウェイシステムがそれらを通して届いているネットワークに関して情報交換する手段を提供します。

This  report  mainly  describes  an  implementation  of EGP that runs as a user
                               *                                  **
process under the Berkeley Unix  4.2 operating system run on a VAX    computer.
Some  related issues concerning local autonomous system configurations are also
discussed.

このレポートはVAXコンピュータで動かされたバークレーUnix4.2オペレーティングシステムの下でユーザ***プロセスとして稼働するEGPの実装を主に記述します。 また、地方の自律システム構成に関するいくつかの関連する問題について議論します。

The EGP implementation is experimental and is not a part of Unix 4.2 BSD. It is
anticipated that Berkeley will incorporate a version of EGP in the future.

EGP実装は、実験的であり、Unix4.2BSDの一部ではありません。 バークレーが将来EGPのバージョンを取り入れると予期されます。

The program is written in C. The EGP  part  is  based  on  the  C-Gateway  code
written  by  Liza  Martin at MIT and the route management part is based on Unix
4.2 BSD route management daemon, "routed".

プログラムはC.に書かれています。ルート管理部分は、EGP部分がMITにライザ・マーチンによって書かれたC-ゲートウェイコードに基づいていて、Unix4.2BSDルート管理デーモンに基づいて、「発送されています」。

The EGP functions are consistent with the specification of [Mills  84a]  except
where noted.

有名であるところを除いて、EGP機能は[工場84a]の仕様と一致しています。

A  knowledge  of  EGP  as  described  in  [Seamonson  & Rosen 84; Mills 84a] is
assumed.

中で説明されるとしてのEGPに関する知識、[Seamonsonとローゼン84; ミルズ84a] 想定されます。

This chapter discusses the motivation for the project, Chapter 2 describes  the
gateway  design,  Chapter 3 is on testing, Chapter 4 suggests some enhancements
and Chapter 5 discusses topology issues.

本章はプロジェクトに関する動機について議論して、第2章はゲートウェイデザインについて説明して、テストには第3章があって、第4章は、いくつかの増進と第5章がトポロジー問題について議論するのを示します。

Further information about running the EGP program and describing  the  software
is being published in an ISI Research Report ISI/RR-84-145 [Kirton 84].

EGPプログラムを動かして、ソフトウェアについて説明することに関する詳細はISI Research Report ISI/RR-84-145[カートン84]で発表されています。

Requests  for  documentation  and  copies  of the EGP program should be sent to
Joyce Reynolds (JKReynolds@USC-ISIF.ARPA). Software support is not provided.

EGPプログラムのドキュメンテーションとコピーを求める要求をジョイス・レイノルズ( JKReynolds@USC-ISIF.ARPA )に送るべきです。 ソフトウェアサポートは提供されません。

1.1 Motivation for Development

1.1 開発に関する動機

With the introduction of EGP, the internet gateways  will  be  divided  into  a
"core"  autonomous  system  (AS)  of  gateways  maintained by Bolt, Beranek and
Newman  (BBN)  and  many  "stub"  AS's  that  are   maintained   by   different
organizations  and  have at least one network in common with a core AS gateway.
The core AS will act as a  hub  for  passing  on  routing  information  between

EGPの導入で、インターネットゲートウェイがBolt、Beranek、およびニューマン(BBN)によって維持されたゲートウェイの「コア」自律システム(AS)に分割されて、多くが、異なった組織によって維持されるASのものを「引き抜い」て、コアASゲートウェイと共用して少なくとも1つのネットワークを持っています。 ASがルーティング情報を伝えるためのハブとして機能するコア

_______________

_______________

  *
   Unix is a trade mark of AT&T
  **
    VAX is a trade mark of Digital Equipment Corporation

RFC 911                                                                       2

* unixはAT&T**VAXの商標がDEC RFC911 2の商標であるということです。

different  stub AS's so that it will only be necessary for stub AS's to conduct
EGP with a core gateway. Further detail is given in [Rosen 82].

相違、スタッブASがコアゲートウェイで単にEGPを行うのが必要であるように、ASのものを引き抜いてください。 [ローゼン82]で詳細を与えます。

At the time of this  project  there  were  28  "non-routing"  gateways  in  the
internet.  Non-routing  gateways  did  not  exchange  routing  information  but
required static entries in the core gateway routing tables.   Since  August  1,
1984  these  static  entries  have  been  eliminated and previously non-routing
gateways are required to communicate this  information  to  the  core  gateways
dynamically via EGP [Postel 84].

このプロジェクト時点で、インターネットには28「非ルーティング」門がありました。 非ルーティングゲートウェイは、ルーティング情報を交換しませんでしたが、コアゲートウェイ経路指定テーブルで静的なエントリーを必要としました。 1984年8月1日以来、これらの静的なエントリーは排除されています、そして、以前に、非ルーティングゲートウェイはEGP[ポステル84]を通してダイナミックにこの情報をコアゲートウェイに伝えなければなりません。

At the USC Information Sciences Institute (ISI) there was a non-routing gateway
to  the  University  of  California  at  Irvine  network  (UCI-ICS).  With  the
elimination of  non-routing  gateways  from  the  core  gateway  tables  it  is
necessary to inform the core ISI gateway of the route to UCI-ICS using EGP.

USC情報Sciences Institute(ISI)に、カリフォルニア大学アーバイン校ネットワーク(UCI-ICS)への非ルーティングゲートウェイがありました。 コアゲートウェイテーブルからの非ルーティングゲートウェイの除去によって、ルートのコアISIゲートウェイをEGPを使用するUCI-ICSに知らせるのが必要です。

Also,  we  would  like a backup gateway between ISI-NET and the ARPANET in case
the core ISI gateway is down. Such, a gateway  would  need  to  convey  routing
information  via EGP. Details of the ISI network configuration are discussed in
Section 5.2.

また、コアISIゲートウェイが下がっているといけなくて、私たちは、ISI-NETとアルパネットの間のバックアップゲートウェイが欲しいと思います。 そのようなaゲートウェイは、EGPを通してルーティング情報を伝える必要があるでしょう。 セクション5.2でISIネットワーク・コンフィギュレーションの詳細について議論します。

Of the 28 non-routing gateways 23 were implemented by Unix  systems,  including
ISI's.  Also, ISI's proposed backup gateway was a Unix system. Thus there was a
local and general need for an EGP implementation to run under Unix. The current
version  of  Unix  that  included  Department  of  Defense  (DoD) protocols was
Berkeley Unix 4.2 so this was selected.

28非ルーティング門では、23はISIのものを含むUnixシステムによって実装されました。 また、ISIの提案されたバックアップゲートウェイはUnixシステムでした。 したがって、EGP実装がUnixで実行される地方的、そして、一般的な必要がありました。 国防総省(DoD)プロトコルを含んでいたUnixの最新版がバークレーUnix4.2であったので、これは選択されました。

1.2 Overview of EGP

1.2 EGPの概要

This report assumes a knowledge of EGP, however a brief overview is given  here
for completeness. For further details refer to [Rosen 82] for the background to
EGP,  [Seamonson & Rosen 84] for an informal description, and [Mills 84a] for a
more formal specification and implementation details.

このレポートはEGPに関する知識を仮定して、しかしながら、完全性のために簡潔な概要をここに与えます。 さらに詳しい明細については非公式の記述のためのEGPと、[Seamonsonとローゼン84]へのバックグラウンドについて[ローゼン82]について言及して、より正式な仕様と実装の詳細のために[工場84a]について言及してください。

EGP is generally conducted between gateways in  different  AS's  that  share  a
common network, that is, neighbor gateways.

EGP is generally conducted between gateways in different AS's that share a common network, that is, neighbor gateways.

EGP  consists  of three procedures, neighbor acquisition, neighbor reachability
and network reachability.

EGPは3つの手順、隣人獲得、隣人の可到達性、およびネットワークの可到達性から成ります。

Neighbor acquisition is a two way handshake in which gateways agree to  conduct
EGP  by exchanging Request and Confirm messages which include the minimum Hello
and Poll  intervals.    Acquisition  is  terminated  by  exchanging  Cease  and
Cease-ack messages.

隣人獲得は、ゲートウェイがRequestを交換することによってEGPを行うのに同意するツーウェイ握手と、最小のHelloを含んでいるConfirmメッセージとPoll間隔です。 獲得は、CeaseとCease-ackメッセージを交換することによって、終えられます。

Neighbor  reachability  is  a  periodic exchange of Hello commands and I-H-U (I
heard you) responses to ensure that each gateway is up. Currently a  30  second
minimum interval is used across ARPANET. Only one gateway need send commands as
the   other   can  use  them  to  determine  reachability.  A  gateway  sending
reachability commands is said to be in the active mode, while  a  gateway  that
just responds is in the passive mode.

RFC 911                                                                       3

隣人の可到達性はHelloコマンドとそれぞれのゲートウェイが上がっているのを保証するI-H-U(私はあなたの声を聞いた)応答の周期的な交換です。 現在の、30秒の最小の間隔はアルパネットの向こう側に費やされます。 もう片方が可到達性を決定するのにそれらを使用できるように1門だけがコマンドを送らなければなりません。 可到達性コマンドを送るゲートウェイはアクティブなモードであると言われています、ただ応じるゲートウェイが受け身の形態でありますが。 RFC911 3

Network  reachability  is  determined by periodically sending Poll commands and
receiving Update responses which indicate the networks  reachable  via  one  or
more  gateways  on  the  shared network. Currently 2 minute minimum interval is
used across ARPANET.

RFC 911                                                                       4

ネットワークの可到達性は、コマンドをPollに送って、共用回線網の1門以上を通して届いているネットワークを示すUpdate応答を受けながら、定期的で決定します。 現在の、2分の最小間隔はアルパネットの向こう側に費やされます。 RFC911 4

2. GATEWAY DESIGN

2. ゲートウェイデザイン

EGP  is a polling protocol with loose timing constraints. Thus the only gateway
function requiring good performance is packet forwarding.  Unix 4.2 already has
packet forwarding built into the kernel where best performance can be achieved.
At the time of writing Unix 4.2 did not send  ICMP  (Internet  Control  Message
Protocol)  redirect  messages  for  misrouted packets. This is a requirement of
internet gateways and will later be added by Berkeley.

EGPはゆるいタイミング規制がある世論調査プロトコルです。 したがって、望ましい市場成果を必要とする唯一のゲートウェイ機能はパケット推進です。 unix4.2で、既に、達成できる中で性能最も良いカーネルをパケット推進に組み込みます。 これを書いている時点でUnix4.2はmisroutedパケットへの再直接のメッセージをICMP(インターネット・コントロール・メッセージ・プロトコル)に送りませんでした。 これは、インターネットゲートウェイの要件であり、後でバークレーによって加えられるでしょう。

The EGP and route update functions are implemented as a  user  process.    This
facilitates  development and distribution as only minor changes need to be made
to the Unix kernel.  This is a similar approach to the Unix route  distribution
program  "routed"  [Berkeley  83]  which  is  based  on  the  Xerox  NS Routing
Information Protocol [Xerox 81].

EGPとルートアップデート機能はユーザ・プロセスとして実装されます。 マイナーチェンジだけが、Unixカーネルに作られている必要があるとき、これは開発と分配を容易にします。 これはゼロックスNSルーティング情報プロトコル[ゼロックス81]に基づいている「発送された」Unixルート提供プログラム[バークレー83]への同様のアプローチです。

2.1 Routing Tables

2.1 ルート設定テーブル

A route consists of a destination network  number,  the  address  of  the  next
gateway  to  use  on  a  directly  connected  network,  and a metric giving the
distance in gateway hops to the destination network.

ルートは目的地ネットワーク・ナンバー(ゲートウェイの距離が送信先ネットワークに飛び越す直接接続されたネットワーク、およびメートル法の付与のときに使用する隣のゲートウェイのアドレス)から成ります。

There are two sets of routing  tables,  the  kernel  tables  (used  for  packet
forwarding) and the EGP process tables. The kernel has separate tables for host
and  network  destinations.  The EGP process only maintains the network routing
tables. The EGP tables are updated when EGP Update messages are received.  When
a  route is changed the kernel network tables are updated via the SIOCADDRT and
SIOCDELRT ioctl system calls. At  initialization  the  kernel  network  routing
tables  are  read  via the kernel memory image file, /dev/kmem, and copied into
the EGP tables for consistency.

2セットの経路指定テーブル、カーネルテーブル(パケット推進のために、使用される)、およびEGPプロセステーブルがあります。 カーネルには、ホストのための別々のテーブルとネットワークの目的地があります。 EGPプロセスはネットワーク経路指定テーブルを維持するだけです。 EGP Updateメッセージが受信されているとき、EGPテーブルをアップデートします。 ルートを変えるとき、SIOCADDRTとSIOCDELRT ioctlシステムコールでカーネルネットワークテーブルをアップデートします。 初期化では、カーネルネットワーク経路指定テーブルは、カーネルメモリイメージ・ファイル、/dev/kmemを通して読み込まれて、一貫性のためにEGPテーブルにコピーされます。

This EGP implementation is designed to run on a gateway that is  also  a  host.
Because  of  the relatively slow polling to obtain route updates it is possible
that the host may receive notification of routing changes  via  ICMP  redirects
before  the EGP process is notified via EGP. Redirects update the kernel tables
directly. The EGP process listens for redirect messages on  a  raw  socket  and
updates its routing tables to keep them consistent with the kernel.

このEGP実装は、またホストであるゲートウェイで走るように設計されています。 ルートアップデートを得るのが比較的遅い世論調査のために、EGPプロセスがEGPを通して通知される前にホストがICMPを通した変化が向け直すルーティングの通知を受け取るのは、可能です。 カーネルが直接見送るアップデートを向け直します。 EGPプロセスは、生のソケットに関する再直接のメッセージの聞こうとして、カーネルと一致しているようにそれらを保つために経路指定テーブルをアップデートします。

The  EGP  process routing tables are maintained as two separate tables, one for
exterior routes (via different AS gateways) and one for  interior  routes  (via
the  gateways of this AS).  The exterior routing table is updated by EGP Update
messages. The interior  routing  table  is  currently  static  and  is  set  at
initialization  time. It includes all directly attached nets, determined by the
SIOCGIFCONF ioctl system call and any interior non-routing gateways  read  from
the  EGP  initialization file, EGPINITFILE. The interior routing table could in
future be updated dynamically by an Interior Gateway Protocol (IGP).

2がテーブル、外のルート(異なったASゲートウェイを通した)への1、および内部のルート(このASのゲートウェイを通した)への1つを切り離すとき、EGPプロセス経路指定テーブルは維持されます。 EGP Updateメッセージは外の経路指定テーブルをアップデートします。 内部の経路指定テーブルは、現在、静的であり、初期化時に設定されます。 それはSIOCGIFCONF ioctlシステムコールで決定するすべての直接付属しているネットを含んでいます、そして、どんな内部の非ルーティングゲートウェイもEGP初期化ファイル(EGPINITFILE)から読みます。 Interiorゲートウェイプロトコル(IGP)でこれから、ダイナミックに内部の経路指定テーブルをアップデートできました。

Maintaining separate tables for exterior and interior routing  facilitates  the
preparation  of  outgoing  Update  messages which only contain interior routing
information [Mills 84b].  It also permits alternative external  routes  to  the
internal  routes  to  be  saved  as  a  backup in case an interior route fails.
Alternate routes are flagged,  RTS_NOTINSTALL,  to  indicate  that  the  kernel

RFC 911                                                                       5

外の、そして、内部のルーティングのために別々のテーブルを維持すると、内部のルーティング情報[84bを製粉する]を含むだけである送信するUpdateメッセージの準備は容易にされます。 また、内部のルートが失敗するといけないので、それは、内部のルートへの代替の外部経路がバックアップとして保存されることを許可します。 代替経路がそれを示すためには旗を揚げさせられた_RTS NOTINSTALLである、カーネルRFC911 5

routes  should  not  be updated. In the current implementation alternate routes
are not used.

ルートをアップデートするべきではありません。 現在の実装代替経路は使用されていません。

2.1.1 Incoming Updates

2.1.1 入って来るアップデート

EGP Updates are used to update  the  exterior  routing  table  if  one  of  the
following is satisfied:

以下の1つが満たされているなら、EGP Updatesは外の経路指定テーブルをアップデートするのに使用されます:

   - No  routing  table  entry  exists for the destination network and the
     metric indicates the route is reachable (< 255).

- 経路指定テーブルエントリーは全く送信先ネットワークのために存在していません、そして、メートル法はルートに届いているのを(<255)示します。

   - The advised gateway is the same as the current route.

- 慎重なゲートウェイは現在のルートと同じです。

   - The advised distance metric is less than the current metric.

- 慎重な距離メトリックは電流よりメートル法であることで少ないです。

   - The current route is older (plus a  margin)  than  the  maximum  poll
     interval  for  all  acquired  EGP  neighbors.  That is, the route was
     omitted from the last Update.

- 現在のルートはすべてのための最大の投票間隔がEGP隣人を取得したより古いです(マージン)。 すなわち、ルートは最後のUpdateから省略されました。

If any exterior route entry, except the default route, is not  updated  by  EGP
within  4  minutes  or  3  times  the  maximum  poll interval, whichever is the
greater, it is deleted.

4分以内のEGPか最大の投票間隔の3回のそばでデフォルトルート以外の少しの外のルートエントリーもアップデートしないなら、どれがさらに大きいかなら、それを削除します。

If there is more than one acquired EGP neighbor, the Update  messages  received
from each are treated the same way in the order they are received.

1人以上の後天的なEGP隣人がいれば、それぞれから受け取られたUpdateメッセージはずっとオーダーにおける扱われた同じくらい受信されています。

In  the worst case, when a route is changed to a longer route and the old route
is not first notified as unreachable, it  could  take  two  poll  intervals  to
update  a  route. With the current poll interval this could be 4 minutes. Under
Unix 4.2  BSD  TCP  connections  (Transmission  Control  Protocol)  are  closed
automatically  after  they  are idle for 6 minutes. So this worst case will not
result in the automatic closure of TCP connections.

ルートが、より長いルートに変わって、古いルートが最初に手の届かないとして通知されないとき、最悪の場合には、ルートをアップデートするには2回の投票間隔かかることができました。 現在の投票間隔で、これは4分であるかもしれません。 Unix4.2の下では、彼らが6分間活動していなくなった後にBSD TCP接続(通信制御プロトコル)は自動的に閉店します。 それで、この最悪の場合はTCP接続の自動閉鎖をもたらさないでしょう。

2.1.2 Outgoing Updates

2.1.2 外向的なアップデート

Outgoing Updates include the direct  and  static  networks  from  the  interior
routing table, except for the network shared with the EGP neighbor.

出発しているUpdatesはEGP隣人と共有されたネットワーク以外の内部の経路指定テーブルからのダイレクトで静的なネットワークを含んでいます。

The  networks  that  are  allowed  to be advised in Updates may be specified at
initialization in EGPINITFILE. This allows particular  routes  to  be  excluded
from  exterior updates in cases where routing loops could be a problem. Another
case where this option is necessary, is when there  is  a  non-routing  gateway
belonging  to  a different AS which has not implemented EGP yet. Its routes may
need to be included in the kernel routing table but they are not allowed to  be
advised in outgoing updates.

UpdatesでアドバイスできるネットワークはEGPINITFILEでの初期化で指定されるかもしれません。 これは、特定のルートがルーティング輪が問題であるかもしれない場合における外のアップデートから除かれるのを許容します。 このオプションが必要である別のケースはまだEGPを実行していない異なったASに属す非ルーティングゲートウェイがある時です。 ルートは、カーネル経路指定テーブルに含まれる必要があるかもしれませんが、それらは外向的なアップデートではアドバイスできません。

If  the  interior routing table includes other interior gateways on the network
shared with the EGP neighbor they are include in  Updates  as  the  appropriate

RFC 911                                                                       6

内部の経路指定テーブルがEGP隣人と共有されたネットワークの他の内部のゲートウェイを含んでいるなら、適切なRFC911としてUpdatesで6を含めてください。

first hop to their attached networks.

まず最初に、それらの付属ネットワークへ跳んでください。

The  distance to networks is set as in the interior routing table except if the
route is marked down in which case the distance  is  set  to  255.  At  present
routes are only marked down if the outgoing interface is down. The state of all
interfaces  is  checked  prior  to  preparing  each  outgoing  Update using the
SIOCGIFFLAGS ioctl system call.

ルートであること以外の経路指定テーブルが内部で距離がどの場合に255に設定されるかにマークされるとき、ネットワークへの距離は設定されます。 現在のところ、外向的なインタフェースが下がっている場合にだけ、ルートは値下げされます。 SIOCGIFFLAGS ioctlシステムコールを使用することでそれぞれの出発しているUpdateを準備する前に、すべてのインタフェースの状態はチェックされます。

Unsolicited Updates are not sent.

求められていないUpdatesは送られません。

2.2 Neighbor Acquisition

2.2 隣人獲得

EGPINITFILE lists the addresses of trusted EGP  neighbor  gateways,  which  are
read  at  initialization.  These  will  usually  be  core gateways as only core
gateways provide full internet routing information.  At  the  time  of  writing
there  were  three  core  gateways  on  ARPANET which support EGP, CSS-GATEWAY,
ISI-GATEWAY and PURDUE-CS-GW, and two on MILNET, BBN-MINET-A-GW and AERONET-GW.

EGPINITFILEは信じられたEGP隣人ゲートウェイのアドレスを記載します。(ゲートウェイは初期化で読まれます)。 コアゲートウェイだけが完全なインターネットルーティング情報を提供するとき、通常、これらはコアゲートウェイになるでしょう。 これを書いている時点で、アルパネットのMILNET、BBNミネタA GW、およびAERONET-GWでEGP、CSS-ゲートウェイ、ISI-ゲートウェイ、パドゥー-CS-GW、および2を支持する3コア門がありました。

EGPINITFILE also includes the maximum number of these gateways that  should  be
acquired  at  any  one  time.  This is usually expected to be just one. If this
gateway is declared down another gateway on the  list  will  then  be  acquired
automatically  in  sufficient  time  to  ensure that the current routes are not
timed out.

また、EGPINITFILEはいかなる時も入手されるべきであるこれらのゲートウェイの最大数を含んでいます。 通常、これはちょうど1であると予想されます。 下がっているとこのゲートウェイを申告すると、十分時間をかけて現在のルートが外で調節されていないのを保証するために自動的にリストの上のもう1門を入手するでしょう。

The gateway will only accept acquisitions from neighbors on  the  trusted  list
and  will  not  accept  them if it already has acquired its maximum quota. This
prevents Updates being accepted from possibly unreliable sources.

ゲートウェイは、信じられたリストで隣人から獲得を受け入れるだけであり、既に最大の割当てを取得したなら、彼らは受け入れないでしょう。 これは、Updatesがことによると頼り無いソースから受け入れられるのを防ぎます。

The ability to acquire core gateways that are not on the trusted list but  have
been  learned of indirectly via Update messages is not included because not all
core gateways run EGP.

すべてのコアゲートウェイがEGPを走らせるというわけではないので、信じられたリストにないコアゲートウェイを入手していますが、間接的にUpdateメッセージで知られるべきであった能力は含まれていません。

New acquisition Requests are sent to neighbors in  the  order  they  appear  in
EGPINITFILE.  No  more new Requests than the maximum number of neighbors yet to
be  acquired  are  sent  at  once.  Any  number  of  outstanding  Requests  are
retransmitted at 32 second intervals up to 5 retransmissions each at which time
the  acquisition  retransmission  interval  is increased to 4 minutes. Once the
maximum number of  neighbors  has  been  acquired,  unacquired  neighbors  with
outstanding  Requests  are  sent  Ceases.  This  approach provides a compromise
between fast response when neighbors do not initially respond and a  desire  to
minimize  the  chance that a neighbor may be Ceased after it has sent a Confirm
but before it has been received.  If the specified maximum number of  neighbors
cannot  be  acquired, Requests are retransmitted indefinitely to all unacquired
neighbors.

彼らがEGPINITFILEで見えるオーダーにおける隣人に新しい獲得Requestsを送ります。 すぐに、まだ取得されるべき隣人の最大数がRequestsでないことのようなどんな新しいRequestsも送りません。 それぞれ5「再-トランスミッション」までの獲得再送信間隔が4分まで増加する32回の2番目の間隔を置いて、いろいろな傑出しているRequestsが再送されます。 いったん隣人の最大数を取得すると、傑出しているRequestsをもっている非取得された隣人にCeasesを送ります。 Confirmを送った後にもかかわらず、それを受け取る前を除いて、このアプローチは隣人が初めは応じないときの速い応答と隣人がCeasedであるかもしれないという機会を最小にする願望の間に妥協を提供します。 指定された最大数の隣人を取得できないなら、Requestsはすべての非取得された隣人に無期限に再送されます。

2.3 Hello and Poll Intervals

2.3に、こんにちは、間隔に投票してください。

The Request and Confirm messages include minimum  values  for  Hello  and  Poll
intervals.  The advised minimums by this and the core gateways are currently 30
and 120 seconds respectively.

RFC 911                                                                       7

RequestとConfirmメッセージはHelloとPoll間隔の間、最小の値を含んでいます。 現在、これによる慎重な最小限とコアゲートウェイはそれぞれ30と120秒です。 RFC911 7

The  received  intervals  are  checked  against  upper  bounds to guard against
nonsense values. The upper bounds are currently set  at  120  and  480  seconds
respectively.  If,  they are exceeded the particular neighbor is considered bad
and not sent further Requests for one hour. This allows  the  situation  to  be
corrected  at  the  other  gateway and normal operation to automatically resume
from this gateway without an excess of unnecessary network traffic.

容認された間隔は、ナンセンス値に用心するために上限に対してチェックされます。 上限は120と480秒に現在、それぞれ設定されます。 それらは超えられていて、特定の隣人は悪いと考えられて、1時間一層のRequestsを送られないということです。 これは、状況が他のゲートウェイと通常操作のときにこのゲートウェイから不要なネットワークトラフィックの過剰なしで自動的に再開するために修正されるのを許容します。

The actual Hello and Poll intervals are chosen by first selecting  the  maximum
of  the  intervals  advised  by this gateway and its peer. A 2 second margin is
then added to the Hello interval to take  account  of  possible  network  delay
variations  and the Poll interval is increased to the next integer ratio of the
Hello interval. This results in 32 second Hello and 128 second Poll intervals.

実際のHelloとPoll間隔は、最初にこのゲートウェイとその同輩によってアドバイスされた間隔の最大を選択することによって、選ばれています。 次に、マージンがHello間隔に加えられる2秒に、可能なネットワーク遅延変化とPoll間隔を考慮に入れるのはHello間隔の次の整数比に増加します。 これは32回のHelloと2番目の128秒のPoll間隔に結果として生じます。

If an Update is not received in response to a Poll, at most  one  repoll  (same
sequence number) is sent instead of the next scheduled Hello.

Pollに対応してUpdateを受け取らないなら、最も1つでは、次の予定されているHelloの代わりに再投票(同じ一連番号)を送ります。

2.4 Neighbor Cease

2.4隣人はやみます。

If  the EGP process is sent a SIGTERM signal via the Kill command, all acquired
neighbors are sent Cease(going down) commands.  Ceases are retransmitted at the
hello interval at most 3 times.  Once all have either responded with Cease-acks
or been sent three retransmitted Ceases the process is terminated.

KillコマンドでSIGTERM信号をEGPの過程に送るなら、Cease(落ちる)コマンドをすべての後天的な隣人に送ります。 やむ、再送される、ほとんどの3回の間隔にこんにちは。 すべてはいったんCease-acksと共に反応するか、または3再送されたCeasesを送ると、過程が終えます。

2.5 Neighbor Reachability

2.5 隣人の可到達性

Only  active  reachability  determination  is  implemented.  It  is   done   as
recommended in [Mills 84a] with a minor variation noted below.

活発な可到達性決断だけが実行されます。 未成年者によるお勧め[84aを製粉する]の変化が以下で注意したようにそれをします。

A  shift  register  of responses is maintained.  For each Poll or Hello command
sent a zero is shifted into the shift register.  If a response  (I-H-U,  Update
or  Error) is received with the correct sequence number the zero is replaced by
a one.  Before each new command is  sent  the  reachability  is  determined  by
examining  the  last  four  entries  of  the shift register. If the neighbor is
reachable  and  <=  1  response  was  received  the  neighbor   is   considered
unreachable.  If the neighbor is considered unreachable and >= 3 responses were
received it is now considered reachable.

応答のシフトレジスタは維持されます。 PollかHelloコマンドが送ったそれぞれに関しては、ゼロはシフトレジスタに移行します。 適度の一連番号で応答(I-H-U、UpdateまたはError)を受けるなら、ゼロを1つに取り替えます。 それぞれの新しいコマンドを送る前に、可到達性は、シフトレジスタの最後の4つのエントリーを調べることによって、決定します。 隣人が届いていて、1つの<=応答を受けたなら、手が届かないと隣人を考えます。 手が届かないと隣人を考えて、3つの>=応答を受けたなら、現在、届くとそれを考えます。

A neighbor is considered reachable immediately after acquisition  so  that  the
first  poll  received  from  a  core  gateway  (once  it considers this gateway
reachable) will be responded to with an Update. Polls are  not  sent  unless  a
neighbor  is considered reachable and it has not advised that it considers this
gateway unreachable in its last Hello, I-H-U or Poll message.    This  prevents
the first Poll being discarded after a down/up transition. This is important as
the  Polls  are  used  for reachability determination. Following acquisition at
least one message must be received before the first Poll is sent.  This  is  to
determine  that  the  peer  does  not  consider this gateway down. This usually
requires at least one Hello to be sent prior to the first poll. The  discussion
of  this  paragraph  differs  from  [Mills 84a] which recommends that a peer be
considered down following acquisition and Polls may be sent as soon as the peer
is  considered  up.  This  is  the  only   significant   departure   from   the

RFC 911                                                                       8

隣人は、獲得直後Updateと共にコアゲートウェイ(このゲートウェイが届いているといったん考えると)から受けられた最初の投票に応じるように届くと考えられます。 隣人が届くのは考えられない場合、投票が送られません、そして、それはこのゲートウェイが最後のHello、I-H-UまたはPollメッセージで手が届かないと考えると忠告していません。 これは、最初のPollが下/の後に変遷に捨てられるのを防ぎます。 Pollsが可到達性決断に使用されるとき、これは重要です。 獲得に続いて、最初のPollを送る前に少なくとも1つのメッセージを受け取らなければなりません。 これは、同輩が、このゲートウェイが下であると考えないことを決定するためのものです。 通常、これは、少なくとも1Helloが最初の投票の前に送られるのを必要とします。 獲得に続いて、このパラグラフの議論は同輩が下がっていると考えられることを勧めるものと異なっています、そして、[84aを製粉します]同輩が上がると考えられるとすぐに、Pollsを送るかもしれません。 これはRFC911 8からの唯一の重要な出発です。

recommendations in [Mills 84a].

[工場84a]の推薦。

Polls  received  by  peers  that  are  considered unreachable are sent an Error
response which allows their reachability determination to  progress  correctly.
This action is an option within [Mills 84a].

正しく進歩をする彼らの可到達性決断を許容するError応答を手が届かないと考えられる同輩によって受けられた投票所に送ります。 この動作は[工場84a]の中のオプションです。

When  a  neighbor  becomes  unreachable  all  routes  using it as a gateway are
deleted from the routing table. If there are  known  unacquired  neighbors  the
unreachable gateway is ceased and an attempt is made to acquire a new neighbor.
If all known neighbors are acquired the reachability determination is continued
for  30  minutes  ([Mills  84a]  suggests  60  minutes)  after  which  time the
unreachable neighbor is ceased and reacquisition  attempted  every  4  minutes.
This is aimed at reducing unnecessary network traffic.

隣人が手が届かなくなるとき、ゲートウェイとしてそれを使用するすべてのルートが経路指定テーブルから削除されます。 非取得された隣人を知っているなら、手の届かないゲートウェイをやめます、そして、新しい隣人を取得するのを試みをします。 すべての知られている隣人が後天的であるなら、可到達性決断は手の届かない隣人がやめられる時、「再-獲得」が4分毎を試みた30分間(60分間示します[84aを製粉する])続けられています。 これは不要なネットワークトラフィックを減少させるのを目的とされます。

If  valid  Update  responses  are  not  received for three successive polls the
neighbor is ceased and an alternative acquired or reacquisition is attempted in
4 minutes. This provision is provided in case erroneous Update data formats are
being sent by the neighbor. This situation did occur  on  one  occasion  during
testing.

有効なUpdate応答が3つの連続した投票のために受けられないなら、隣人はやめられます、そして、取得された代替手段か「再-獲得」が4分後に試みられます。 誤ったUpdateデータ形式が隣人によって送られるといけないので、この支給を提供します。 この状況はテストの間、あるとき起こりました。

2.6 Sequence Numbers

2.6 一連番号

Sequence  numbers  are  managed  as recommended in [Mills 84a]. Single send and
receive sequence numbers are maintained for each neighbor.  The  send  sequence
number  is  initialized  to  zero  and is incremented before each new Poll (not
repoll) is sent and at no other time. The send sequence number is used  in  all
commands.  The  receive  sequence  number is maintained by copying the sequence
number of the last Request, Hello, or Poll command received  from  a  neighbor.
This  sequence  number  is  used  in outgoing Updates. All responses (including
Error responses) return the sequence number of the message just received.

一連番号は[工場84a]で推薦されるように管理されます。 シングルは、一連番号を送って、受けます。各隣人のために、維持されます。 送って他のどんな時にも、それぞれの新しいPoll(再投票しない)がない前にゼロに初期化されて、増加された一連番号を送ってください。 すべてのコマンドで使用される一連番号を送ってください。 一連番号を受けてください。コマンドが隣人から受けた最後のRequest、Hello、またはPollの一連番号をコピーすることによって、維持されます。 この一連番号は出発しているUpdatesで使用されます。 すべての応答(Error応答を含んでいる)がただ受け取られたメッセージの一連番号を返します。

2.7 Treatment of Excess Commands

2.7 余分なコマンドの処理

If more than 20 commands are received from a neighbor in any  8  minute  period
the  neighbor  is  considered  bad,  Ceased and reacquisition prevented for one
hour.

隣人が悪いと考えられるどんな8分の時代にも隣人から20以上のコマンドを受け取るなら、1時間防がれたCeasedと「再-獲得」です。

At most one repoll (same sequence number) received before the poll interval has
expired (less a 4 second margin for network delay variability) is responded  to
with  an  Update,  others are sent an Error response. When an Update is sent in
response to a repoll the unsolicited bit is not set,  which  differs  from  the
recommendation in [Mills 84a].

Updateと共に高々投票間隔が期限が切れる前に受け取られたある再投票(同じ一連番号)(ネットワーク遅延の可変性のための、より少ないa4 2番目のマージン)に応じて、Error応答を他のものに送ります。 再投票に対応してUpdateを送るとき、求められていないビット([工場84a]で推薦と異なっている)を設定しません。

2.8 Inappropriate Messages

2.8 不適当なメッセージ

If  a Confirm, Hello, I-H-U, Poll or Update is received from any gateway (known
or unknown) that is in the unacquired state, synchronization has probably  been
lost  for  some  reason. A Cease(protocol violation) message is sent to try and
reduce unnecessary network traffic. This action is an option in [Mills 84a].

RFC 911                                                                       9

非取得された状態にあるいくつかのゲートウェイ(知られているか未知の)からConfirm、Hello、I-H-U、PollまたはUpdateを受け取るなら、たぶんある理由で同期を失いました。 不要なネットワークトラフィックを減少させてみるためにCease(プロトコル違反)メッセージを送ります。 この動作は[工場84a]のオプションです。 RFC911 9

2.9 Default Gateway

2.9 デフォルトゲートウェイ

A  default gateway may be specified in EGPINITFILE. The default route (net 0 in
Unix 4.2 BSD) is used by the kernel packet forwarder if there  is  no  specific
route for the destination network. This provides a final level of backup if all
known EGP neighbors are unreachable. This is especially useful if there is only
one available EGP neighbor, as in the ISI case, Section 5.2.2.

デフォルトゲートウェイはEGPINITFILEで指定されるかもしれません。 送信先ネットワークのためのどんな特定のルートもなければ、デフォルトルート(Unix4.2BSDのネットの0)はカーネルパケット混載業者によって使用されます。 すべての知られているEGP隣人が手が届かないなら、これは最終的なレベルのバックアップを提供します。 1人の手があいているEGP隣人しかいなければ、これはISIケース、セクション5.2.2のように特に役に立ちます。

The  default route is installed at initialization and deleted after a valid EGP
Update message is received. It  is  reinstalled  if  all  known  neighbors  are
acquired  but  none  are  reachable,  if routes time out while there are no EGP
neighbors that are acquired and reachable, and prior to process termination.

有効なEGP Updateメッセージが受信されていた後に、デフォルトルートは、初期化にインストールされて、削除されます。 すべての知られている隣人が後天的ですが、なにも届かないならそれが再インストールされて、ルートであるなら、そこである間、タイムアウトは、後天的で届いているEGP隣人でなく、過程終了の前にそうです。

It is deleted after a valid EGP Update message is received because the  default
gateway will not know any more routing information than learned via EGP.  If it
were  not deleted, all traffic to unreachable nets would be sent to the default
gateway under Unix 4.2 forwarding strategy.

デフォルトゲートウェイがEGPを通して学習されるよりそれ以上のルーティング情報を知らないので有効なEGP Updateメッセージが受信されていた後にそれは削除されます。 それを削除しないなら、Unix4.2推進戦略の下で手の届かないネットへのすべての交通をデフォルトゲートウェイに送るでしょうに。

The default gateway should normally be set to a full-routing core gateway other
than the known EGP neighbor gateways to give another backup in case all of  the
EGP gateways are down simultaneously.

RFC 911                                                                      10

通常、知られているEGP隣人ゲートウェイ以外の完全なルーティングコアゲートウェイにEGPゲートウェイのすべてが同時に下がっているといけないのでデフォルトゲートウェイが別のバックアップに与えるように設定されるはずです。 RFC911 10

3. TESTING

3. テスト

A few interesting cases that occurred during testing are briefly described.

テストの間に現れたいくつかのおもしろいケースが簡潔に説明されます。

The   use   of  sequence  numbers  was  interpreted  differently  by  different
implementers. Consequently some implementations  rejected  messages  as  having
incorrect  sequence numbers, resulting in the peer gateway being declared down.
The main problem was that the specification was solely in narrative form  which
is  prone  to  inconsistencies, ambiguities and incompleteness. The more formal
specification of [Mills 84a] has eliminated these ambiguities.

一連番号の使用は異なったimplementersによって異なって解釈されました。 その結果いくつかの実現が下がっていると申告される同輩ゲートウェイをもたらして、不正確な一連番号を持っているとしてメッセージを拒絶しました。 主な問題は仕様が唯一矛盾、あいまいさ、および不備に傾向がある報告様式にあったということでした。 [工場84a]の、より正式な仕様はこれらのあいまいさを排除しました。

When testing  the  response  to  packets  addressed  to  a  neighbor  gateway's
interface  that  was  not  on  the  shared net a loop resulted as both gateways
repeatedly exchanged  error  messages  indicating  an  invalid  interface.  The
problem  was that both gateways were sending Error responses after checking the
addresses but before the EGP message type was checked.  This was  rectified  by
not  sending  an  Error response unless it was certain that the message was not
itself an Error response.

共有されたネットになかった隣人ゲートウェイのインタフェースに記述されたパケットへの応答をテストするとき、両方のゲートウェイが繰り返して無効のインタフェースを示すエラーメッセージを交換したとき、輪は結果として生じました。 問題はアドレスをチェックした後にもかかわらず、EGPメッセージタイプがチェックされる前を除いて、両方のゲートウェイが応答をErrorに送ったということでした。 これは、メッセージがそれ自体でError応答でなかったのが確かでなかったならError応答を送らないことによって、正されました。

On one occasion a core gateway had some  form  of  data  error  in  the  Update
messages  which  caused  them to be rejected even though reachability was being
satisfactorily conducted. This resulted in all routes being  timed  out.    The
solution  was  to  count  the  number of successive Polls that do not result in
valid Updates being received and if this number reaches  3  to  Cease  EGP  and
attempt to acquire an alternative gateway.

あるときコアゲートウェイには、可到達性が満足に行われていましたが、それらを拒絶したUpdateメッセージにおける、何らかの形式のデータ誤りがありました。 これは外で調節されているすべてのルートをもたらしました。 解決策は受け取られる有効なUpdatesをもたらさない連続したPolls、この数が3にCease EGPに達するか、そして、および代替ゲートウェイを入手する試みの数を数えることでした。

Another  interesting idiosyncrasy, reported by Mike Karels at Berkeley, results
from having multiple gateways between MILNET and ARPANET. Each ARPANET host has
an assigned gateway to use for access to MILNET. In cases where the EGP gateway
is a host as well as  a  gateway,  the  EGP  Update  messages  may  indicate  a
different  MILNET/ARPANET  gateway from the assigned one. When the host/gateway
originates a packet that is routed  via  the  EGP  reported  gateway,  it  will
receive  a  redirect to its assigned gateway.  Thus the MILNET gateway can keep
being switched between the gateway reported by EGP and the assigned gateway.  A
similar thing occurs when using routes to other nets reached via MILNET/ARPANET
gateways.

RFC 911                                                                      11

MILNETとアルパネットの間に複数のゲートウェイを持つのからのバークレー、結果でマイクKarelsによって報告された別のおもしろい特異性。 それぞれのアルパネットホストはMILNETへのアクセスに使用する割り当てられたゲートウェイを持っています。 EGPゲートウェイがゲートウェイと同様にホストである場合では、EGP Updateメッセージは割り当てられたものから異なったMILNET/アルパネットゲートウェイを示すかもしれません。 ホスト/ゲートウェイが由来するとき、EGPを通して発送されるパケットはゲートウェイを報告して、それは割り当てられたゲートウェイへの再直接のaを受けるでしょう。 したがって、MILNETゲートウェイは、切り換えられるのをEGPによって報告されたゲートウェイと割り当てられたゲートウェイの間に置くことができます。 MILNET/アルパネットゲートウェイを通して達した他のネットにルートを使用するとき、同様のものは現れます。 RFC911 11

4. FUTURE ENHANCEMENTS

4. 今後の増進

4.1 Multiple Autonomous Systems

4.1 複数の自律システム

The  present  method  of  acquiring  a  maximum  number of EGP neighbors from a
trusted list implies that all the neighbors are in the same AS.  The  intention
is  that  they all be members of the core AS. When updating the routing tables,
Updates are treated independently with no distinction made as  to  whether  the
advised  routes  are  internal  or  external  to  the peer's AS.  Also, routing
metrics are compared without reference to the AS of the source.

信じられたリストから最大数のEGP隣人を取得する現在の方法は、すべての隣人が同じASにいるのを含意します。 意志は彼らが皆、コアASのメンバーであるということです。 経路指定テーブルをアップデートするとき、Updatesは慎重なルートが同輩のASに内部である、または外部であるかに関してされた区別なしで独自に扱われます。 また、ルーティング測定基準はソースのASの参照なしで比較されます。

If EGP is to be  conducted  with  additional  AS's  beside  the  core  AS,  all
neighbors  on  the  list  would  need  to  be  acquired in order to ensure that
gateways from both AS's were always acquired. This results  in  an  unnecessary
excess  of  EGP  traffic if redundant neighbors are acquired for reliability. A
more desirable approach would be to have separate lists of trusted EGP gateways
and the maximum number to be acquire, for each AS. Routing entries  would  need
to  have  the  source AS added so that preference could be given to information
received from the owning AS (see Section 5.1.2)

EGPがコアASの横で追加ASのものと共に行われるつもりであるなら、リストの上のすべての隣人が、両方からそのゲートウェイを確実にするために取得して、いつもASのものを獲得したということである必要があるでしょう。 信頼性のために余分な隣人を取得するなら、これはEGP交通の不要な過剰をもたらします。 より望ましいアプローチは信じられたEGPゲートウェイの別々のリストとそれぞれのためにASを獲得することである最大数を持つだろうことです。 エントリーがソースASを持つために必要とするルート設定は、情報に、ASが優先を与えることができるように所有から受信していたと言い足しました。(セクション5.1.2を見ます)

4.2 Interface Monitoring

4.2 インタフェースモニター

At present, interface status is only checked immediately prior to  the  sending
of  an  Update  in response to a Poll.  The interface status could be monitored
more regularly and an unsolicited Update sent when a change is  detected.  This
is  one  area where the slow response of EGP polling could be improved. This is
of particular interest to networks that may  be  connected  by  dial-in  lines.
When such a network dials in, its associated interface will be marked as up but
it  will not be able to receive packets until the change has been propagated by
EGP. This is one case where the unsolicited  Update  message  would  help,  but
there  is still the delay for other non-core gateways to poll core EGP gateways
for the new routing information.

現在のところ、インタフェース状態はUpdateの発信のすぐ前にPollに対応してチェックされるだけです。 インタフェース状態は、より定期的にモニターされたかもしれません、そして、変化が検出されるとき、求められていないUpdateは発信しました。 これはEGP世論調査の遅い応答を改良できた1つの領域です。 これは特別にダイアルイン回線によって接続されるかもしれないネットワークにおもしろいです。 そのようなネットワークが直通電話にかけるとき、関連インタフェースは上がるのが示されるでしょうが、変化がEGPによって伝播されるまで、それはパケットを受けることができないでしょう。 これは求められていないUpdateメッセージが助けるでしょうが、他の中核でないゲートウェイが新しいルーティング情報のためにコアEGPゲートウェイに投票するように遅れがまだある1つのそうです。

This  was  one  case  where  it  was  initially  thought  that  a  kernel   EGP
implementation  might  help.  But  the kernel does not presently pass interface
status changes by interrupts so a new facility would need to  be  incorporated.
If  this was done it may be just as easy to provide a user level signal when an
interface status changes.

これは初めはカーネルEGP実現が助けるかもしれないと思われた1つのそうでした。 しかし、新しい施設が、法人組織である必要があるように、カーネルは現在、中断でインタフェース状態変化を通過しません。 インタフェース状態が変化するとき、これをしたなら、ユーザレベル信号を提供するのはちょうど同じくらい簡単であるかもしれません。

4.3 Network Level Status Information

4.3 ネットワークの平らな状態情報

At present, network level status reports, such as IMP  Destination  Unreachable
messages,  are  not used to detect changes in the reachability of EGP neighbors
or other neighbor gateways. This information should  be  used  to  improve  the
response time to changes.

RFC 911                                                                      12

現在のネットワークレベルでは、IMP Destination Unreachableメッセージなどの現状報告は、EGP隣人か他の隣人ゲートウェイの可到達性における変化を検出するのに使用されません。 この情報は、変化に応答時間を改良するのに使用されるべきです。 RFC911 12

4.4 Interior Gateway Protocol Interface

4.4 内部のゲートウェイプロトコルインタフェース

At  present  any  routing  information that is interior to the AS is static and
read from the initialization file. The internal route management functions have
been written so that it should be reasonably  easy  to  interface  an  IGP  for
dynamic  interior  route  updates. This is facilitated by the separation of the
exterior and interior routing tables.

現在のところ、どんなASに内部であることのルーティング情報も、静的であり、初期化ファイルから読まれます。 内部のルート管理機能が書かれているので、ダイナミックな内部のルートアップデートのためにIGPを連結するのは合理的に簡単であるはずです。 これは外の、そして、内部の経路指定テーブルの分離で容易にされます。

The outgoing EGP Updates will be correctly prepared from the  interior  routing
table by rt_NRnets() whether or not static or dynamic interior routing is done.
Functions  are  also  provided  for  looking  up, adding, changing and deleting
internal routes, i.e. rt_int_lookup(), rt_add(),  rt_change()  and  rt_delete()
respectively.

静的であるかダイナミックな内部のルーティングが完了しているか否かに関係なく、出発しているEGP Updatesはrt_NRnets()によって内部の経路指定テーブルから正しく準備されるでしょう。 機能がまた、内部のルート、すなわち、rt_int_ルックアップ()を見上げて、加えて、変えて、削除するために、rt_が()を加えるかどうかということである、rt_変化()とrt_はそれぞれ()を削除します。

The  interaction  of an IGP with the current data structures basically involves
three functions: updating the interior routing table using a  function  similar
to rt_NRupdate(), preparing outgoing interior updates similarly to rt_NRnets(),
and timing out interior routes similarly to rt_time().

RFC 911                                                                      13

現在のデータ構造とのIGPの相互作用は基本的に3つの機能にかかわります: rt_NRupdate()と同様の機能を使用することで内部の経路指定テーブルをアップデートして、外向的な内部を準備すると、出ている内部のルートはrt_時間()まで同様に同様にrt_NRnets()、およびタイミングにアップデートされます。 RFC911 13

5. TOPOLOGY ISSUES

5. トポロジー問題

5.1 Topology Restrictions and Routing Loops

5.1 トポロジー制限とルート設定輪

5.1.1 Background

5.1.1 バックグラウンド

EGP  is  not  a  routing  algorithm.  it  merely  enables exterior neighbors to
exchange routing information which is likely to  to  be  needed  by  a  routing
algorithm.  It does not pass sufficient information to prevent routing loops if
cycles exist in the topology [Rosen 82].

EGPはルーティング・アルゴリズムではありません。それは、ありそうなルーティング情報を交換する外の隣人がルーティング・アルゴリズムによって必要とされるのを単に可能にします。 それは、サイクルがトポロジー[ローゼン82]に存在しているなら輪を発送するのを防ぐために十分な情報を通過しません。

Routing loops can occur when two gateways think there are alternate  routes  to
reach a third gateway via each other. When the third gateway goes down they end
up  pointing  to  each  other  forming a routing loop.  Within the present core
system, loops are broken by counting to "infinity" (the  internet  diameter  in
gateway  hops).  This  (usually)  works  satisfactorily  because GGP propagates
changes fairly quickly as routing updates are sent as soon  as  changes  occur.
Also  the  diameter of the internet is quite small (5) and a universal distance
metric, hop count, is used. But this will be changed in the future.

2門が、互いを通して3番目のゲートウェイに達するように代替経路があると思うとき、ルート設定輪は現れることができます。 3番目のゲートウェイが落ちると、彼らは、結局、ルーティング輪を形成しながら、互いを示します。 現在のコア・システムの中では、輪は、「無限」(ゲートウェイホップのインターネット直径)まで数えることによって、壊されます。 変化が起こるとすぐに、ルーティングアップデートを送るのに応じてGGPがかなりすばやく変化を伝播するので、(通常、)これは満足に働いています。 また、インターネットの直径はかなり小さい(5)です、そして、普遍的な距離メトリック(ホップカウント)は使用されています。 しかし、将来、これを変えるでしょう。

With EGP, changes are propagated  slowly.  Although  a  single  unsolicited  NR
message  can  be  sent,  it  won't  necessarily  be passed straight on to other
gateways who must hear about it  indirectly.  Also,  the  distance  metrics  of
different  AS's  are  quite  independent  and  hence  can't be used to count to
infinity.

EGPと共に、変化はゆっくり伝播されます。 ただ一つの求められていないNRメッセージを送ることができますが、必ずまっすぐ間接的にそれについて聞かなければならない他のゲートウェイにそれを通過するというわけではないでしょう。 また、異なったASのものの距離測定基準は、かなり独立していて、したがって、無限で数えるのに使用できません。

The initial proposal was to prevent routing loops by restricting  the  topology
of  AS's to a tree structure so that there are no multiple routes via alternate
AS's.  Multiple routes within the same AS are allowed as  it  is  the  interior
routing strategies responsibility to control loops.

最初の提案は交互のASのものを通して複数のルートが全くないようにASのトポロジーを木構造に制限することによって輪を発送するのを防ぐことでした。 同じASの中の複数のルートが、輪を制御するのが、内部のルーティング戦略責任であるので、許容されています。

[Mills  84b]  has  noted that even with the tree topology restriction, "we must
assume that transient loops may form within the core system from time  to  time
and  that  this  information  may escape to other systems; however, it would be
expected that these loops would not persist for very long and would  be  broken
in  a  short  time  within the core system itself. Thus a loop between non-core
systems can persist until the first round of Update messages sent to the  other
systems  after  all traces of the loop have been purged from the core system or
until the reachability information ages out of  the  tables,  whichever  occurs
first".

[84bを製粉します] 木のトポロジー制限があっても、「私たちは、一時的な輪がコア・システムの中で時々形成されるかもしれなくて、この情報が他のシステムに逃げるかもしれないと思わなければならない」と述べました。 しかしながら、これらの輪が非常に長い間固執していなくて、まもなくコア・システム自体の中で壊れていると予想されるでしょう。 「その結果、Updateメッセージの最初のラウンドがテーブルから他のシステムにコア・システムが輪のすべての跡から追放された後か可到達性情報化時代まで発信するまで、中核でないシステムの間の輪は持続できます、どれが最初に起こっても。」

With the initial simple stub EGP systems the tree topology restriction could be
satisfied. But for the long term this does not provide sufficient robustness.

初期の簡単なスタッブEGPシステムに、木のトポロジー制限を満たすことができました。 しかし、長期の間、これは十分な丈夫さを提供しません。

[Mills  83]  proposed a procedure by which the AS's can dynamically reconfigure
themselves such that the topology restriction is always met, without  the  need
for  a  single  "core" AS.  One AS would own a shared net and its neighbor AS's
would just conduct EGP with the owner. The owner would pass on such information
indirectly as the core system does now. If the  owning  AS  is  defined  to  be
closest  to  the  root  of the tree topology, any haphazard interconnection can

RFC 911                                                                      14

[工場83]はASの缶がダイナミックに自分たちを再構成するのでトポロジー制限がいつも迎えられる手順を提案しました、独身の「コア」ASの必要性なしで。 1ASが共有されたネットを所有しているでしょう、そして、隣人ASのものは所有者と共にEGPをただ行うでしょう。 間接的にコア・システムが現在するように所有者はそのような情報を伝えるでしょう。 所有しているASは木のトポロジーの根の最も近くにあるように定義されます、どんな行き当たりばったりのインタコネクト缶RFC911 14

form  itself  into  an appropriate tree structured routing topology. By routing
topology I mean the topology as advised in routing updates. There may  well  be
other  physical  connections  but if they are not advised they will not be used
for routing. Each AS can conduct EGP with at most one AS that owns one  of  its
shared nets. Any AS that is not conducting EGP over any net owned by another AS
is  the  root of a subtree. It may conduct EGP with just one other AS that owns
one of its shared nets. This "attachment" combines  the  two  subtrees  into  a
single  subtree  such  that  the  overall  topology  is still a tree.  Topology
violations can be determined because two different AS's will report  that  they
can reach the same net.

適切な木の構造化されたルーティングトポロジーに形成してください。 ルーティングトポロジーのそばでは、私がルーティングアップデートでアドバイスされるようにトポロジーを言っています。 他の物理接続がたぶんいるでしょうが、アドバイスされないと、彼らはルーティングに使用されないでしょう。 各ASは高々共有されたネットの1つを所有している1ASとEGPを行うことができます。 別のASによって所有されていたどんなネットの上にもEGPを行っていないどんなASも下位木の根本です。 それは共有されたネットの1つを所有している他のちょうど1ASとEGPを行うかもしれません。 この「付属」が2つの下位木をただ一つの下位木に結合するので、それでも、総合的なトポロジーは木です。 異なったASの2ものが、同じネットに達することができると報告するので、トポロジー違反は決定できます。

With  such  a  dynamic  tree,  there may be preferred and backup links. In such
cases it is necessary to monitor the failed link so that routing can be changed
back to the preferred link when service is restored.

そのようなダイナミックな木をもって、都合のよい、そして、バックアップリンクがあるかもしれません。 そのような場合、失敗したリンクをモニターするのが、サービスが復元されるとき、ルーティングの都合のよいリンクにもとに戻られることができるくらい必要です。

Another aspect to consider is the possibility of detecting  routing  loops  and
then  breaking  them. Expiration of the packet time-to-live (TTL) could be used
to do this. If such a loop is suspected a diagnostic packet, such as ICMP echo,
could be sent over the suspect route to confirm whether it is a loop. If a loop
is detected a special  routing  packet  could  be  sent  over  the  route  that
instructs  each gateway to delete the route after forwarding the packet on. The
acceptance of new routing information may need to be delayed for  a  hold  down
period.  This approach would require sensible selection of the initial TTL. But
this is not done by many hosts.

考えるもう一つの側面はルーティング輪を検出して、次に、それらを壊す可能性です。 これをするのに生きるパケット現代(TTL)の満了を使用できました。 そのような輪を疑うなら、それが輪であるかどうか確認するためにICMPエコーなどの診断パケットを疑わしいルートの上に送るかもしれません。 輪を検出するなら、パケットを進めた後にオンなルートを削除するよう各ゲートウェイに命令するルートの上に特別なルーティングパケットを送るかもしれません。 新しいルーティング情報の承認は、抑制の期間、遅らせられる必要があるかもしれません。 このアプローチは初期のTTLの分別がある選択を必要とするでしょう。 しかし、これが多くのホストによって行われません。

5.1.2 Current Policy

5.1.2 通貨政策

Considering the general trend to  increased  network  interconnection  and  the
availability of alternative long-haul networks such as ARPANET, WBNET (wideband
satellite  network),  and public data networks the tree topology restriction is
generally unacceptable. A less restrictive topology is  currently  recommended.
The following is taken from [Mills 84b].

一般に、増加するネットワーク相互接続への一般的な傾向とアルパネットや、WBNET(広帯域衛星ネットワーク)や、公共のデータ網などの代替の長期ネットワークの有用性が木のトポロジー制限であると考えるのは容認できません。 それほど制限していないトポロジーは現在、お勧めです。 以下から、取ります[84bを製粉します]。

EGP topological model:

EGP位相モデル:

   - An  autonomous  system  consists  of  a  set of gateways connected by
     networks.  Each gateway in the system must be  reachable  from  every
     other  gateway in its system by paths including only gateways in that
     system.

- 自律システムはネットワークによって接続された1セットのゲートウェイから成ります。 そのシステムにゲートウェイだけを含んでいて、システムのそれぞれのゲートウェイは経路のそばでシステムの他のあらゆるゲートウェイから届いているに違いありません。

   - A gateway in a system may run EGP with a gateway in any other  system
     as  long  as the path over which EGP itself is run does not include a
     gateway in a third system.

- EGP自身が走る経路が3番目のシステムにゲートウェイを含んでいない限り、ゲートウェイがいかなる他のシステムにもある状態で、システムのゲートウェイはEGPを走らせるかもしれません。

   - The "core system" is distinguished from the others by the  fact  that
     only  it  is  allowed  to  distribute  reachability information about
     systems other than itself.

- それ自体以外のシステムの可到達性情報を分配できるという事実によって「コア・システム」は他のものと区別されます。

   - At least one gateway in every system must have a net in common with a
     gateway in the core system.

RFC 911                                                                      15

- あらゆるシステムの少なくとも1門には、コア・システムのゲートウェイと共用してネットがなければなりません。 RFC911 15

   - There  are  no  topological  or  connectivity restrictions other than
     those implied above.

- それら以外の暗示している位相的でないか接続性の制限が上にあります。

A gateway  will  use  information  derived  from  its  configuration  (directly
connected  nets),  the  IGP of its system, called S in the following, (interior
nets) and EGP (interior and exterior nets of neighboring systems) to  construct
its routing tables. If conflicts with respect to a particular net N occur, they
will be resolved as follows:

ゲートウェイは経路指定テーブルを組み立てるために構成(直接、ネットを接続する)、以下のSと呼ばれるシステム(内部のネット)とEGP(隣接しているシステムの内部の、そして、外の放送網)のIGPから得られた情報を使用するでしょう。 特定のネットのNに関する闘争が起こると、それらは以下の通り決議されるでしょう:

   - If  N  is  directly connected to the gateway, all IGP and EGP reports
     about N are disregarded.

- Nが直接ゲートウェイに接続されるなら、Nに関するすべてのIGPとEGPレポートは無視されます。

   - If N is reported by IGP as  interior  to  S  and  by  EGP  as  either
     interior  or  exterior  to  another  system,  the  IGP  report  takes
     precedence.

- NがSとEGPによる別のシステムへの内部か外であるのと同じくらい内部のIGPによって報告されるなら、IGPレポートは優先します。

   - If N is reported by EGP as interior to one  system  and  exterior  to
     another, the interior report takes precedence.

- Nが1台のシステムへの内部と別のものへの外としてEGPによって報告されるなら、内部のレポートは優先します。

   - If  N  is  reported  as  interior by two or more gateways of the same
     system using EGP, the reports specifying the smallest hop count  take
     precedence.

- Nが同じシステムの2門以上によってEGPを使用することで内部であると報告されるなら、指定する中でホップカウント最も小さいレポートは優先します。

   - In all other cases the latest received report takes precedence.

- 他のすべての場合では、最新の受け取られていているレポートは優先します。

Old information will be aged from the tables.

旧情報はテーブルから熟成するでしょう。

The   interim   model  provides  an  acceptable  degree  of  self-organization.
Transient routing loops can occur between systems,  but  these  are  eventually
broken by old reachability information being aged out of the tables.  Given the
fact  that  transient  loops  can occur due to temporary core-system loops, the
additional loops that might occur in the case of local nets homed  to  multiple
systems does not seem to increase the risk significantly.

当座のモデルは許容できる度の自己組織を提供します。 一時的なルーティング輪はシステムの間に現れることができますが、これらは結局、テーブルから熟成する古い可到達性情報によって壊されます。 事実を考えて、一時的な輪が一時的なコア・システム輪に当然の状態で現れることができて、ローカルのネットの場合で現れるかもしれない追加輪が複数のシステムと家へ帰ったのは危険をかなり増加させるように思えません。

5.2 Present ISI Configuration

5.2 現在のISI構成

A  simplified  version of the ISI network configuration is shown in Figure 5-1.
ISI-Hobgoblin can provide a backup gateway function  to  the  core  ISI-Gateway
between  ARPANET and ISI-NET. ISI-Hobgoblin is a VAX 11/750 which runs Berkeley
Unix  4.2.  The  EGP  implementation  described  in  this  report  is  run   on
ISI-Hobgoblin.

ISIネットワーク・コンフィギュレーションの簡易型のバージョンは図5-1に示されます。 ISI-おばけはアルパネットとISI-NETの間のコアISI-ゲートウェイにバックアップゲートウェイ機能を供給できます。 ISI-おばけはバークレーUnix4.2を走らせるVAX11/750です。 このレポートで説明されたEGP実現はISI-おばけにおける走行です。

ISI-Troll  is part of a split gateway to the University of California at Irvine
network (UCI-ICS). The complete logical gateway consists of ISI-Troll, the 9600
baud link and UCI-750A [Rose 84]. ISI-Troll runs Berkeley Unix 4.1a  and  hence
cannot  run  the  EGP  program.  It  is  therefore  a non-routing gateway.  The
existence of UCI-ICS net must be advised to the core AS by ISI-Hobgoblin.  This
can be done by including an appropriate entry in the EGPINITFILE.

ISI-トロールはカリフォルニア大学アーバイン校ネットワーク(UCI-ICS)への分裂ゲートウェイの一部です。 完全な論理的なゲートウェイはISI-トロール、9600年のボーリンク、およびUCI-750A[バラ84]から成ります。 ISI-トロールは、バークレーUnix 4.1aを走らせて、したがって、EGPプログラムを動かすことができません。 したがって、それは非ルーティングゲートウェイです。 ISI-おばけでUCI-ICSネットの存在をコアASまで教えなければなりません。 EGPINITFILEに適切なエントリーを含んでいることによって、これができます。

Hosts on ISI-NET, including ISI-Troll, have  static  route  entries  indicating
ISI-Gateway as the first hop for all networks other than UCI-ICS and ISI-NET.

RFC 911                                                                      16

ISI-トロールを含むISI-NETの上のホストには、UCI-ICSとISI-NET以外のすべてのネットワークのための最初のホップとしてISI-ゲートウェイを示すスタティックルートエントリーがあります。 RFC911 16

          -------------------------------------------------
         /                                                 \
        /                      ARPANET                      \
        \                        10                         /
         \                                                 /
          -------------------------------------------------
             |                    |                    |
             |                    |                    |
             |                    |                    |
      +-------------+      +-------------+      +---------------+
      | ISI-PNG11   |      |             |      |               |
      | Arpanet     |      | ISI-GATEWAY |      | ISI-HOBGOBLIN |
      | Address     |      |             |      |   Vax 11/750  |
      | logical     |      |  Core EGP   |      |   Unix 4.2    |
      | multiplexer |      |             |      |               |
      +-------------+      +-------------+      +---------------+
             |                    |                    |
             |                    |                    |
             |                    |                    |
      ---------------          ----------------------------
     /               \        /                            \
    / 3 Mb/s Ethernet \      /           ISI-NET            \
    \     net 10      /      \            128.9             /
     \               /        \                            /
      ---------------          ----------------------------
                                      |
                                      |
                                      |
                               +--------------+
                               |  ISI-TROLL   |
                               |  Vax 11/750  |
                               |  Unix 4.1a   |
                               |  Non-routing |
                               |      |       |
                               |      | 9600  |   ISI-TROLL, UCI-750A
                               |      | baud  |   and the link form a
                               |      | link  |   single logical gateway
                               |      |       |
                               |  UCI-750A    |
                               |  Vax 11/750  |
                               |  Unix 4.2    |
                               +--------------+
                                      |
                                      |
                                      |
                            ----------------------
                           /                      \
                          /        UCI-ICS         \
                          \        192.5.19        /
                           \                      /
                            ----------------------

------------------------------------------------- /\/アルパネット\10円/\/------------------------------------------------- | | | | | | | | | +-------------+ +-------------+ +---------------+ | ISI-PNG11| | | | | | Arpanet| | ISI-ゲートウェイ| | ISI-おばけ| | アドレス| | | | バックス11/750| | 当然| | コアEGP| | unix4.2| | 回線多重化装置| | | | | +-------------+ +-------------+ +---------------+ | | | | | | | | | --------------- ---------------------------- /\/3円の/Mb/sイーサネット\/ISI-NET\ネットの128.9/\10/円円/\/--------------- ---------------------------- | | | +--------------+ | ISI-トロール| | バックス11/750| | unix4.1a| | 非ルーティング| | | | | | 9600 | ISI-トロール、UCI-750A| | ボー| そして、リンクはaを形成します。| | リンク| 単一の論理的なゲートウェイ| | | | UCI-750A| | バックス11/750| | unix4.2| +--------------+ | | | ---------------------- 192.5円の.19/\/\/UCI-ICS円の/----------------------

              Figure 5-1:   Simplified ISI Network Configuration

RFC 911                                                                      17

図5-1: 簡易型のISIネットワーク・コンフィギュレーションRFC911 17

EGP can either be conducted with ISI-Gateway across ARPANET or ISI-NET.

ISI-ゲートウェイと共にアルパネットかISI-NETの向こう側にEGPを行うことができます。

5.2.1 EGP Across ARPANET

5.2.1 アルパネットの向こう側のEGP

ISI-Hobgoblin  will  advise  ISI-Gateway  across  ARPANET,  and  hence the core
system, that it can reach ISI-NET and UCI-ICS.

それは、ISI-おばけは、アルパネットの向こう側のISI-ゲートウェイにアドバイスして、したがって、コア・システムにアドバイスして、ISI-NETとUCI-ICSに達することができます。

Packets from AS's exterior to ISI and destined for UCI-ICS will be  routed  via
ISI-Gateway,  ISI-Hobgoblin  and  ISI-Troll.  The extra hop via ISI-Gateway (or
other core EGP gateway) is because the core gateways do not currently  pass  on
indirect-neighbor   exterior   gateway   addresses   in   their   IGP  messages
(Gateway-to-Gateway Protocol).  Packets originating from UCI-ICS  destined  for
exterior  AS's will be routed via ISI-Troll and ISI-Gateway.  Thus the incoming
and out going packet routes are different.

UCI-ICSのためのASの外部からISIであって運命づけられるまでのパケットはISI-ゲートウェイ、ISI-おばけ、およびISI-トロールを通して発送されるでしょう。 ISI-ゲートウェイ(または、他のコアEGPゲートウェイ)を通した余分なホップはコアゲートウェイが現在それらのIGPメッセージ(ゲートウェイからゲートウェイへのプロトコル)の間接的な隣人の外のゲートウェイアドレスを伝えないからです。 外のASのもののために運命づけられたUCI-ICSから発するパケットがISI-トロールとISI-ゲートウェイを通して発送されるでしょう。 したがって、入って来て外を行っているパケットルートは異なっています。

Packets originating from ISI-Hobgoblin as a host and destined for exterior AS's
will be routed via the appropriate gateway on ARPANET.

外のASのもののためにホストとしてISI-おばけから発して、運命づけられたパケットはアルパネットの適切なゲートウェイを通して発送されるでしょう。

UCI-ICS can only communicate with exterior AS's if ISI-Troll, ISI-Hobgoblin and
ISI-Gateway are all up. The dependence on ISI-Gateway could  be  eliminated  if
ISI-Troll  routed  packets via ISI-Hobgoblin rather than ISI-Gateway.  However,
as ISI-Hobgoblin is primarily a host and not a gateway it  is  preferable  that
ISI-Gateway route packets when possible.

ISI-トロール、ISI-おばけ、およびISI-ゲートウェイが皆、上がる場合にだけ、UCI-ICSは外のASのものとコミュニケートできます。 ISI-トロールがISI-ゲートウェイよりむしろISI-おばけでパケットを発送するなら、ISI-ゲートウェイへの依存を根絶できるでしょうに。 しかしながら、ISI-おばけがゲートウェイではなく、主としてホストであるので、可能であるときに、ISI-ゲートウェイがパケットを発送するのは、望ましいです。

ISI-Hobgoblin  can  provide a back-up gateway function to ISI-Gateway as it can
automatically switch to an alternative core EGP peer if ISI-Gateway goes  down.
Even  though  ISI-Hobgoblin  normally advises the core system that it can reach
ISI-NET the core uses its own internal route  via  ISI-Gateway  in  preference.
For hosts on ISI-NET to correctly route outgoing packets they need their static
gateway  entries  changed  from  ISI-Gateway to ISI-Hobgoblin.  At present this
would have to be done manually. This would only be appropriate  if  ISI-Gateway
was going to be down for an extended period.

ISI-おばけはISI-ゲートウェイが落ちるなら自動的に代替のコアEGP同輩に切り替わることができる間、ISI-ゲートウェイにバックアップゲートウェイ機能を提供できます。 ISI-おばけは、ISI-NETに達することができると通常コア・システムに忠告しますが、コアは好みにおけるISI-ゲートウェイを通してそれ自身の内部のルートを使用します。 ISI-NETの上のホストが正しく出発しているパケットを発送するように、それらは、彼らの静的なゲートウェイエントリーをISI-ゲートウェイからISI-おばけに変える必要があります。 現在のところ、手動でこれをしなければならないでしょう。 単にISI-ゲートウェイが長期間の間、あるなら、これは適切でしょうに。

5.2.2 EGP Across ISI-NET

5.2.2 ISI-ネットの向こう側のEGP

ISI-Hobgoblin   will  advise  ISI-Gateway  across  ISI-NET  that  its  indirect
neighbor, ISI-Troll, can reach UCI-ICS net.

ISI-おばけは、ISI-NETの向こう側に間接的な隣人(ISI-トロール)がUCI-ICSネットに達することができるとISI-ゲートウェイに忠告するでしょう。

All exterior packet routing  for  UCI-ICS  will  be  via  ISI-Gateway  in  both
directions   with   no  hops  via  ISI-Hobgoblin.    Packets  originating  from
ISI-Hobgoblin as a host and destined for  exterior  AS's  will  be  routed  via
ISI-Gateway, rather than the ARPANET interface, in both directions, thus taking
an additional hop.

UCI-ICSのためのすべての外のパケットルーティングは両方の方向へのISI-ゲートウェイを通してホップなしでISI-おばけを使用するでしょう。 外のASのもののためにホストとしてISI-おばけから発して、運命づけられたパケットはアルパネットインタフェースよりむしろISI-ゲートウェイを通して発送されるでしょう、両方の方向に、その結果、追加ホップを取ります。

UCI-ICS  can  only  communicate with exterior AS's if ISI-Troll and ISI-Gateway
are up and ISI-Hobgoblin has advised  ISI-Gateway  of  the  UCI-ICS  route.  If
ISI-Hobgoblin   goes   down,  communication  will  still  be  possible  because
ISI-gateway (and other core gateways)  do  not  time  out  routes  to  indirect

RFC 911                                                                      18

ISI-トロールとISI-ゲートウェイが上がっていて、ISI-おばけがISI-ゲートウェイにUCI-ICSルートを知らせた場合にだけ、UCI-ICSは外のASのものとコミュニケートできます。 ISI-ゲートウェイ(そして、他のコアゲートウェイ)が間接的なRFC911 18へのルートをどんなタイムアウトにもしないのでコミュニケーションがISI-おばけが落ちるのがまだ可能であるなら

neighbors.  If  ISI-Gateway  then  goes  down,  it will need to be readvised by
ISI-Hobgoblin of the UCI-ICS route, when it comes up.

隣人。 次に、ISI-ゲートウェイが落ちると、UCI-ICSルートのISI-おばけによって再アドバイスされるのが必要でしょう、来ると。

Conducting EGP over ISI-NET rather than ARPANET should  provide  more  reliable
service  for  UCI-ICS  for  the  following reasons: ISI-Gateway is specifically
designed as a gateway, it is expected to be up more than ISI-Hobgoblin,  it  is
desirable  to  eliminate  extra  routing  hops where possible and, the exterior
routing  information  will  persist  after  ISI-hobgoblin  goes   down.      If
ISI-Hobgoblin  is to be used in its back-up mode, EGP could be restarted across
ARPANET after the new gateway routes  are  manually  installed  in  the  hosts.
Therefore, EGP across ISI-NET was selected as the preferred mode of operation.

アルパネットよりむしろISI-NETの上にEGPを行うと、より信頼できるサービスは以下の理由でUCI-ICSに供給されるべきです: ISI-ゲートウェイはゲートウェイとして明確に設計されています、そして、ISI-おばけよりさらに上がると予想されて、可能であるところで付加的なルーティングホップを排除するのが望ましく、ISI-おばけが落ちた後に外のルーティング情報は持続するでしょう。 ISI-おばけがバックアップモードで使用されることであるなら、新しいゲートウェイルートが手動でホストにインストールされた後にEGPはアルパネットの向こう側に再開されるかもしれません。 したがって、ISI-NETの向こう側のEGPは操作の最もよく使われる方法として選定されました。

5.2.3 Potential Routing Loop

5.2.3 潜在的ルート設定輪

Because  both  ISI-Gateway and ISI-Hobgoblin provide routes between ARPANET and
ISI-NET there is a potential routing loop. This topology in fact  violates  the
original  tree  structure  restriction. Provided ISI-Hobgoblin does not conduct
EGP simultaneously with ISI-Gateway over ISI-NET and ARPANET, the gateways will
only ever know about the alternative route from the shared EGP network and  not
from  the  other  network.  Thus  a loop cannot occur.  For instance, if EGP is
conducted over ISI-NET, both ISI-Gateway and ISI-Hobgoblin will know about  the
alternative  routes  via  each other to ARPANET from ISI-NET, but they will not
know about the gateway addresses on ARPANET to be able to access  ISI-NET  from
ARPANET.  Thus  they have insufficient routing data to be able to route packets
in a loop between themselves.

ISI-ゲートウェイとISI-おばけの両方がアルパネットとISI-NETの間のルートを提供するので、潜在的ルーティング輪があります。 事実上、このトポロジーはオリジナルの木構造制限に違反します。 提供されたISI-おばけは同時にISI-ゲートウェイと共にISI-NETとアルパネットの上にEGPを行いません、とゲートウェイは他のネットワークから知るのではなく、代替のルートに関して共有されたEGPネットワークから知るだけでしょう。 したがって、輪は現れることができません。 例えば、EGPがISI-NETの上に行われるなら、ISI-ゲートウェイとISI-おばけの両方が互いを通して代替のルートに関してISI-NETからアルパネットに知るでしょうが、それらは、ゲートウェイに関してアルパネットに関するアドレスがアルパネットからISI-NETにアクセスできるのを知らないでしょう。 したがって、彼らには、輪で自分たちの間にパケットを発送できるように、不十分なルーティングデータがあります。

5.3 Possible Future Configuration

5.3 可能な将来の構成

5.3.1 Gateway to UCI-ICS

5.3.1 UCI-ICSへのゲートウェイ

An improvement in the reliability and performance of  the  service  offered  to
UCI-ICS  can  be  achieved  by  moving  the UCI-ICS interface from ISI-Troll to
ISI-Hobgoblin. Reliability  will  improve  because  the  connection  will  only
require  ISI-Hobgoblin  and its ARPANET interface to be up and performance will
improve because the extra gateway hop will be eliminated.

ISI-トロールからISI-おばけまでUCI-ICSインタフェースを動かすことによって、UCI-ICSに提供されたサービスの信頼性と性能における改良を達成できます。 接続が、ISI-おばけとそのアルパネットインタフェースが上がっているのを必要とするだけであるので、信頼性は向上するでしょう、そして、付加的なゲートウェイホップが排除されるので、性能は向上するでしょう。

This will also allow EGP to be conducted across ARPANET giving  access  to  the
alternative  core gateways running EGP. This will increase the chances of being
able to reliably acquire an EGP neighbor at all times. It will  also  eliminate
the  extra hop via ISI-Gateway for packets originating from ISI-Hobgoblin, as a
host, and destined for exterior networks.

また、これは、EGPがEGPを実行する代替のコアゲートウェイへのアクセスを与えるアルパネットの向こう側に行われるのを許容するでしょう。 これはできるのがEGP隣人を確かにいつも取得する可能性を増強するでしょう。 また、それは外のネットワークのためにホストとしてISI-おばけから発して、運命づけられたパケットのためのISI-ゲートウェイを通して付加的なホップを排除するでしょう。

This configuration change will be made at sometime in the future.  It  was  not
done  initially because ISI-Hobgoblin was experimental and down more often than
ISI-Troll.

RFC 911                                                                      19

この構成変更は将来、いつかで作られるでしょう。 ISI-おばけがISI-トロールよりしばしば実験的であって、下がっていたので、初めは、それをしませんでした。 RFC911 19

5.3.2 Dynamic Switch to Backup Gateway

5.3.2 ゲートウェイのバックアップをとるダイナミックなスイッチ

It  was  noted in Section 5.2.1 that ISI-Hobgoblin can provide a backup gateway
function to ISI-Gateway between ARPANET and ISI-NET. Such backup gateways could
become a common approach to providing increased reliability.

セクション5.2.1では、ISI-おばけがアルパネットとISI-NETの間でISI-ゲートウェイにバックアップゲートウェイ機能を提供できることに注意されました。 そのようなバックアップゲートウェイは増強された信頼性を提供することへの一般的なアプローチになることができました。

At present the change over to the backup gateway requires the new gateway route
to be manually entered for hosts on ISI-NET. This section describes a  possible
method  for achieving this changeover dynamically when the primary gateway goes
down.

現在のところ、バックアップゲートウェイへの変化は、新しいゲートウェイルートがホストのために手動でISI-NETに入れられるのを必要とします。 このセクションはプライマリゲートウェイが落ちるときダイナミックにこの転換を達成するための可能なメソッドを説明します。

The aim is to be able to detect when the primary gateway is down and  have  all
hosts  on  the local network change to the backup gateway with a minimum amount
of additional network traffic. The hosts should  revert  back  to  the  primary
gateway when it comes up again.

目的は最小の量の追加ネットワークトラフィックでプライマリゲートウェイがいつ下がっているかを検出して、企業内情報通信網のすべてのホストにバックアップゲートウェイに変化させることであることができます。 再び来るとき、ホストはプライマリゲートウェイに先祖帰りをして戻るべきです。

The  proposed  method  is  for  only  the backup gateway to monitor the primary
gateway status and for it to notify all hosts of the new gateway  address  when
there is a change.

提案されたメソッドは、変化があるとき、バックアップゲートウェイだけがプライマリゲートウェイ状態をモニターして、新しいゲートウェイアドレスについてすべてのホストに通知することです。

5.3.2.1 Usual Operation

5.3.2.1 普通の操作

The backup gateway runs a process which sends reachability-probe messages, such
as  ICMP echoes, to the primary gateway every 30 seconds and uses the responses
to determine reachability as for EGP.  If  the  primary  gateway  goes  down  a
"gateway-address  message"  indicating  the backup gateway address is broadcast
(or preferably multicast) to all hosts.  When  the  primary  gateway  comes  up
another  gateway  message  indicating the primary gateway address is broadcast.
These broadcasts should be done four times at 30 second intervals to avoid  the
need for acknowledgements and knowledge of host addresses.

バックアップゲートウェイは、30秒毎にプライマリゲートウェイへのICMPエコーなどの可到達性徹底的調査メッセージを送るプロセスを実行して、EGPのように可到達性を決定するのに応答を使用します。 プライマリゲートウェイがバックアップを示しながら「ゲートウェイアドレスメッセージ」を下るなら、ゲートウェイアドレスはすべてのホストに放送されます(または、望ましくはマルチキャスト)。 プライマリゲートウェイが来るとき、プライマリゲートウェイアドレスを示す別のゲートウェイメッセージが放送されます。 30回の2番目の間隔を置いて、ホスト・アドレスに関する承認と知識の必要性を避けるためにこれらの放送に4回をするべきです。

Each  host  would run a process that listens for gateway-address messages. If a
different gateway is advised it changes the default gateway entry  to  the  new
address.

各ホストはゲートウェイアドレスメッセージの聞こうとするプロセスを実行するでしょう。 異なったゲートウェイがアドバイスされるなら、それはデフォルトゲートウェイエントリーを新しいアドレスに変えます。

5.3.2.2 Host Initialization

5.3.2.2 ホスト初期設定

When  a  host comes up the primary gateway could be down so it needs to be able
to determine that it should use the backup gateway. The  host  could  read  the
address  of  the primary and backup gateways from a static initialization file.
It would then set its default  gateway  as  the  primary  gateway  and  send  a
"gateway-request  message" to the backup gateway requesting the current gateway
address. The backup gateway would respond with a gateway-address message.    If
no response is received the gateway-request should be retransmitted three times
at  30  second intervals.  If no response is received the backup gateway can be
assumed down and the primary gateway retained as the default.

ホストが来るとき、プライマリゲートウェイが下がるかもしれないので、それは、バックアップゲートウェイを使用するべきであることを決定できる必要があります。 ホストは、予備選挙のアドレスを読んで、静的な初期化ファイルからゲートウェイのバックアップをとることができました。 それは、現在のゲートウェイアドレスを要求するバックアップゲートウェイに、次に、プライマリゲートウェイとしてデフォルトゲートウェイを設定して、「ゲートウェイ要求メッセージ」を送るでしょう。 バックアップゲートウェイはゲートウェイアドレスメッセージで応じるでしょう。 どんな応答も受け取られていないなら、30回の2番目の間隔を置いて、ゲートウェイ要求は3回再送されるべきです。 どんな応答も受け取られていないなら、下であるのとデフォルトとして保有されたプライマリゲートウェイであるとバックアップゲートウェイを思うことができます。

Whenever the backup gateway comes up it broadcasts a gateway-address message.

バックアップゲートウェイが来るときはいつも、それはゲートウェイアドレスメッセージを放送します。

Alternatively, a broadcast (or  multicast)  gateway-request  message  could  be

RFC 911                                                                      20

あるいはまた、放送(または、マルチキャスト)ゲートウェイ要求メッセージはRFC911 20であるかもしれません。

defined  to  which  only  gateways  would  respond.  The backup gateway-address
message needs to indicate that it is the backup gateway so that future requests
need not be broadcast. Again, three retransmissions should be used.    But  the
primary gateway also needs to broadcast its address whenever it comes up.

どの唯一のゲートウェイが応じるだろうかと定義されます。 バックアップゲートウェイアドレスメッセージは、それが今後の要求が放送される必要はないためのバックアップゲートウェイであることを示す必要があります。 一方、3「再-トランスミッション」は使用されるべきです。 しかし、また、プライマリゲートウェイは、来るときはいつも、アドレスを放送する必要があります。

5.3.2.3 When Both the Primary and Backup are Down

5.3.2.3 Bothであるときに、PrimaryとBackupはDownです。

If the primary gateway is down and the backup knows it is going down, it should
broadcast  gateway-address  messages indicating the primary gateway in case the
primary gateway comes up first.

プライマリゲートウェイが下がっていて、バックアップが、それが落ちているのを知っているなら、それはプライマリゲートウェイが最初に来るといけないのでプライマリゲートウェイを示すゲートウェイアドレスメッセージを放送するべきです。

But the backup could go down without warning and the primary come up before it.
If the primary gateway broadcasts a gateway-address message when  it  comes  up
there  is  no problem. Otherwise, while hosts are using the backup gateway they
should send a gateway-request message every  10  minutes.  If  no  response  is
received it should be retransmitted 3 times at 30 second intervals and if still
no response the backup assumed down and the primary gateway reverted to.

しかし、バックアップはいきなり落ちることができました、そして、予備選挙はそれの前に来ます。 そこに来るとき、プライマリゲートウェイ放送であるなら、ゲートウェイアドレスメッセージは問題ではありません。 さもなければ、ホストがバックアップゲートウェイを使用している間、彼らは10分あたり1つのゲートウェイ要求メッセージに発信するべきです。 どんな応答も受け取られていないなら、30回の2番目の間隔を置いて、それは3回再送されるべきでした、そして、それでも、応答でないなら、バックアップは下であるのとプライマリゲートウェイが戻ったと仮定しました。

Thus the only time hosts need to send messages periodically is when the primary
gateway  does  not  send  gateway-address  messages on coming up and the backup
gateway is being used. In some cases, such as at ISI, the  primary  gateway  is
managed  by  a  different  organization  and  experimental  features  cannot be
conveniently added.

したがって、ホストが定期的にメッセージを送るために必要とする唯一の時間がプライマリゲートウェイが来るときゲートウェイアドレスメッセージを送らない時です、そして、バックアップゲートウェイは使用されています。 ISIなどのいくつかの場合では、異なった組織はプライマリゲートウェイを管理します、そして、便利に実験特徴を加えることができません。

5.3.2.4 Unix 4.2 BSD

5.3.2.4 unix4.2BSD

One difficulty with the above is that there is no standard method of specifying
internet broadcast or multicast addresses. Multicast addressing  is  preferable
as  only those participating need process the message (interfaces with hardware
multicast detection are available). In the case of Unix  4.2  BSD  an  internet
address  with zero local address is assumed for the internet broadcast address.
However, the general Internet Addressing policy is to use an all ones value  to
indicate a broadcast function.

上記の1つの困難はインターネット放送かマルチキャストアドレスを指定する標準方法が全くないということです。 参加が必要とするものだけがメッセージを処理するとき(ハードウェアマルチキャスト検出とのインタフェースは利用可能です)、マルチキャストアドレシングは望ましいです。 Unix4.2BSDの場合では、ローカルアドレスがないインターネットアドレスはインターネット放送演説のために想定されます。 しかしながら、一般的なインターネットAddressing方針は放送機能を示すのにすべてのもの値を使用することです。

On  Unix  4.2  BSD systems, both the gateway and host processes could be run at
the user level so that kernel modifications are not required.

Unix4.2では、BSDシステム、ゲートウェイとホストプロセスの両方がユーザレベルにおいて走行であるかもしれないので、カーネル変更は必要ではありません。

A User Datagram Protocol (UDP) socket could be reserved for host-backup-gateway
communication.

ホストバックアップゲートウェイコミュニケーションのためにユーザー・データグラム・プロトコル(UDP)ソケットを予約できました。

Super user access to raw sockets for sending and receiving ICMP  Echo  messages
requires a minor modification to the internet-family protocol switch table.

RFC 911                                                                      21

送受信ICMP Echoメッセージのための生のソケットへのスーパーユーザアクセスはインターネットファミリープロトコルスイッチテーブルへの小さい方の変更を必要とします。 RFC911 21

6. ACKNOWLEDGEMENT

6. 承認

I acknowledge with thanks the many people who have helped me with this project,
but  in  particular,  Dave  Mills,  who  suggested  the project, Jon Postel for
discussion and encouragement, Liza Martin for providing the initial  EGP  code,
Berkeley  for  providing  the  "routed"  code, Mike Brescia for assistance with
testing, Telecom Australia for funding me, and ISI for providing facilities.

RFC 911                                                                      22

デーヴ・ミルズ、私は感謝でこのプロジェクトと共に私を助けた多くの人々を承認しますが、特に、だれがプロジェクト、議論と奨励のためのジョン・ポステル、初期のEGPコードを提供するためのライザ・マーチン、「発送された」コードを提供するためのバークレー、テストによる支援のためのマイク・ブレシア、私に資金を供給するためのオーストラリア電信電話公社、および便宜を与えるためのISIを勧めましたか? RFC911 22

7. REFERENCES

7. 参照

[Berkeley 83]   "Unix  Programmer's  Manual",  Vol.  1,  4.2  Berkeley Software
                Distribution, University of California, Berkeley.

[バークレー83] 「unixプログラマのマニュアル」、Vol.1、4.2バークレーのソフトウェア配布、カリフォルニア大学バークレイ校。

[Kirton 84]     Kirton, P.A., "EGP Gateway Under Berkeley Unix 4.2", University
                of  Southern  California,   Information   Sciences   Institute,
                Research Report ISI/RR-84-145, to be published.

カートン、[カートン84]P.A.、「EGPゲートウェイ、バークレーunixの下では、何4.2インチも、南カリフォルニア大学(科学が設ける情報)が発行されるためにレポートISI/RR-84-145について研究する、」

[Mills 83]      Mills,  D.L.,  "EGP Models and Self-Organizing Systems" Message
                to EGP-PEOPLE@BBN-UNIX, Nov. 1983.

[工場83] 工場、D.L.、 EGP-PEOPLE@BBN-UNIX 、1983年11月までの「EGPモデルと自己最適化システム」メッセージ。

[Mills 84a]     Mills, D.L., "Exterior Gateway Protocol Formal  Specification",
                Network Information Center RFC 904, April 1984.

[84aを製粉します] D.L.、「外のゲートウェイプロトコル形式仕様」という工場はインフォメーション・センターRFC904、1984年4月をネットワークでつなぎます。

[Mills 84b]     Mills,  D.L.,  "Revised  EGP  Model  Clarified  and Discussed",
                Message to EGP-PEOPLE@BBN-UNIX, May 1984.

[84bを製粉します] 工場(D.L.、「はっきりさせられて、議論した改訂されたEGPモデル」、 EGP-PEOPLE@BBN-UNIX へのメッセージ)は1984がそうするかもしれません。

[Postel 84]     Postel, J., "Exterior Gateway Protocol Implementation Schedule"
                Network Information Center RFC 890, Feb. 1984.

[ポステル84]ポステル、J.、「外のゲートウェイプロトコル遂行スケジュール」がインフォメーション・センターRFC890、1984年2月をネットワークでつなぎます。

[Rose 84]       Rose, M.T., "Low-Tech Connection into  the  ARPA-Internet:  The
                Raw-Packet   Split  Gateway",  Department  of  Information  and
                Computer Science, University of California,  Irvine,  Technical
                Report 216, Feb. 1984.

ローズ、[バラ84]M.T.、「アルパインターネットとの低い科学技術の接続:」 「生のパケット分裂ゲートウェイ」、情報とコンピュータサイエンス、カリフォルニア大学アーバイン校の部、技術報告書216、1984年2月。

[Rosen 82]      Rosen,  E.C.,  "Exterior Gateway Protocol", Network Information
                Center RFC 827, Oct. 1982.

[ローゼン82]ローゼン、E.C.、「外のゲートウェイプロトコル」がインフォメーション・センターRFC827、1982年10月をネットワークでつなぎます。

[Seamonson & Rosen 84]
                Seamonson,  L.J.  and  Rosen,  E.C.,  "Stub  Exterior   Gateway
                Protocol", Network Information Center RFC 888, Jan. 84.

E.C.、「スタッブの外のゲートウェイプロトコル」という[Seamonsonとローゼン84]Seamonson、L.J.、およびローゼンはインフォメーション・センターRFC888、1月84日をネットワークでつなぎます。

[Xerox 81]      "Internet   Transport   Protocols",  Xerox  System  Integration
                Standard XSIS 028112, Dec. 1981.

[ゼロックス81] 「インターネットトランスポート・プロトコル」、ゼロックスのシステムインテグレーションの標準のXSIS028112、1981年12月。

スポンサーリンク

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

伊豆・三津シーパラダイス(みと)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る