RFC1504 日本語訳
1504 Appletalk Update-Based Routing Protocol: Enhanced AppletalkRouting. A. Oppenheimer. August 1993. (Format: TXT=201553 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Oppenheimer
Request for Comments: 1504 Apple Computer
August 1993
コメントを求めるワーキンググループA.オッペンハイマー要求をネットワークでつないでください: 1504 アップル・コンピューター1993年8月
Appletalk Update-Based Routing Protocol:
Enhanced Appletalk Routing
Appletalkのアップデートベースのルーティング・プロトコル: 高められたAppletalkルート設定
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Introduction
序論
This memo is being distributed to members of the Internet community to fully document an Apple protocol that may be running over the Internet. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers.
このメモは、インターネットを中を走らせているかもしれないアップルプロトコルを完全に記録するためにインターネットコミュニティのメンバーに配布されています。 議論した問題が直接インターネットの研究課題に関連していないかもしれない間、それらは多くの研究者とimplementersにおもしろいかもしれません。
About This Document
このドキュメントに関して
This document provides detailed information about the AppleTalk Update-based Routing Protocol (AURP) and wide area routing. AURP provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. The organization of this document has as its basis the three major components of AURP:
このドキュメントはAppleTalkのUpdateベースのルート設定プロトコル(AURP)と広い領域ルーティングの詳細な情報を提供します。 AURPは広い領域ルーティング増進をAppleTalkルーティング・プロトコルに提供して、AppleTalk Phase2と完全に互換性があります。 このドキュメントの組織には、基礎としてAURPの3個の主要コンポーネントがあります:
AppleTalk tunneling, which allows AppleTalk data to pass through
foreign networks and over point-to-point links
AppleTalkトンネリング。(そのトンネリングで、AppleTalkデータは外国ネットワークを通してポイントツーポイント接続の上で終わります)。
the propagation of AppleTalk routing information between internet
routers connected through foreign networks or over point-to-point
links
外国ネットワークを通して、または、ポイントツーポイント接続の上に関連づけられたインターネットルータの間のAppleTalkルーティング情報の伝播
the presentation of AppleTalk network information by an internet
router to nodes and other Phase 2-compatible routers on its local
internet
ノードへのインターネットルータによるAppleTalkネットワーク情報と地方のインターネットに関する他のPhaseの2コンパチブルルータのプレゼンテーション
What This Document Contains
このドキュメントが含むこと
The chapters of this document contain the following information:
このドキュメントの章は以下の情報を含んでいます:
Chapter 1, "Introduction to the AppleTalk Update-Based Routing
Protocol," introduces the three major components of AURP and the
そして「AppleTalkのアップデートベースのルーティング・プロトコルへの序論」という第1章がAURPの3個の主要コンポーネントを導入する。
Oppenheimer [Page 1] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[1ページ]RFC1504Appletalk
key wide area routing enhancements that AURP provides to the
AppleTalk routing protocols.
AURPがAppleTalkルーティング・プロトコルに提供する主要な広い領域ルーティング増進。
Chapter 2, "Wide Area AppleTalk Connectivity," provides
information about AppleTalk tunneling through IP internets and over
point-to-point links.
「広い領域AppleTalkの接続性」という第2章はIPインターネットを通してトンネルを堀るAppleTalkの周りと、そして、ポイントツーポイント接続の上に情報を供給します。
Chapter 3, "Propagating Routing Information With the AppleTalk
Update-Based Routing Protocol," describes the essential elements of
AURP, including the architectural model for update-based routing.
This chapter provides detailed information about the methods that
AURP uses to propagate routing information between internet routers
connected through tunnels.
「AppleTalkのアップデートベースのルーティング・プロトコルで経路情報を伝播し」て、第3章はAURPの必須元素について説明します、アップデートベースのルーティングのための建築モデルを含んでいて。 本章はAURPがルーティング情報を伝播するのに使用するメソッドの詳細な情報をトンネルを通って接続されたインターネットルータの間に提供します。
Chapter 4, "Representing Wide Area Network Information," describes
optional features of AURP-some of which can also be implemented on
routers that use RTMP rather than AURP for routing-information
propagation. It gives detailed information about how an exterior
router represents imported network information to its local
internet and to other exterior routers. It describes network
hiding, device hiding, network-number remapping, clustering, loop
detection, hop-count reduction, hop-count weighting, and backup
paths.
「ワイドエリアネットワーク情報を表し」て、第4章はまた、ルーティング情報伝播にAURPよりむしろRTMPを使用するルータでどれを実装することができるかについていくつかAURPに関するオプション機能について説明します。 それは外のルータがどう地方のインターネットと、そして、他の外のルータにインポートしているネットワーク情報を表すかの詳細な情報を教えます。 それはネットワーク隠れることについて説明して、デバイス隠れること、クラスタリングしているネットワーク・ナンバー再写像は検出、ホップカウント減少、ホップカウントの重さ、およびバックアップ道を輪にします。
The Appendix, "Implementation Details," provides information about
implementing AURP.
「実装の詳細」というAppendixはAURPを実装することの情報を提供します。
What You Need to Know
あなたが知る必要があること
This document is intended for developers of AppleTalk wide area routing products. It assumes familiarity with the AppleTalk network system, internet routing, and wide area networking terms and concepts.
このドキュメントはAppleTalkの広い領域ルーティング製品の開発者のために意図します。 それは用語と概念をネットワークでつなぐAppleTalkネットワークシステム、インターネットルーティング、および広い領域への親しみを仮定します。
Format of This RFC Document
このRFCドキュメントの形式
The text of this document has been quickly prepared for RFC format. However, the art is more complex and is not yet ready in this format. We plan to incorporate the art in the future. Consult the official APDA document, as indicated below, for the actual art.
このドキュメントの原本はRFC形式のためにすぐに準備されました。 しかしながら、芸術は、より複雑であり、この形式でまだ準備ができていません。 私たちは、将来芸術を取り入れるのを計画しています。 実際の芸術のために以下に示すように公式のAPDAドキュメントを参照してください。
For More Information
詳しい情報のために
The following manuals and books from Apple Computer provide additional information about AppleTalk networks. You can obtain books published by Addison-Wesley at your local bookstore. Contact APDA, Apple's source for developer tools, to obtain technical reference materials for developers:
アップル・コンピューターからの以下のマニュアルと本はAppleTalkネットワークに関する追加情報を提供します。 あなたは地元の書店でアディソン-ウエスリーによって発行された本を入手できます。 APDA、開発ツールのためのアップルのソースに連絡して、開発者のための技術的な参照の材料を得てください:
Oppenheimer [Page 2] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[2ページ]RFC1504Appletalk
APDA
Apple Computer, Inc.
20525 Mariani Avenue, M/S 33-G
Cupertino, CA 95014-6299
APDAアップル・コンピューター, Inc.20525マリアニAvenue、33-Gカルパチーノ、M/Sカリフォルニア95014-6299
These manuals provide information about some AppleTalk network products:
これらのマニュアルはいくつかのAppleTalkネットワーク製品の情報を提供します:
The Apple Ethernet NB User's Guide explains how to install and use
an Apple Ethernet NB Card and EtherTalk software on an AppleTalk
network.
アップルイーサネットネブラスカUserのガイドはAppleTalkネットワークでどのようにアップルイーサネットネブラスカCardとEtherTalkソフトウェアをインストールして、使用するかを説明します。
The Apple InteroPoll Network Administrator's Guide describes how
to perform maintenance and troubleshooting on an AppleTalk network
using InteroPoll, a network administrator's utility program.
アップルInteroPoll Network Administratorのガイドは、どうメインテナンスを実行するか、そして、InteroPoll(ネットワークアドミニストレータのユティリティプログラム)を使用するAppleTalkネットワークで障害調査すると説明します。
The Apple Internet Router Administrator's Guide explains how to
install the Apple Internet Router Basic Connectivity Package and
how to use the Router Manager application program. It provides
information about setting up the router, configuring ports to
create local area and wide area internets, monitoring and
troubleshooting router operation, and planning your internet.
アップルインターネットRouter AdministratorのガイドはどのようにアップルインターネットRouter Basic Connectivityパッケージをインストールするか、そして、どのようにRouterマネージャアプリケーション・プログラムを使用するかを説明します。 それはルータをセットアップすることの情報を提供します、局部と広い領域インターネットを作成するためにポートを構成して、ルータ操作をモニターして、障害調査して、あなたのインターネットを計画していて。
Using the AppleTalk/IP Wide Area Extension explains how to install
and use the AppleTalk/IP Wide Area Extension for the Apple Internet
Router. It provides information about tunneling through TCP/IP
networks, configuring an IP Tunnel access method for an Ethernet or
Token Ring port on the Apple Internet Router, troubleshooting IP
tunneling problems, and configuring MacTCP.
AppleTalk/IP Wide Area Extensionを使用するのに、アップルインターネットRouterにどのようにAppleTalk/IP Wide Area Extensionをインストールして、使用するかがわかります。 それはTCP/IPネットワークを通してトンネルを堀ることの情報を提供します、イーサネットのためのIP Tunnelアクセス法かアップルインターネットRouterの上のToken Ringポートを構成して、問題にトンネルを堀りながらIPを障害調査して、MacTCPを構成して。
The AppleTalk Remote Access User's Guide explains how to use a
Macintosh computer to communicate with another Macintosh computer
over standard telephone lines to access information and resources
at a remote location.
AppleTalk Remote Access Userのガイドは離れた場所で情報とリソースにアクセスするために標準の電話回線の上に別のマッキントッシュのコンピュータとコミュニケートするのにマッキントッシュのコンピュータを使用する方法を説明します。
The Apple Token Ring 4/16 NB Card User's Guide explains how to
install and operate the card and TokenTalk software on a Token Ring
network.
4/16ネブラスカCard Userのガイドがその方法を説明するアップルToken RingはToken RingネットワークのカードとTokenTalkソフトウェアをインストールして、操作します。
The MacTCP Administrator's Guide, version 1.1, explains how to
install and configure the MacTCP driver, which implements TCP/IP
(Transmission Control Protocol/Internet Protocol) on a Macintosh
computer.
MacTCP Administratorのガイド(バージョン1.1)はどのように、MacTCPドライバーをインストールして、構成するかを説明します。(そのドライバーは、マッキントッシュのコンピュータでTCP/IPが(伝送制御プロトコル/インターネット・プロトコル)であると実装します)。
Oppenheimer [Page 3] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[3ページ]RFC1504Appletalk
The following books provide reference information about AppleTalk networks:
以下の本はAppleTalkネットワークに関する参考情報を提供します:
The Advantages of AppleTalk Phase 2 provides a detailed
description of the enhanced internetworking capabilities of
AppleTalk Phase 2, and a brief guide to upgrading an AppleTalk
internet to AppleTalk Phase 2. Available from Apple Computer.
AppleTalk Phase2のAdvantagesはAppleTalk Phase2の高められたインターネットワーキング能力の詳述、およびAppleTalk Phase2にAppleTalkインターネットをアップグレードさせることへの簡潔なガイドを提供します。 アップル・コンピューターから、利用可能です。
The AppleTalk Network System Overview provides a technical
introduction to the AppleTalk network system and its protocol
architecture. Published by Addison-Wesley Publishing Company.
AppleTalkネットワークSystem OverviewはAppleTalkネットワークシステムとそのプロトコルアーキテクチャに技術的な序論を供給します。 アディソン-ウエスリー出版社によって発行されます。
The AppleTalk Phase 2 Introduction and Upgrade Guide is a detailed
guide to upgrading AppleTalk network hardware, drivers, and
application programs to AppleTalk Phase 2, and briefly describes
extensions to the AppleTalk network system that enhance its
support for large networks. Available from Apple Computer.
AppleTalk Phase2IntroductionとUpgradeガイドは、AppleTalkネットワークハードウェア、ドライバー、およびアプリケーション・プログラムをAppleTalk Phase2にアップグレードさせることへの詳細なガイドであり、簡潔に大きいネットワークのサポートを機能アップする拡大をAppleTalkネットワークシステムに説明します。 アップル・コンピューターから、利用可能です。
The AppleTalk Phase 2 Protocol Specification is an addendum to the
first edition of Inside AppleTalk that defines AppleTalk Phase 2
extensions to AppleTalk protocols that provide enhanced AppleTalk
addressing, routing, and naming services. Available from APDA.
AppleTalk Phase2プロトコルSpecificationはアドレシング、ルーティング、および名前付けサービスを高められたAppleTalkに提供するAppleTalkプロトコルとAppleTalk Phase2拡張子を定義するInside AppleTalkの初版への付加物です。 APDAから、利用可能です。
Inside AppleTalk, second edition, is a technical reference that
describes the AppleTalk protocols in detail and includes
information about AppleTalk Phase 2. Published by Addison-Wesley
Publishing Company.
内面のAppleTalk(第2版)は詳細にAppleTalkプロトコルについて説明して、AppleTalk Phase2の情報を含んでいる技術的な参照です。 アディソン-ウエスリー出版社によって発行されます。
The Local Area Network Cabling Guide provides information about
network media, topologies, and network types. Available from Apple
Computer.
ローカル・エリア・ネットワークCablingガイドはネットワークメディア、topologies、およびネットワークタイプの情報を提供します。 アップル・コンピューターから、利用可能です。
Planning and Managing AppleTalk Networks provides in-depth
information for network administrators about planning and managing
AppleTalk networks-including AppleTalk terms and concepts, and
information about network services, media, topologies, security,
monitoring and optimizing network performance, and
troubleshooting. Published by Addison-Wesley Publishing Company.
計画とManaging AppleTalkネットワークはネットワーク・サービスに関してAppleTalkネットワークを含むAppleTalk用語、概念、および情報を計画して、管理することに関してネットワーク管理者に詳細な情報を提供します、メディア、topologies、セキュリティ、ネットワーク性能、およびトラブルシューティングをモニターして、最適化して。 アディソン-ウエスリー出版社によって発行されます。
Understanding Computer Networks provides an overview of
networking-including basic information about protocol
architectures, network media, and topologies. Published by
Addison-Wesley Publishing Company.
コンピュータNetworksを理解していると、プロトコルアーキテクチャ、ネットワークメディア、およびtopologiesに関するネットワークを含む基本情報の概要は提供されます。 アディソン-ウエスリー出版社によって発行されます。
The AppleTalk Update-Based Routing Protocol Specification is the
official Apple specification of AURP. It includes the artwork
currently missing from this document. Available from APDA.
AppleTalkベースのUpdateルート設定プロトコルSpecificationはAURPの公式のアップル仕様です。 それは現在このドキュメントからなくなったアートワークを含んでいます。 APDAから、利用可能です。
Oppenheimer [Page 4] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[4ページ]RFC1504Appletalk
Table of Contents
目次
1. Introduction to the AppleTalk Update-Based Routing Protocol 6
Wide area routing enhancements provided by AURP 6
2. Wide Area AppleTalk Connectivity 7
AppleTalk tunneling 7
IP tunneling 14
Point-to-point tunneling 17
3. Propagating Routing Information With the AppleTalk Update-Based
Routing Protocol 18
AURP architectural model 18
Maintaining current routing information with AURP 20
AURP-Tr 21
One-way connections 22
Initial information exchange 22
Reobtaining routing information 28
Updating routing information 28
Processing update events 33
Router-down notification 38
Obtaining zone information 40
Hiding local networks from remote networks 44
AURP packet format 45
Error codes 55
4. Representing Wide Area Network Information 56
Network hiding 56
Device hiding 57
Resolving network-numbering conflicts 59
Zone-name management 65
Hop-count reduction 66
Routing loops 67
Using alternative paths 71
Network management 73
Appendix. Implementation Details 75
State diagrams 75
AURP table overflow 75
A scheme for updates following initial information exchange 75
Implementation effort for different components of AURP 76
Creating free-trade zones 77
Implementation details for clustering 78
Modified RTMP algorithms for a backup path 79
Security Considerations 82
Author's Address 82
1. AppleTalkへの序論はAURP6 2によって提供されたルート設定プロトコル6Wide領域ルーティング増進をUpdate基礎づけました。 14Pointからポイントの広いArea AppleTalk Connectivity7AppleTalkトンネリング7IPトンネリングトンネリング17 3。 経路情報Withを伝播する、AURP20AURP-Tr21One-道の接続22Initial情報交換22Reobtainingルーティング情報28Updatingルーティング28回の情報Processingアップデートイベント33下にRouter通知38Obtainingゾーン情報40Hidingが地方であることでのAppleTalkベースのUpdateルート設定プロトコル18のAURPの建築モデル18のMaintainingの現在のルーティング情報が44AURPパケット・フォーマット45Errorがコード化するリモートネットワークからのネットワークである55、4 57回のネットワークに付番するResolving闘争59を隠しながら56Deviceを隠すワイドエリアネットワーク情報56Networkを表して、67の管理のUsingの代替の減少66ルート設定が輪にする65Hop-カウント経路71Network管理を73AppendixとZone命名してください。 バックアップ経路79Security Considerations82AuthorのAddress82のための78のModified RTMPアルゴリズムをクラスタリングさせるためのAURP76Creating自由貿易圏77Implementationの詳細の異なった成分のための初期の情報交換75Implementation取り組みに続いて、実装Details75州はアップデートの75AURPテーブルオーバーフロー75A体系を図解します。
Oppenheimer [Page 5] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[5ページ]RFC1504Appletalk
1. INTRODUCTION TO THE APPLETALK UPDATE-BASED ROUTING PROTOCOL
1. APPLETALKのアップデートベースのルーティング・プロトコルへの序論
The AppleTalk Update-based Routing Protocol (AURP) provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. AURP consists of three major components:
AppleTalkのUpdateベースのルート設定プロトコル(AURP)は、広い領域ルーティング増進をAppleTalkルーティング・プロトコルに提供して、AppleTalk Phase2と完全に互換性があります。 AURPは3個の主要コンポーネントから成ります:
AppleTalk tunneling through foreign network systems-for example,
TCP/IP (Transmission Control Protocol/Internet Protocol) and over
point-to-point links
例えば、TCP/IP(伝送制御プロトコル/インターネット・プロトコル)とポイントツーポイント接続の上の外国ネットワークシステムを通してトンネルを堀るAppleTalk
the propagation of routing information between internet routers
connected through foreign network systems or over point-to-point
links
外国ネットワーク・システムを通して、または、ポイントツーポイント接続の上に接続されたインターネットルータの間のルーティング情報の伝播
the presentation of AppleTalk network information by an internet
router to nodes or to other Phase 2-compatible routers on its local
internet-in other words, on the AppleTalk internet connected
directly to the router
ノード、または、言い換えれば、地方のインターネット、直接ルータに関連づけられたAppleTalkインターネットに関する他のPhaseの2コンパチブルルータへのインターネットルータによるAppleTalkネットワーク情報のプレゼンテーション
Chapter 3, "Propagating Routing Information With the AppleTalk Update-Based Routing Protocol," describes the elements of AURP that are essential for a minimal implementation of AURP. AURP includes many optional features for the presentation of network information. You can implement many of these optional features on routers that use either AURP or RTMP (Routing Table Maintenance Protocol) for routing-information propagation.
「AppleTalkのアップデートベースのルーティング・プロトコルで経路情報を伝播し」て、第3章はAURPの最小限の器具に、不可欠のAURPの要素について説明します。 AURPはネットワーク情報のプレゼンテーションのための多くのオプション機能を含んでいます。 あなたはルーティング情報伝播のためにAURPかRTMPのどちらかを使用するルータ(ルート設定Table Maintenanceプロトコル)に関するこれらのオプション機能の多くを実装することができます。
Figure 1-1 shows how the three major components of AURP interact.
図1-1はAURPの3個の主要コンポーネントがどう相互作用するかを示しています。
<<Figure 1-1 Major components of AURP>>
<<数値1-1AURP>>のメージャーの部品
Wide Area Routing Enhancements Provided by AURP
AURPによって提供された広い領域ルート設定増進
AURP provides AppleTalk Phase 2-compatible routing for large wide area networks (WANs). Key wide area routing enhancements provided by AURP include:
AURPは大きい広域ネットワーク(WAN)のために2コンパチブルルーティングをAppleTalk Phaseに供給します。 AURPによって提供された主要な広い領域ルーティング増進は:
tunneling through TCP/IP internets and other foreign network
systems
TCP/IPインターネットと他の外国ネットワーク・システムを通してトンネルを堀ること。
point-to-point tunneling
二地点間トンネリング
basic security-including device hiding and network hiding
セキュリティを含む基本的なデバイス隠れることとネットワーク隠れること
remapping of remote network numbers to resolve numbering conflicts
付番闘争を解決するためにリモートネットワーク・ナンバーを再写像します。
Oppenheimer [Page 6] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[6ページ]RFC1504Appletalk
internet clustering to minimize routing traffic and routing-
information storage requirements
トラフィックを発送する最小にするインターネットクラスタリングとルーティング情報記憶要件
hop-count reduction to allow the creation of larger internets
improved use of alternate paths through hop-count weighting and
the designation of backup paths
代替パスのホップカウントの重さとバックアップ道の名称による改良された使用をより大きいインターネットの作成に許すホップカウント減少
2. WIDE AREA APPLETALK CONNECTIVITY
2. 広い領域APPLETALKの接続性
This chapter describes the wide area connectivity capabilities provided by the AppleTalk Update-based Routing Protocol (AURP), including:
本章はAppleTalkのUpdateベースのルート設定プロトコル(AURP)、包含で提供された広い領域接続性能力について説明します:
AppleTalk tunneling
AppleTalkトンネリング
tunneling through TCP/IP internets
TCP/IPインターネットを通してトンネルを堀ること。
tunneling over point-to-point links
ポイントツーポイント接続の上でトンネルを堀ること。
AppleTalk Tunneling
AppleTalkトンネリング
Tunneling allows a network administrator to connect two or more native internets through a foreign network system to form a large wide area network (WAN). For example, an AppleTalk WAN might consist of two or more native AppleTalk internets connected through a tunnel built on a TCP/IP internet. In such an AppleTalk WAN, native internets use AppleTalk protocols, while the foreign network system uses a different protocol family.
トンネリングで、ネットワーク管理者は、大きい広域ネットワーク(WAN)を形成するために外国ネットワーク・システムを通して2つ以上のネイティブのインターネットを接続できます。 例えば、AppleTalk WANはTCP/IPインターネットで建設されたトンネルを通って接続された2つ以上のネイティブのAppleTalkインターネットから成るかもしれません。 そのようなAppleTalk WANでは、ネイティブのインターネットはAppleTalkプロトコルを使用しますが、外国ネットワーク・システムは異なったプロトコルファミリーを使用します。
A tunnel connecting AppleTalk internets functions as a single, virtual data link between the internets. A tunnel can be either a foreign network system or a point-to-point link. Figure 2-1 shows an AppleTalk tunnel.
AppleTalkインターネットを接続するトンネルはインターネットの間の単一の、そして、仮想のデータ・リンクとして機能します。 トンネルは、外国ネットワーク・システムかポイントツーポイント接続のどちらかであるかもしれません。 図2-1はAppleTalkトンネルを示しています。
<<Figure 2-1 AppleTalk tunnel>>
<<数値2-1AppleTalkトンネル>>。
There are two types of tunnels:
2つのタイプのトンネルがあります:
dual-endpoint tunnels, which have only two routers on a tunnel-for
example, point-to-point tunnels
二元的な終点トンネル。(そのトンネルは例えば、トンネル、二地点間トンネルの上に2つのルータしか持っていません)。
multiple-endpoint tunnels-herein referred to as multipoint tunnels-
which have two or more routers on a tunnel
ここにトンネルの上に2つ以上のルータを持っている多点トンネルと呼ばれた複数の終点トンネル
AURP implements multipoint tunneling by providing mechanisms for data encapsulation and the propagation of routing information to specific routers.
AURPは、メカニズムをデータに提供するのによる多点トンネリングがルーティング情報のカプセル化と伝播であると特定のルータに実装します。
Oppenheimer [Page 7] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[7ページ]RFC1504Appletalk
Exterior Routers
外のルータ
An AppleTalk router with a port that connects an AppleTalk internet to a tunnel is an exterior router. An exterior router always sends split-horizoned routing information to the other exterior routers on a multipoint tunnel. That is, an exterior router on a multipoint tunnel sends routing information for only its local internet to other exterior routers on that tunnel. An exterior router never exports routing information obtained from other exterior routers on the tunnel, because the exterior routers communicate their own routing information to one another.
AppleTalkインターネットをトンネルに接続するポートがあるAppleTalkルータは外のルータです。 外のルータは多点トンネルでいつも分裂でhorizonedされたルーティング情報を他の外のルータに送ります。 すなわち、多点トンネルの上の外のルータはそのトンネルで地方のインターネットだけのためのルーティング情報を他の外のルータに送ります。 外のルータは、ルーティングがトンネルの上で他の外のルータから得られた情報であると決してエクスポートしません、外のルータがそれら自身のルーティング情報をお互いに伝えるので。
As shown in Figure 2-2, the absence or presence of redundant paths, or loops, across a tunnel changes the way an exterior router defines its local internet. For more information about redundant paths, see the section "Redundant Paths" in Chapter 4. If no loops exist across a tunnel, an exterior router's local internet comprises all networks connected directly or indirectly to other ports on the exterior router. When loops exist across a tunnel, an exterior router's local internet comprises only those networks for which the next internet router is not across a tunnel. Using this definition of a local internet, two exterior routers' local internets might overlap if loops existed across a tunnel. For more information about routing loops, see the section "Routing Loops" in Chapter 4.
図2-2に示されるように、冗長パス、または輪の不在か存在がトンネルの向こう側に外のルータが地方のインターネットを定義する方法を変えます。 冗長パスに関する詳しい情報に関しては、第4章の「冗長パス」というセクションを見てください。 輪が全くトンネルの向こう側に存在していないなら、外のルータの地方のインターネットは直接か間接的な外のルータの他のポートに接続されたすべてのネットワークを包括します。 輪がトンネルの向こう側に存在していると、外のルータの地方のインターネットは次のインターネットルータがトンネルのむこうにないそれらのネットワークだけを包括します。 地方のインターネットのこの定義を使用して、輪がトンネルの向こう側に存在しているなら、2つの外のルータの地方のインターネットは重なるでしょうに。 ルーティング輪に関する詳しい情報に関しては、第4章で「ルート設定輪」というセクションを見てください。
<<Figure 2-2 An exterior router's local internet>>
<<数値2-2An外部ルータの地方のインターネット>>。
An exterior router functions as an AppleTalk router within its local internet and as an end node in the foreign network system connecting AppleTalk internets. An exterior router uses RTMP to communicate routing information to its local internet, and uses AURP and the network-layer protocol of the tunnel's underlying foreign network system to communicate with other exterior routers connected to the tunnel. An exterior router encapsulates AppleTalk data packets using the headers required by the foreign network system, then forwards the packets to another exterior router connected to the tunnel.
外のルータは、地方のインターネットの中のAppleTalkルータとしてエンドノードとしてAppleTalkインターネットを接続しながら、外国ネットワーク・システムで機能します。 外のルータは、ルーティング情報を地方のインターネットに伝えるのにRTMPを使用して、トンネルに接続される他の外のルータで交信するのにAURPとトンネルの基本的な外国ネットワーク・システムのネットワーク層プロトコルを使用します。 外のルータは、AppleTalkがデータ・パケットであることを外国ネットワーク・システムによって必要とされたヘッダーを使用することでカプセルに入れって、次に、トンネルに接続された別の外のルータにパケットを送ります。
FORWARDING DATA: When forwarding AppleTalk data packets across a multipoint tunnel, an exterior router
推進データ: AppleTalkを進めるとき、多点の向こう側のデータ・パケットはトンネルを堀って、外部はルータです。
encapsulates the AppleTalk data packets in the packets of the
tunnel's underlying foreign network system by adding the headers
required by that network system
ヘッダーがそのネットワーク・システムが必要であると言い足すことによって、トンネルの基本的な外国ネットワーク・システムのパケットでAppleTalkがデータ・パケットであるとカプセル化します。
adds an AURP-specific header-called a domain header-immediately
preceding each AppleTalk data packet
それぞれのAppleTalkデータ・パケットに先行しながら、すぐにAURP特有のヘッダーによって電話をされたaドメインヘッダーを加えます。
Oppenheimer [Page 8] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[8ページ]RFC1504Appletalk
A domain header contains additional addressing information-including a source domain identifier and destination domain identifier. For more information about domain headers, see the sections "AppleTalk Data-Packet Format" and "AppleTalk Data-Packet Format for IP Tunneling" later in this chapter. For detailed information about domain identifiers, see the section "Domain Identifiers" later in this chapter.
ドメインヘッダーはソースドメイン識別子と目的地ドメイン識別子を情報で含む追加アドレシングを含んでいます。 後での本章のドメインヘッダーの周りでは、「AppleTalkデータ・パケット形式」というセクションを見てください。そうすれば、「AppleTalkデータ・パケットはIPのためにトンネリングをフォーマットする」という詳しい情報のために。 ドメイン識別子の詳細な情報に関しては、後で本章で「ドメイン識別子」というセクションを見てください。
Before forwarding a data packet to a network in another exterior router's local internet, an exterior router must obtain the foreign- protocol address of the exterior router that is the next internet router in the path to the packet's destination network. The exterior router then sends the packet to that exterior router's foreign- protocol address using the network-layer protocol of the foreign network system. The exterior router need not know anything further about how the packet traverses this virtual data link.
別の外のルータの地方のインターネットでデータ・パケットをネットワークに送る前に、外のルータは経路で次のインターネットルータである外のルータの外国プロトコルアドレスをパケットの送信先ネットワークとして得なければなりません。 そして、外のルータは、外国ネットワーク・システムのネットワーク層プロトコルを使用することでその外のルータの外国プロトコルアドレスにパケットを送ります。 外のルータは、より遠くにパケットがどうこの仮想データリンクを横断するかに関して何も知る必要はありません。
Once the destination exterior router receives the packet, it removes the headers required by the foreign network system and the domain header, then forwards the packet to its destination in the local AppleTalk internet.
一度、目的地の外のルータがパケットを受けて、それは、外国ネットワーク・システムとドメインヘッダーによって必要とされたヘッダーを移して、次に、地方のAppleTalkインターネットにおける目的地にパケットを送ります。
If the length of an AppleTalk data packet in bytes is greater than that of the data field of a foreign-protocol packet, a forwarding exterior router must fragment the AppleTalk data packet into multiple foreign-protocol packets, then forward these packets to their destination. Once the destination exterior router receives all of the fragments that make up the AppleTalk data packet, it reassembles the packet.
バイトで表現されるAppleTalkデータ・パケットの長さがデータ・フィールドのものより大きいなら、外国プロトコルパケット、外のルータがそうしなければならない推進では複数の外国プロトコルパケットにAppleTalkデータ・パケットを断片化してください、そして、次に、これらのパケットをそれらの目的地に送ってください。 目的地の外のルータがいったんAppleTalkデータ・パケットを作る断片のすべてを受けると、それはパケットを組み立て直します。
CONNECTING MULTIPLE TUNNELS TO AN EXTERIOR ROUTER: An exterior router can also connect two or more multipoint tunnels. As shown in Figure 2-3, when an exterior router connects more than one multipoint tunnel, the tunnels can be built on any of the following:
接続倍数は外のルータにトンネルを堀ります: また、外のルータは2つ以上の多点トンネルをつなげることができます。 図2-3に示されるように、外のルータが1つ以上の多点トンネルをつなげると、以下のどれかでトンネルを建設できます:
the same foreign network system
同じ外国ネットワーク・システム
different foreign network systems
異なった外国ネットワーク・システム
similar, but distinct foreign network systems
同様の、しかし、異なった外国ネットワーク・システム
<<Figure 2-3 Connecting multiple tunnels to an exterior router>>
<<数値2-3Connecting倍数は外のルータ>>にトンネルを堀ります。
Whether the tunnels connected to an exterior router are built on similar or different foreign network systems, each tunnel acts as an independent, virtual data link. As shown in Figure 2-4, an exterior router connected to multiple tunnels functions logically as though it were two or more exterior routers connected to the same AppleTalk
同様の、または、異なった外国ネットワーク・システムの上で建設されるか否かに関係なく、各トンネルは独立していて、仮想のデータ・リンクとして作動します。 図2-4に示されるように、複数のトンネルに接続された外のルータはまるでそれが同じAppleTalkに接続された2つ以上の外のルータであるかのように論理的に機能します。
Oppenheimer [Page 9] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[9ページ]RFC1504Appletalk
network, with each exterior router connected to a different tunnel.
それぞれの外のルータが異なったトンネルに接続される状態で、ネットワークでつなぎます。
<<Figure 2-4 An exterior router connected to multiple tunnels>>
<<数値2-4倍数に関連づけられたAnの外のルータは>>にトンネルを堀ります。
Fully Connected and Partially Connected Tunnels
完全に接続されて部分的に接続されたTunnels
An AppleTalk multipoint tunnel functions as a virtual data link. AURP assumes full connectivity across a multipoint tunnel-that is, all exterior routers on such a tunnel can communicate with one another. An exterior router always sends split-horizoned routing information to other exterior routers on a multipoint tunnel. That is, an exterior router on a multipoint tunnel sends routing information for only its local internet to other exterior routers on that tunnel. An exterior router never exports routing information obtained from other exterior routers on the tunnel, because exterior routers communicate their routing information to one another.
AppleTalk多点トンネルは仮想データリンクとして機能します。 AURPはそのようなトンネルの上のすなわち、すべてにトンネルを堀っている外のルータがお互いと伝えることができる多点の向こう側に完全な接続性を仮定します。 外のルータは多点トンネルでいつも分裂でhorizonedされたルーティング情報を他の外のルータに送ります。 すなわち、多点トンネルの上の外のルータはそのトンネルで地方のインターネットだけのためのルーティング情報を他の外のルータに送ります。 外のルータは、ルーティングがトンネルの上で他の外のルータから得られた情報であると決してエクスポートしません、外のルータがそれらのルーティング情報をお互いに伝えるので。
If all exterior routers connected to a multipoint tunnel are aware of and can send packets to one another, that tunnel is fully connected. If some of the exterior routers on a multipoint tunnel are not aware of one another, the tunnel is only partially connected. Figure 2-5 shows examples of a fully connected tunnel, a partially connected tunnel, and two fully connected tunnels.
多点トンネルに接続された外のルータが意識していて、お互いにパケット、そのトンネルを送ることができるすべてが完全に接続されるなら。 多点トンネルの上の外のルータのいくつかがお互いを意識していないなら、トンネルは部分的につなげられるだけです。 図2-5は、完全に接続されたトンネル、部分的に接続されたトンネル、および2に関する例がトンネルを完全につなげたのを示します。
<<Figure 2-5 Fully connected and partially connected tunnels>>
<<数値2-5接続されて、部分的に接続されたFullyは>>にトンネルを堀ります。
In the second example shown in Figure 2-5, the network administrator may have connected the tunnel partially for one of these reasons:
図2-5の2番目の例では、ネットワーク管理者はこれらの理由の1つによってトンネルを部分的につなげたかもしれません:
to prevent the local internets connected to exterior routers A and
C from communicating with one another, while providing full
connectivity between the local internets connected to exterior
router
外のルータAとCに関連づけられた地方のインターネットが外のルータに関連づけられた地方のインターネットの間に完全な接続性を提供している間、お互いにコミュニケートするのを防ぐために
B and the local internets connected to both exterior routers A and
C
Bと外のルータAとCの両方に接続された地方のインターネット
because local internets connected to exterior routers A and C need
access only to local internets connected to exterior router B-not
to each other's local internets
外のルータAとCに関連づけられた地方のインターネットが外のルータに関連づけられた地方のインターネットだけへのアクセスを必要とする、B、-、地元のインターネット
because exterior routers A and C-which should be aware of one
another-were misconfigured
そして、外のルータA、C、-、どれ、意識しているべきであるか、お互いである、-、misconfigured
Generally, an exterior router cannot determine whether a multipoint tunnel is fully connected or partially connected. In the second example in Figure 2-5, exterior router B does not know whether exterior routers A and C are aware of one another. However, exterior
一般に、外のルータは、多点トンネルが完全につなげられるか、または部分的につなげられるかを決定できません。 図2-5における2番目の例では、外のルータBは、外のルータAとCがお互いを意識しているかどうかを知りません。 しかしながら、外部
Oppenheimer [Page 10] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[10ページ]RFC1504Appletalk
router B must assume that the tunnel is fully connected, and that exterior routers A and C can exchange routing information. An exterior router should never forward routing information received from other exterior routers back across the tunnel. It should always send split-horizoned routing information to other exterior routers.
ルータBは、トンネルが完全につなげられて、外のルータAとCがルーティング情報を交換できると仮定しなければなりません。 外のルータはトンネルの向こう側に他の外のルータから受け取られたルーティング情報を決して転送するべきではありません。 それはいつも分裂でhorizonedされたルーティング情報を他の外のルータに送るべきです。
If connecting exterior routers A and C directly would be either expensive or slow, a network administrator could instead establish two independent multipoint tunnels-one connecting exterior routers A and B, another connecting exterior routers B and C-as shown in the third example in Figure 2-5. Exterior routers A and C could then establish connectivity by routing all data packets forwarded by one to the other through exterior router B.
そして、接続の外のルータAとCが直接高価であるか、または遅いなら、ネットワーク管理者は代わりに2の独立している多点トンネル-1つの接続の外のルータAとBを確立するかもしれません、別の接続の外のルータB、C、-、図2-5における3番目の例では、目立ちます。 そして、外のルータAとCはすべてのデータ・パケットが1時までに外のルータBを通してもう片方に送ったルーティングで接続性を確立するかもしれません。
Hiding Local Networks From Tunnels
Tunnelsから企業内情報通信網を隠します。
When configuring a tunneling port on an exterior router, a network administrator can provide network-level security to a network in the exterior router's local internet by hiding that network. Hiding a specific network in the exterior router's local internet prevents internets across a multipoint tunnel from becoming aware of the presence of that network. When the exterior router exchanges routing information with other exterior routers connected to the tunnel, it exports no information about any hidden networks to the exterior routers from which the networks are hidden.
外のルータのトンネリングポートを構成するとき、ネットワーク管理者は、外のルータの地方のインターネットでネットワークレベルセキュリティをネットワークにそのネットワークを隠すことによって、提供できます。 外のルータの地方のインターネットに特定のネットワークを隠すのは、多点トンネル中のインターネットがそのネットワークの存在を意識するようになるのを防ぎます。 外のルータがトンネルに接続された他の外のルータとルーティング情報を交換するとき、それはどんな隠されたネットワークの情報も全くネットワークが隠される外のルータにエクスポートしません。
An administrator can specify that certain networks in the exterior router's local internet be hidden from a specific exterior router connected to the tunnel or from all exterior routers on the tunnel.
管理者は、特定の外のルータトンネルの上に外のルータの地方のインターネットにおける、あるネットワークをトンネルかすべての外のルータから接続されていた状態で隠されると指定できます。
Nodes on the local internet of an exterior router from which a network is hidden cannot access that network. Neither the zones on a hidden network nor the names of devices in those zones appear in the Chooser on computers connected to such an internet. When a network is hidden, its nodes are also unable to access internets from which the network is hidden. If a node on a hidden network sends a packet across a tunnel to a node on an internet from which it is hidden, even if the packet arrives at its destination, the receiving node cannot respond. The exterior router connected to the receiving node's internet does not know the return path to the node on the hidden network. Thus, it appears to the node on the hidden network that the node to which it sent the packet is inaccessible.
ネットワークが隠される外のルータの地方のインターネットのノードはそのネットワークにアクセスできません。 隠されたネットワークのゾーンもそれらのゾーンのデバイスの名前もChooserにそのようなインターネットに接続されたコンピュータに現れません。 また、ネットワークが隠されるとき、ノードはネットワークが隠されるインターネットにアクセスできません。 隠されたネットワークのノードがそれが隠されるインターネットでトンネルの向こう側にパケットをノードに送るなら、パケットが目的地に到着しても、受信ノードは応じることができません。 受信ノードのインターネットに関連づけられた外のルータは隠されたネットワークのノードにリターンパスを知りません。 したがって、それがパケットを送ったノードがアクセスできないように隠されたネットワークのノードに見えます。
ADVANTAGES AND DISADVANTAGES OF NETWORK HIDING: Network hiding provides the following advantages:
ネットワーク隠れることの利点と損失: ネットワーク隠れることは以下の利点を提供します:
On large, global WANs, a network administrator can configure
network-level security for an organization's internets.
大きくて、グローバルなWANでは、ネットワーク管理者は組織のインターネットのためにネットワークレベルセキュリティを構成できます。
Oppenheimer [Page 11] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[11ページ]RFC1504Appletalk
It reduces the amount of network traffic across both a tunnel and
the internets connected to that tunnel.
それはそのトンネルに接続されたトンネルとインターネットの両方の向こう側にネットワークトラフィックの量を減少させます。
Network hiding has the following disadvantages:
ネットワーク隠れることには、以下の損失があります:
Nodes on hidden networks have limited access to internets across a
tunnel.
隠されたネットワークのノードはトンネルの向こう側にアクセスをインターネットに制限しました。
AppleTalk networking software running on a node on a hidden network
lists all of the AppleTalk zone names exported by exterior routers
connected to a tunnel, but may list the names of only some or none
of the devices in those zones. It cannot list the names of devices
that are unable to respond to Name Binding Protocol (NBP) lookups
originating from a node on a hidden network.
隠されたネットワークをノードで動きながらソフトウェアをネットワークでつなぐAppleTalkは、トンネルに接続された外のルータによってエクスポートされたAppleTalkゾーン名のすべてを記載しますが、それらのゾーンにいくつかだけの名前かデバイスのいずれも記載しないかもしれません。 それはノードから発するName Bindingプロトコル(NBP)ルックアップに応じることができないデバイスの名前を隠されたネットワークに記載できません。
Domain Identifiers
ドメイン識別子
Exterior routers assign a unique domain identifier to each AppleTalk internet, or domain. Domain identifiers enable exterior routers on a multipoint tunnel to distinguish individual AppleTalk internets in a wide area internet from one another.
外のルータは各AppleTalkインターネット、またはドメインにユニークなドメイン識別子を割り当てます。 ドメイン識別子は、多点トンネルの上の外のルータがお互いと広い領域インターネットにおける個々のAppleTalkインターネットを区別するのを可能にします。
The definition of an AppleTalk domain identifier is extensible to allow for future use when many additional types of AppleTalk tunnels and tunneling topologies may exist:
多くの追加タイプについてAppleTalkトンネルとtopologiesにトンネルを堀るのが存在するとき、AppleTalkドメイン識別子の定義は今後の使用を考慮するのにおいて広げることができます:
Under the current version of AURP, each exterior router connected
to a multipoint tunnel assigns a domain identifier to its local
AppleTalk internet that uniquely identifies that internet on the
tunnel. If redundant paths connect an AppleTalk internet through
more than one exterior router on a tunnel, each exterior router can
assign a different domain identifier to that internet, or AppleTalk
domain, as shown in Figure 2-6.
AURPの最新版の下では、多点トンネルに接続されたそれぞれの外のルータはトンネルの上で唯一そのインターネットを特定する地方のAppleTalkインターネットにドメイン識別子を割り当てます。 冗長パスがトンネルの上の1つ以上の外のルータを通してAppleTalkインターネットを接続するなら、それぞれの外のルータはそのインターネット、またはAppleTalkドメインに異なったドメイン識別子を割り当てることができます、図2-6に示されるように。
Under future routing protocols, a domain identifier will define the
boundaries of an AppleTalk domain globally-for all exterior
routers. Thus, a domain identifier will be unique among all
domains in a wide area internet. All exterior routers within a wide
area internet will use the same domain identifier for a given
AppleTalk internet, as shown in Figure 2-6.
将来のルーティング・プロトコル、識別子が境界線をはっきりさせるドメインの下、AppleTalkドメイン、グローバルである、-、すべての外のルータ。 したがって、ドメイン識別子は広い領域インターネットにおけるすべてのドメインの中でユニークになるでしょう。 広い領域インターネットの中のすべての外のルータが与えられたAppleTalkインターネットに同じドメイン識別子を使用するでしょう、図2-6に示されるように。
<<Figure 2-6 Domain identifiers>>
<<数値2-6Domain識別子>>。
To simplify an exterior router's port configuration, a parameter that is already administrated-such as a node address-can serve as the basis for an exterior router's domain identifier.
外のルータのポート構成、既にそうであるパラメタを簡素化する、そのようなものが管理される、外のルータのドメイン識別子の基礎としてのノードアドレス缶のサーブ。
Oppenheimer [Page 12] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[12ページ]RFC1504Appletalk
GENERAL DOMAIN-IDENTIFIER FORMAT: Figure 2-7 shows the general form of a domain identifier.
一般的なドメイン識別子形式: 図2-7はドメイン識別子の一般的な書式を示しています。
<<Figure 2-7 General domain-identifier format>>
<<数値2-7一般ドメイン識別子形式>>。
The general domain identifier (DI) consists of the following fields:
一般的なドメイン識別子(DI)は以下の分野から成ります:
Length: Byte 1 represents the length of the DI in bytes, not including the length byte. A DI must consist of an even number of bytes. Thus, the length byte is always an odd-numbered byte. The length field permits tunneling through foreign network systems that have addresses of any length-including the long addresses characteristic of X.25 and OSI. The value of the length byte varies, depending on the format of the DI.
長さ: バイト1は長さのバイトを含んでいるのではなく、バイトで表現されるDIの長さを表します。 DIはバイトの偶数から成らなければなりません。 したがって、いつも長さのバイトは変に番号付のバイトです。 長さの分野は、X.25とOSIの長さが扱うどんな長さ包含特性のアドレスも持っている外国ネットワーク・システムを通してトンネルを堀ることを許可します。 DIの形式によって、長さのバイトの値は異なります。
Authority: Byte 2 indicates the authority that administrates the identifier bytes of the DI. At present, Apple has defined only two authority-byte values:
権威: バイト2はDIの識別子バイトを管理する権威を示します。 現在のところ、アップルは2つの権威バイト値だけを定義しました:
$01-indicates that the subsequent bytes correspond to a unique,
centrally administrated IP address
その後のバイトがa特有に対応するのを示している、中心で管理された01IPが扱う$
$00-the null DI-indicates that no additional bytes follow
-00ドルに、ヌルは、どんな追加バイトも続かないのをDI示します。
All other authority-byte values are reserved and should not be used.
他のすべての権威バイト値を予約されていて、使用するべきであるというわけではありません。
Identifier: The identifier field starts at byte 3 and consists of a variable number of bytes of the type indicated by the authority byte.
識別子: 識別子分野は、バイト3で始まって、権威バイトによって示されたタイプの可変数のバイトから成ります。
NULL DOMAIN-IDENTIFIER FORMAT: The use of a null domain identifier is appropriate only when there is no need to distinguish the domains connected to a tunnel-for example, where a tunnel exists within a single internet-or for a point-to-point link. Figure 2-8 shows the null form of a domain identifier.
ヌルドメイン識別子形式: または、例えば、トンネルがシングルの中に存在するトンネルに接続されたドメインを区別する必要は全くないときだけ、ヌルドメイン識別子の使用が適切である、インターネット、-、ポイントツーポイント接続に。 図2-8はドメイン識別子のヌル書式を示しています。
<<Figure 2-8 Null domain-identifier format>>
<<数値2-8Nullドメイン識別子形式>>。
A null domain identifier consists of the following bytes:
ヌルドメイン識別子は以下のバイトから成ります:
Length: Byte 1 contains the value $01, defining the length of the null DI as one byte.
長さ: ヌルDIの長さを1バイトと定義して、バイト1は値を01ドル含んでいます。
Authority: Byte 2 contains the value $00, indicating a null DI.
権威: ヌルDIを示して、バイト2は値を00ドル含んでいます。
AppleTalk Data-Packet Format
AppleTalkデータ・パケット形式
Part of the format of an AppleTalk data packet sent across a multipoint tunnel or a point-to-point link depends on the underlying
多点トンネルかポイントツーポイント接続の向こう側に送られたAppleTalkデータ・パケットの形式の一部が基本的さによります。
Oppenheimer [Page 13] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[13ページ]RFC1504Appletalk
foreign network system. The headers required by a foreign-network protocol always precede an AppleTalk data packet sent across a multipoint tunnel. A domain header generally immediately precedes the AppleTalk data packet. Figure 2-9 shows the format of an AppleTalk data packet preceded by a domain header.
外国ネットワーク・システム。 外国ネットワーク・プロトコルによって必要とされたヘッダーはいつも多点トンネルの向こう側に送られたAppleTalkデータ・パケットに先行します。 一般に、ドメインヘッダーはすぐに、AppleTalkデータ・パケットに先行します。 図2-9は、データ・パケットがドメインヘッダーで先行したのをAppleTalkの形式に示します。
<<Figure 2-9 AppleTalk data-packet format with a domain header>>
<<数値2-9AppleTalkデータ・パケットはドメインヘッダーと共に>>をフォーマットします。
A domain header consists of the following fields:
ドメインヘッダーは以下の分野から成ります:
Destination DI: The length of the destination DI field in bytes depends on the type of DI.
目的地ディ: バイトで表現される目的地DI分野の長さはDIのタイプに頼っています。
Source DI: The length of the source DI field in bytes depends on the type of DI.
ソースディ: バイトで表現されるソースDI分野の長さはDIのタイプに頼っています。
Version number: The version number field is two bytes in length and currently contains the value 0001.
バージョン番号: バージョンナンバーフィールドは、長さ2バイトであり、現在、値0001を含みます。
Reserved: The two-byte field that follows the version number field is reserved for future use and is set to 0000.
予約される: バージョンナンバーフィールドに続く2バイトの分野は、今後の使用のために予約されて、0000に設定されます。
Packet type: The two-byte packet type field contains the value 0002 to identify the data that follows as AppleTalk data-distinguishing it from other data, such as routing data. In the future, Apple may define other values for this field.
パケットタイプ: 2バイトのパケットタイプ分野が従うデータがAppleTalkデータ区別であると認識するために値0002を含んでいる、それ、ルーティングデータなどの他のデータから。 将来、アップルは他の値をこの分野と定義するかもしれません。
An AppleTalk data packet does not require a domain header if
AppleTalkデータ・パケットはドメインヘッダーを必要としません。
it is sent across a multipoint tunnel or point-to-point link that
provides separate channels for data and routing packets
データとルーティングパケットに別々のチャンネルを提供する多点トンネルかポイントツーポイント接続の向こう側にそれを送ります。
the domain header's destination DI and source DI fields would both
contain null DIs
ドメインヘッダーの目的地DIとソースDI分野はともにヌルDIsを含んでいるでしょう。
Omitting a domain header reduces overhead associated with the exchange of routing information, without any loss of routing information. Figure 2-10 shows the format of an AppleTalk data packet without a domain header.
ドメインヘッダーを省略すると、ルーティング情報の少しも損失なしでルーティング情報の交換に関連しているオーバーヘッドは下げられます。 図2-10はドメインヘッダーなしでAppleTalkデータ・パケットの書式を示しています。
<<Figure 2-10 AppleTalk data-packet format without a domain header>>
<<数値2-10AppleTalkデータ・パケットはドメインヘッダーなしで>>をフォーマットします。
IP Tunneling
IPトンネリング
The Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite is a widely used communications standard that provides interoperability among computers from various vendors, including Apple, IBM, Digital Equipment Corporation, Sun, and Hewlett-Packard.
伝送制御プロトコル/インターネット・プロトコル(TCP/IP)プロトコル群は相互運用性を様々なベンダーからコンピュータに供給する広く使用されたコミュニケーション規格です、アップル、IBM、ディジタルイクイップメント社、Sun、およびヒューレット・パッカードを含んでいて。
Oppenheimer [Page 14] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[14ページ]RFC1504Appletalk
Descriptions of three of the most important TCP/IP protocols follow:
3つの最も重要なTCP/IPプロトコルの記述は続きます:
The Transmission Control Protocol (TCP) is a transport-layer
protocol that provides reliable data transmission between
processes-that is, between programs that communicate with one
another. This connection-oriented, byte-stream protocol ensures
error-free, sequential data delivery, without loss or duplication.
通信制御プロトコル(TCP)はお互いにコミュニケートするすなわち、間のプロセスプログラムの間に確実な資料送信を供給するトランスポート層プロトコルです。 この接続指向のバイト・ストリームプロトコルは損失も複製なしでエラーのなくて、連続したデータ配送を確実にします。
The User Datagram Protocol (UDP) is a transport-layer protocol
that provides best-effort, low-overhead interprocess data
transmission. This datagram-oriented protocol allows higher-layer
protocols that do not require reliability to transmit data without
incurring the overhead associated with TCP. UDP does no error
checking, does not acknowledge its successful receipt of data,
and does not sequence incoming messages. UDP messages may be lost,
duplicated, or improperly sequenced.
ユーザー・データグラム・プロトコル(UDP)はベストエフォート型の、そして、低いオーバーヘッドのインタプロセスデータ伝送を提供するトランスポート層プロトコルです。 このデータグラム指向のプロトコルで、TCPに関連しているオーバーヘッドを被らないで、信頼性を必要としない上位層プロトコルはデータを送ることができます。 UDPは誤りが全くチェックしないで、して、データのうまくいっている領収書を受け取ったことを知らせないで、またどんな系列にも入力メッセージはしません。 UDPメッセージは、失われているか、コピーされるか、または不適切に配列されるかもしれません。
The Internet Protocol (IP) is a network-layer protocol that
provides connectionless, best-effort datagram delivery across
multiple networks. Each host on a TCP/IP network has a unique,
centrally administrated internet address, called an IP address,
that identifies the node. The header of an IP datagram contains its
source and destination IP addresses, allowing any host to route a
datagram to its destination. TCP/IP provides connectivity between
many different network types that use data frames of various sizes.
Therefore, IP can fragment a datagram before sending it across an
internet. Datagram fragments can fit into data frames of any size.
Once all of a datagram's fragments reach their destination, IP
reassembles the datagram.
インターネットプロトコル(IP)は複数のネットワークの向こう側にコネクションレスで、ベストエフォート型のデータグラム配信を提供するネットワーク層プロトコルです。 TCP/IPネットワークの各ホストには、ノードを特定するIPアドレスと呼ばれるユニークで、中心で管理されたインターネットアドレスがあります。 IPデータグラムのヘッダーはソースと送付先IPアドレスを含んでいます、どんなホストもデータグラムを目的地に発送するのを許容して。 TCP/IPは様々なサイズのデータフレームを使用する多くの異なったネットワークタイプの間に接続性を提供します。 したがって、インターネットの向こう側にそれを送る前に、IPはデータグラムを断片化できます。 データグラム・フラグメントはどんなサイズのデータフレームにも収まることができます。 データグラムの断片のすべてがいったん目的地に到着すると、IPはデータグラムを組み立て直します。
Protocols in higher layers pass data to TCP or UDP for delivery to peer processes. TCP and UDP encapsulate the data in segments, using the appropriate headers, then pass the segments to IP. IP further encapsulates the data in IP datagrams, determines each datagram's path to its destination, and sends the datagrams across the internet.
より高い層のプロトコルは配送のためにTCPかUDPへのデータを同輩プロセスに通過します。 TCPとUDPは適切なヘッダーを使用して、セグメントでデータをカプセル化して、次に、セグメントをIPに通過します。 IPはIPデータグラムでさらにデータをカプセル化して、各データグラムの経路を目的地に決定して、インターネットの向こう側にデータグラムを送ります。
Figure 2-11 shows how the TCP/IP family of protocols conforms to the Open Systems Interconnection (OSI) model.
図2-11はプロトコルのTCP/IPファミリーがどうオープン・システム・インターコネクション(OSI)モデルに従うかを示しています。
<<Figure 2-11 TCP/IP protocol stack and the OSI model>>
<<数値2-11TCP/IPプロトコル・スタックとOSIモデル>>。
Exterior routers that connect AppleTalk internets through a TCP/IP tunnel are configured as nodes on both an AppleTalk internet and on the TCP/IP internet. Thus, an exterior router on a TCP/IP tunnel is also an IP end node in the TCP/IP network system. Exterior routers use the TCP/IP internet only to exchange AppleTalk routing information and AppleTalk data packets with one another. An exterior router encapsulates AppleTalk data packets in IP datagrams before
TCP/IPトンネルを通ってAppleTalkインターネットを接続する外のルータがAppleTalkインターネットとTCP/IPインターネットの両方のノードとして構成されます。 したがって、また、TCP/IPトンネルの上の外のルータはTCP/IPネットワーク・システムのIPエンドノードです。 外のルータはTCP/IPインターネットを使用しますが、お互いと共にAppleTalkルーティング情報とAppleTalkデータ・パケットを交換します。 外のルータは、以前、IPデータグラムでAppleTalkがデータ・パケットであるとカプセル化します。
Oppenheimer [Page 15] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[15ページ]RFC1504Appletalk
sending them across the TCP/IP internet to a forwarding exterior router, which decapsulates the packets, then forwards them to their destination AppleTalk networks.
そして、TCP/IPインターネットの向こう側に推進の外のルータにそれらを送ると、自己の目的地AppleTalkネットワークにそれらを送ります。(ルータはパケットをdecapsulatesします)。
IP Domain-Identifier Format
IPドメイン識別子形式
Under the current version of AURP, exterior routers on IP tunnels must use domain identifiers that are based on IP addresses. An exterior router on an IP tunnel derives its domain identifier from its IP address. Thus, a network administrator does not need to configure an exterior router's domain identifier. Figure 2-12 shows the IP form of a domain identifier.
AURPの最新版の下では、IPトンネルの上の外のルータはIPアドレスに基づいているドメイン識別子を使用しなければなりません。 IPトンネルの上の外のルータがドメイン識別子にIPアドレスに由来しています。 したがって、ネットワーク管理者は外のルータのドメイン識別子を構成する必要はありません。 図2-12はドメイン識別子のIP書式を示しています。
<<Figure 2-12 IP domain-identifier format>>
<<数値2-12IPドメイン識別子形式>>。
An IP domain identifier consists of the following fields:
IPドメイン識別子は以下の分野から成ります:
Length: Byte 1 contains the value $07, defining the length of the IP DI as seven bytes.
長さ: IP DIの長さを7バイトと定義して、バイト1は値を07ドル含んでいます。
Authority: Byte 2 contains the value $01, indicating that the remainder of the DI is based on an IP address.
権威: DIの残りがIPアドレスに基づいているのを示して、バイト2は値を01ドル含んでいます。
Distinguisher: Bytes 3 and 4 are reserved for future use and are set to 0 ($00).
Distinguisher: バイト3と4は、今後の使用のために予約されて、0(00ドル)に設定されます。
IP address: Bytes 5 through 8 contain the four-byte IP address of either the sending or the receiving exterior router.
IPアドレス: バイト5〜8は送付か受信の外のルータのどちらかの4バイトのIPアドレスを含んでいます。
NOTE: Future versions of AURP will allow exterior routers to usealternative formats for domain identifiers, even on IP tunnels.
以下に注意してください。 AURPの将来のバージョンはドメイン識別子と、IPトンネルの上にさえusealternative形式に外のルータを許容するでしょう。
AppleTalk Data-Packet Format for IP Tunneling
IPトンネリングのためのAppleTalkデータ・パケット形式
The following protocol headers precede an AppleTalk data packet that is forwarded across an IP tunnel by an exterior router:
以下のプロトコルヘッダーはIPトンネルの向こう側に外のルータによって進められるAppleTalkデータ・パケットに先行します:
a data-link header
データ・リンクヘッダー
an IP header
IPヘッダー
a User Datagram Protocol (UDP) header
ユーザー・データグラム・プロトコル(UDP)ヘッダー
a domain header
ドメインヘッダー
An exterior router encapsulates AppleTalk data packets in UDP packets when forwarding them through its UDP port 387, across an IP tunnel, to UDP port 387 on another exterior router. When encapsulating data
UDPポート387を通してそれらを進めるとき、外のルータはUDPパケットでAppleTalkデータ・パケットをカプセルに入れります、IPトンネルの向こう側に、別の外のルータのUDPポート387に。 データをカプセル化します。
Oppenheimer [Page 16] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[16ページ]RFC1504Appletalk
packets, an exterior router should always use UDP checksums. When a destination exterior router receives the UDP packets at UDP port 387, it decapsulates the packets.
パケット、外のルータはいつもUDPチェックサムを使用するべきです。目的地の外のルータがUDPポート387でUDPパケットを受けるとき、それはパケットをdecapsulatesします。
A domain header consists of the following fields:
ドメインヘッダーは以下の分野から成ります:
Destination DI: This field contains the DI of the exterior router to which a packet is being forwarded.
目的地ディ: この分野はパケットが送られている外のルータのDIを含んでいます。
Source DI: This field contains the DI of the exterior router that is forwarding a packet.
ソースディ: この分野はパケットを進めている外のルータのDIを含んでいます。
Version number: The version number field is two bytes in length and currently contains the value 0001.
バージョン番号: バージョンナンバーフィールドは、長さ2バイトであり、現在、値0001を含みます。
Reserved: The two-byte field that follows the version number field is reserved for future use and is set to 0000.
予約される: バージョンナンバーフィールドに続く2バイトの分野は、今後の使用のために予約されて、0000に設定されます。
Packet type: The two-byte packet type field contains the value 0002 to identify the data that follows as AppleTalk data-distinguishing it from other data, such as routing data.
パケットタイプ: 2バイトのパケットタイプ分野が従うデータがAppleTalkデータ区別であると認識するために値0002を含んでいる、それ、ルーティングデータなどの他のデータから。
An AppleTalk data packet consists of a domain header and AppleTalk data. Figure 2-13 shows the format of an AppleTalk data packet forwarded across an IP tunnel.
AppleTalkデータ・パケットはドメインヘッダーとAppleTalkデータから成ります。 図2-13はIPトンネルの向こう側に進められたAppleTalkデータ・パケットの書式を示しています。
<<Figure 2-13 AppleTalk data packet forwarded across an IP tunnel>>
<<数値2-13IPトンネル>>の向こう側に進められたAppleTalkデータ・パケット
Point-to-Point Tunneling
二地点間トンネリング
In point-to-point tunneling, two remote AppleTalk local area networks (LANs) connected to half-routers communicate with one another over a point-to-point link. A point-to-point link may consist of modems communicating over a standard telephone line or a leased line, such as a T1 line. Figure 2-14 shows an example of point-to-point tunneling.
指すポイントのトンネリング、半分ルータに接続された2つのリモートAppleTalkローカル・エリア・ネットワーク(LAN)が二地点間リンクの上にお互いにコミュニケートします。 ポイントツーポイント接続は標準の電話回線か専用線の上に交信するモデムから成るかもしれません、T1系列のように。 図2-14は、ポイントツーポイントに関する例がトンネルを堀るのを示します。
<<Figure 2-14 Point-to-point tunneling>>
<<数値2-14Pointからポイントへのトンネリング>>。
Generally, exterior routers use null domain identifiers on point-to- point links, because there is no IP address to be administrated and the opposite end of the tunnel is already uniquely identified. However, an exterior router may use other domain-identifier formats.
一般に、外のルータはポイントからポイントへのリンクに関するヌルドメイン識別子を使用します、管理されるためにIPアドレスが全くなくて、トンネルの反対端が既に唯一特定されるので。 しかしながら、外のルータは他のドメイン識別子形式を使用するかもしれません。
Point-to-Point Protocol
二地点間プロトコル
The Point-to-Point Protocol (PPP) is a data-link-layer protocol that provides a standard method of encapsulating and decapsulating
Pointからポイントへのプロトコル(PPP)は要約とdecapsulatingの標準方法を提供するデータリンク層プロトコルです。
Oppenheimer [Page 17] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[17ページ]RFC1504Appletalk
network-layer protocol information, and transmitting that information over point-to-point links. PPP includes an extensible Link Control Protocol (LCP) and a suite of Network Control Protocols (NCPs) that configure, enable, and disable various network-layer protocols.
ネットワーク層プロトコル情報と、その情報をポイントツーポイント接続の上に伝えること。 PPPは様々なネットワーク層プロトコルを構成して、可能にして、無効にする広げることができるLink Controlプロトコル(LCP)とひとそろいのNetwork Controlプロトコル(NCP)を含んでいます。
The AppleTalk Control Protocol (ATCP) is a PPP NCP for AppleTalk protocols. ATCP configures, enables, and disables the AppleTalk network-layer protocol DDP on the half-router at each end of a point-to-point link. ATCP also specifies the protocol that a half- router uses to propagate routing information-for example, AURP. When using AURP for routing-information propagation, a half-router uses a specific PPP protocol type to identify AURP routing-information packets-that is, packets preceded by a domain header. PPP provides separate channels for AppleTalk data packets and AppleTalk routing- information packets. Thus, a half-router can use DDP encapsulation to send AppleTalk data packets without including their domain headers. When using AURP, a half-router should accept both AppleTalk data packets that are preceded by domain headers and DDP-encapsulated packets.
AppleTalk Controlプロトコル(ATCP)はAppleTalkプロトコルのためのPPP NCPです。 ATCPは、ポイントツーポイント接続の各端の半分ルータでAppleTalkネットワーク層がプロトコルDDPであると構成して、可能にして、無効にします。 AURP、また、ATCPは半分ルータが例えばルーティング情報を伝播するのに使用するプロトコルを指定します。 ルーティング情報伝播にAURPを使用するとき、半分ルータは、ドメインヘッダーによって先行されて、情報パケットを発送して、それがそうです、パケットでAURPを特定するのに特定のPPPプロトコルタイプを使用します。 PPPはAppleTalkのための別々のチャンネルにデータ・パケットを提供して、AppleTalkルーティングに情報パケットを提供します。 したがって、半分ルータは、彼らのドメインヘッダーを含んでいなくてAppleTalkデータ・パケットを送るのにDDPカプセル化を使用できます。 AURPを使用するとき、半分ルータはドメインヘッダーによって先行されているAppleTalkデータ・パケットとDDPでカプセル化されたパケットの両方を受け入れるべきです。
NOTE: The Request for Comments (RFC) 1378, "The PPP AppleTalk Control Protocol (ATCP)," provides a detailed specification of ATCP, as well as information about using PPP to send AppleTalk data.
以下に注意してください。 Comments(RFC)1378のための「ppp AppleTalk制御プロトコル(ATCP)」というRequestはATCPの仕様詳細を提供します、AppleTalkデータを送るのにPPPを使用することの情報と同様に。
3. PROPAGATING ROUTING INFORMATION WITH THE APPLETALK UPDATE-BASED
ROUTING PROTOCOL
3. APPLETALKのアップデートベースのルーティング・プロトコルで経路情報を伝播します。
This chapter describes the required elements of AURP. It provides detailed information about using the AppleTalk Update-based Routing Protocol (AURP) to propagate routing information between AppleTalk exterior routers connected through a foreign network or over a point-to-point link, and includes information about
本章はAURPの必要な要素について説明します。 それはAppleTalkの外のルータの間のルーティング情報が外国ネットワークを通して、または、ポイントツーポイント接続の上で接続して、情報を含む伝播するAppleTalkのUpdateベースのルート設定プロトコル(AURP)を使用することの詳細な情報を提供します。
the AURP architectural model
AURPの建築モデル
one-way connections
一方向接続
exchanging routing information
ルーティング情報を交換します。
updating routing information
ルーティング情報をアップデートします。
notifying other exterior routers that an exterior router is going
down
外のルータが落ちているように他の外のルータに通知します。
obtaining zone information
ゾーン情報を得ます。
packet formats
パケット・フォーマット
Oppenheimer [Page 18] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[18ページ]RFC1504Appletalk
error codes
エラーコード
AURP Architectural Model
AURPの建築モデル
AURP provides the functionality of the Routing Table Maintenance Protocol (RTMP) and the Zone Information Protocol (ZIP) while eliminating most of the routing traffic generated by these protocols. Figure 3-1 shows the architectural model for AURP.
AURPはこれらのプロトコルによって生成されたルーティングトラフィックの大部分を排除している間、ルート設定Table Maintenanceプロトコル(RTMP)とZone情報プロトコル(ZIP)の機能性を提供します。 図3-1はAURPのために建築モデルを示しています。
<<Figure 3-1 AURP architectural model>>
<<数値3-1AURPの建築モデル>>。
Generally, an AppleTalk router uses RTMP and ZIP to maintain routing information, and sends RTMP data packets, ZIP Queries, and ZIP Replies out its ports. However, if one of the router's ports is connected to an AppleTalk tunnel, the architectural model for the router's central routing module becomes more complex. Logically, the central routing module in an exterior router communicates RTMP and ZIP information to an RTMP/ZIP-to-AURP conversion module, which sends AURP data packets out the tunneling port.
一般に、AppleTalkルータは、ルーティング情報を保守するのにRTMPとZIPを使用して、ポートからRTMPデータ・パケット、ZIP Queries、およびZIP Repliesを送ります。 しかしながら、ルータのポートの1つがAppleTalkトンネルに接続されるなら、ルータの主要なルーティングモジュールのための建築モデルは、より複雑になります。 論理的に、外のルータにおける主要なルーティングモジュールはRTMP/ZIPからAURPへの変換モジュールにRTMPとZIP情報を伝えます。(それは、データ・パケットをトンネリングポートからAURPに送ります)。
RTMP/ZIP-to-AURP Conversion Module
ファスナからRTMP/AURPへの変換モジュール
The RTMP/ZIP-to-AURP conversion module maintains split-horizoned routing-table information and network number-to-zone name mappings for each exterior router on the tunnel-that is, a copy of the routing information for each exterior router's local internet. Figure 3-2 shows the architectural components of the RTMP/ZIP-to-AURP conversion module.
RTMP/ZIPからAURPへの変換モジュールはそれぞれの外のルータの地方のインターネットのためのルーティング情報のすなわち、aにトンネルを堀っているコピーの上のそれぞれの外のルータのための分裂でhorizonedされた経路指定テーブル情報とネットワーク番号からゾーンへの名前マッピングを保守します。 図3-2はRTMP/ZIPからAURPへの変換モジュールの建築構成を示しています。
<<Figure 3-2 RTMP/ZIP-to-AURP conversion module architecture>>
<<数値3-2RTMP/ZIPからAURPへの変換モジュールアーキテクチャ>>。
The AURP module of the conversion module obtains routing information from the other exterior routers on the tunnel, then periodically updates the routing-table information and the mappings in the conversion module. The RTMP module passes this routing-table information to the exterior router's central routing module. Logically, the RTMP module generates an RTMP data packet for each exterior router on the tunnel every ten seconds-the RTMP retransmission time-then passes the packet to the central routing module.
変換モジュールのAURPモジュールは、トンネルの上で他の外のルータからルーティング情報を得て、次に、定期的に経路指定テーブル情報と変換モジュールによるマッピングをアップデートします。 RTMPモジュールは外のルータの主要なルーティングモジュールにこの経路指定テーブル情報を通過します。 論理的に、RTMPモジュールがトンネルの上のそれぞれの外のルータのためのRTMPデータ・パケットにあらゆる10を生成する、秒、-、-その時調節しているRTMP retransmissionは主要なルーティングモジュールにパケットを通過します。
The RTMP/ZIP-to-AURP conversion module also maintains a split- horizoned copy of the routing information maintained by the exterior router in which it resides. Logically, the conversion module obtains the routing information from RTMP data packets and ZIP Replies sent by the exterior router's central routing module, then updates the routing information in the conversion module.
また、RTMP/ZIPからAURPへの変換モジュールは、分裂がそれが住んでいる外のルータによって保守されたルーティング情報のコピーをhorizonedしたと主張します。 変換モジュールは、論理的に、RTMPデータ・パケットと外のルータの主要なルーティングモジュールで送られたZIP Repliesからルーティング情報を得て、次に、変換モジュールでルーティング情報をアップデートします。
Oppenheimer [Page 19] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[19ページ]RFC1504Appletalk
The AURP module exports routing information about its local AppleTalk internet to other exterior routers on the tunnel.
AURPモジュールは、トンネルの上でルーティングが地方のAppleTalkインターネットの情報であると他の外のルータにエクスポートします。
AURP Transport Layering
AURP輸送レイヤリング
AURP can propagate routing information between exterior routers using
AURPは、使用することで外のルータの間のルーティング情報を伝播できます。
a simple, reliable transport based on an underlying datagram
service-such as the default transport-layer service for AURP,
AURP-Tr. See the section "AURP-Tr," later in this chapter,
for more information.
基本的さに基づいたa簡単で、信頼できる輸送データグラムサービスそのようなもの、AURP、AURP-Trのためのデフォルトトランスポート層サービス。 詳しい情報に関してセクション中の後で"AURP-Tr"本章を見てください。
a more complex transport-layer service-such as TCP
そのようなものを修理しているTCPの、より複雑なトランスポート層
Figure 3-3 shows the AURP transport-layering model.
図3-3は輸送を層にするAURPモデルを示しています。
<<Figure 3-3 AURP transport-layering model>>
<<数値3-3輸送を層にするAURPモデル>>。
Maintaining Current Routing Information With AURP
AURPがある現在の経路情報を維持します。
AURP allows exterior routers to maintain current routing information for other exterior routers on a tunnel by supporting
AURPは、外のルータにトンネルの上でサポートすることによって、他の外のルータのための現在のルーティング情報を保守させます。
the reliable, initial exchange of split-horizoned routing
information - that is, the routing information for an exterior
router's local internet
分裂でhorizonedされたルーティング情報の信頼できて、初期の交換--すなわち、外のルータの地方のインターネットのためのルーティング情報
reliable updates to that information whenever it changes
変化するときはいつも、その情報への信頼できるアップデート
If an internet topology does not change, AURP generates significantly less routing traffic than RTMP and ZIP. Thus, an administrator can connect very large AppleTalk internets through a tunnel, and the resulting internet generates little or no routing traffic on the tunnel.
インターネットトポロジーが変化しないなら、AURPはRTMPとZIPよりかなり少ないルーティングトラフィックを生成します。 したがって、管理者はトンネルを通って非常に大きいAppleTalkインターネットを接続できます、そして、結果として起こるインターネットはまずトンネルの上のルーティングトラフィックを生成しません。
When an exterior router discovers another exterior router on the tunnel-that is, a peer exterior router-it can request that exterior router to send its routing information. In a reliable, initial exchange of split-horizoned routing information, the peer exterior router returns its network-number list. The peer exterior router also returns each connected network's zone information in an unsequenced series of zone-information packets. If the exterior router requesting the routing information does not receive complete zone information for a network, it must retransmit requests for zone information until it receives the information.
外のルータがすなわち、aにトンネルを堀っている同輩外部で別の外のルータを発見する、ルータ、-、それ、ルーティング情報を送るようその外のルータに要求できます。 分裂でhorizonedされたルーティング情報の信頼できて、初期の交換、外のルータが返す同輩では、ネットワーク・ナンバーは記載します。 また、同輩の外のルータは非配列されたシリーズのゾーン情報パケットでそれぞれの接続ネットワークのゾーン情報を返します。 ルーティング情報を要求する外のルータがネットワークのための完全なゾーン情報を受け取らないなら、それは知らせを聞くまでゾーン情報に関する要求を再送しなければなりません。
Once an exterior router requesting routing information from a peer exterior router has received that exterior router's network-number
一度、同輩の外のルータからルーティング情報を要求する外のルータはその外のルータのネットワーク・ナンバーを受けたことがあります。
Oppenheimer [Page 20] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[20ページ]RFC1504Appletalk
list and complete zone information, it typically requests the peer exterior router to notify it of any changes to that routing information. The peer exterior router then provides the requesting exterior router with reliable updates to its routing information- however, it sends no other routing information.
リストと完全なゾーン情報、それはそのルーティング情報へのあらゆる変化についてそれに通知するよう同輩の外のルータに通常要求します。 次に外のルータが信頼できるのがある要求の外のルータを提供する同輩は他のルーティング情報を全くしかしながら、送る情報を発送するのにアップデートしません。
Notifying Other Exterior Routers of Events
イベントの他の外のルータに通知します。
If an exterior router has requested notification of changes in another exterior router's split-horizoned routing information, that exterior router must notify the requesting exterior router of any event that changes its routing information. Thus, an exterior router must send updated routing information to the requesting exterior router whenever any of the following events occur:
外のルータが別の外のルータの分裂でhorizonedされたルーティング情報における変化の通知を要求したなら、その外のルータはルーティング情報を変えるどんなイベントの要求の外のルータにも通知しなければなりません。 したがって、以下のイベントのどれかが起こるときはいつも、外のルータはアップデートされたルーティング情報を要求の外のルータに送らなければなりません:
the addition of a new, exported network-that is, a network that is
not hidden-to the exterior router's local internet and,
consequently, to its routing table
外のルータの地方のインターネットとその結果、その経路指定テーブルに隠されなかったすなわち、aをネットワークでつないでいる新しくて、エクスポートしているネットワークの参加
a change in the path to an exported network that causes the
exterior router to access that network through its local internet
rather than through a tunneling port
外のルータをトンネリングポートを通してというよりむしろ地方のインターネットを通してそのネットワークにアクセスさせるエクスポートしているネットワークへの経路の変化
the removal of an exported network from the exterior router's
routing table because a network in the exterior router's local
internet has gone down
外のルータの地方のインターネットにおけるネットワークが落ちたので外のルータがテーブルを発送するのからのエクスポートしているネットワークの取り外し
a change in the path to an exported network that causes the
exterior router to access that network through a tunneling port
rather than through its local internet
外のルータを地方のインターネットを通してというよりむしろトンネリングポートを通してそのネットワークにアクセスさせるエクスポートしているネットワークへの経路の変化
a change in the distance to an exported network
aはエクスポートしているネットワークに遠くに変わらせます。
a change to a zone name in the zone list of an exported network-
an event not currently supported by ZIP or the current version of
AURP
ゾーンのゾーン名へのa変化が記載する、ネットワークが現在ZIPによってサポートされていないイベントかAURPの最新版であるとエクスポートします。
the exterior router goes down or is shut down
外のルータは、落ちるか、または止められます。
Routing-information updates allow an exterior router to maintain accurate, split-horizoned routing information for a peer exterior router on a tunnel.
ルート設定情報最新版で、外のルータはトンネルの上で同輩の外のルータのための正確で、分裂でhorizonedされたルーティング情報を保守できます。
AURP-Tr
AURP-Tr
AURP-Tr, the default transport-layer service for AURP, provides a simple, reliable transport that is based on an underlying datagram service. When using AURP-Tr, only one sequenced transaction can be
AURP-Tr(AURPのためのデフォルトトランスポート層サービス)は基本的なデータグラムサービスに基づいている簡単で、信頼できる輸送を提供します。 AURP-Tr、1つの配列されたトランザクションだけを使用するのは、いつであることができますか。
Oppenheimer [Page 21] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[21ページ]RFC1504Appletalk
outstanding, or unacknowledged, at a time-greatly simplifying the implementation of AURP, without limiting its functionality.
傑出しているか、または大いに機能性を制限しないでAURPの実装を簡素化する時に認められません。
One-Way Connections
一方向コネクションズ
A one-way connection is an asymmetrical link between a data sender and a data receiver that are using AURP-Tr, in which an exterior router functioning as a data sender sends a sequenced, reliable, unidirectional data stream to an exterior router functioning as a data receiver. An exterior router can send routing information over a one-way connection as
一方向接続はAURP-Trを使用しているデータ送付者とデータ受信装置との非対称的なリンクです。(そこでは、データ送付者として機能する外のルータが. 外のルータが一方向接続の上のルーティング情報を送ることができるデータ受信装置として機能する外のルータに配列されて、信頼できる単方向のデータ・ストリームを送ります)。
sequenced data
配列されたデータ
transaction data
変更用データ
Sequenced data is data sent in sequence by the data sender and delivered reliably to the data receiver. Typically, the sending of sequenced data is unprovoked-that is, it is not requested by a data receiver. However, a data receiver can request sequenced data. Figure 3-4 shows sequenced data being sent across a one-way connection.
配列されたデータはデータ受信装置への連続してデータ送付者によって送られて、確かに提供されたデータです。配列されたデータの発信が通常、そう、刺激されなさ、-それはそうです、それ、要求されていない、aデータ受信装置しかしながら、データ受信装置缶の要求がデータを配列しました。 図3-4ショーは一方向接続の向こう側に送られるデータを配列しました。
<<Figure 3-4 Sequenced data on a one-way connection>>
<<数値3-4一方向接続>>に関するSequencedデータ
Transaction data-also referred to as out-of-band data-is data sent unsequenced by the data sender through a linked request/response transaction that is initiated by the data receiver.
送られたデータがバンドの外にデータであるとき、示された変更用データもデータ受信装置によって開始される繋がっている要求/応答トランザクションを通してデータ送付者に非配列されました。
The data receiver can use a one-way connection to request transaction data from the data sender. If the data receiver does not receive a response, it must retransmit its request. Figure 3-5 shows a one-way connection on which the data receiver requests transaction data from the data sender.
データ受信装置は、データ送付者から変更用データを要求するのに一方向接続を使用できます。 データ受信装置が応答を受けないなら、それは要求を再送しなければなりません。 図3-5はデータ受信装置がデータ送付者から変更用データを要求する一方向接続を示しています。
<<Figure 3-5 Request for transaction data on a one-way connection>>
<<数値3-5一方向接続>>に関する変更用データのためのRequest
Generally, communication between two exterior routers is bidirectional-that is, two one-way connections exist between the exterior routers, with each exterior router acting as the data sender on one connection and the data receiver on the other. Thus, each exterior router can send its routing information to the other.
-すなわち、一般に、2つの外のルータのコミュニケーションがそうである、双方向、2つの一方向接続が外のルータの間に存在しています、それぞれの外のルータが1つの接続でのデータ送付者とデータ受信装置としてもう片方に機能して。 したがって、それぞれの外のルータはルーティング情報をもう片方に送ることができます。
Initial Information Exchange
初期の情報交換
When an AppleTalk exterior router discovers another exterior router on the tunnel, it uses the underlying transport-layer service to open a connection with that exterior router. When using AURP-Tr, an exterior router opens this connection as a one-way connection.
AppleTalkの外のルータがトンネルの上で別の外のルータを発見するとき、それは、その外のルータとの関係を開くのに基本的なトランスポート層サービスを利用します。 AURP-Trを使用するとき、外のルータは一方向接続としてこの接続を開きます。
Oppenheimer [Page 22] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[22ページ]RFC1504Appletalk
Open Request Packet
開いているリクエスト・パケット
Once the data receiver opens a connection using the underlying transport, the data receiver sends an Open Request packet, or Open- Req, to the data sender. An Open-Req packet includes the following information:
データ受信装置が基本的な輸送を使用することでいったん接続を開くと、データ受信装置はオープンRequestパケット、またはオープンReqを送ります、データ送付者に。 オープン-Reqパケットは以下の情報を含んでいます:
Send update information flags: The states of the four send update information (SUI) flags indicate whether the data sender should send various types of update information over the connection. Typically, the four SUI flags are set to 1.
アップデート情報フラグを送ってください: 4つのものの州は接続の上でデータ送付者が発信するべきであるか否かに関係なく、旗が示すアップデート情報(SUI)に様々なタイプのアップデート情報を送ります。 通常、4個のSUI旗が1に設定されます。
Version number: The version number field indicates the version of AURP used by the data receiver. The current version number of AURP is 1.
バージョン番号: バージョンナンバーフィールドはデータ受信装置によって使用されるAURPのバージョンを示します。AURPの最新版番号は1です。
Data field: The optional data field allows exterior routers with capabilities beyond those described in this document to notify other exterior routers about such options, by initiating option negotiation. An exterior router that has similar capabilities indicates that it accepts the options, completing option negotiation. An exterior router that lacks such options ignores the information in the data field.
データ・フィールド: 能力が本書では説明されたものを超えてある外のルータは任意のデータ・フィールドでそのようなオプションに関して他の外のルータに通知できます、オプション交渉を開始することによって。 オプション交渉を終了して、同様の能力を持っている外のルータは、オプションを受け入れるのを示します。 そのようなオプションを欠いている外のルータはデータ・フィールドで情報を無視します。
Open Response Packet
開いている応答パケット
When an exterior router receives an Open-Req, it becomes the data sender and responds with an Open Response packet, or Open-Rsp, as follows:
外のルータがオープン-Reqを受けるとき、データ送付者になって、オープンResponseパケット、またはオープン-Rspと共に応じます、以下の通りです:
If the exterior router accepts the connection, it returns
information about its setup in the Open-Rsp. An Open-Rsp also
contains an optional data field. This data field indicates whether
the exterior router accepts the options in the data field of the
Open-Req to which it is responding.
外のルータが接続を受け入れるなら、それはオープン-Rspでのセットアップの情報を返します。 また、オープン-Rspは任意のデータ・フィールドを含んでいます。 このデータ・フィールドは、外のルータがそれが応じているオープン-Reqのデータ・フィールドでオプションを受け入れるかどうかを示します。
If the exterior router cannot accept the connection-for example,
because the Open-Req does not contain the correct version number-it
returns an error in the Open-Rsp and closes the transport-layer
connection.
外のルータがそうすることができないなら、例えば接続を受け入れてください、オープン-Reqがそれに付番する状態で正しいバージョンを含んでいないので。オープン-Rspで誤りを返して、トランスポート層接続を終えます。
Figure 3-6 shows a connection-opening dialog between a data sender and a data receiver.
図3-6はデータ送付者とデータ受信装置の間の接続の初めである対話を示しています。
<<Figure 3-6 Connection-opening dialog>>
<<数値3-6Connection-始まり対話>>。
Oppenheimer [Page 23] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[23ページ]RFC1504Appletalk
Routing Information Request Packet
経路情報リクエスト・パケット
Under AURP, once two exterior routers establish a connection, the data receiver can request the data sender to send its routing information by sending it a Routing Information Request packet, or RI-Req.
AURPの下では、2つの外のルータがいったん取引関係を築くと、データ受信装置は、経路情報Requestパケット、またはロードアイランド-Reqをそれに送ることによってルーティング情報を送るようデータ送付者に要求できます。
Routing Information Response Packets
経路情報応答パケット
When the data sender receives an RI-Req, it reliably sends a sequence of Routing Information Response packets, or RI-Rsp, to the exterior router requesting the information.
データ送付者がロードアイランド-Reqを受け取るとき、経路情報Responseパケット、またはロードアイランド-Rspの系列を確かに送ります、情報を要求する外のルータに。
The RI-Rsp packets provide a list of exported networks on the data sender's local internet and the distance of each network from the data sender. The data sender must finish sending RI-Rsp packets to the exterior router requesting routing information before it can send any other sequenced data over the connection. Figure 3-7 shows a routing-information request/response dialog between a data sender and a data receiver.
ロードアイランド-Rspパケットはデータ送付者からデータ送付者の地方のインターネットのエクスポートしているネットワークのリストとそれぞれのネットワークの距離を提供します。 データ送付者は、いかなる他の配列されたデータも接続の上に送ることができる前にルーティング情報を要求する外のルータにロードアイランド-Rspパケットを送り終えなければなりません。 図3-7はデータ送付者とデータ受信装置の間のルーティング情報要求/応答対話を示しています。
<<Figure 3-7 Routing-information request/response dialog>>
<<数値3-7ルート設定情報要求/応答対話>>。
Zone Information Request Packet
ゾーン情報リクエスト・パケット
The data receiver can obtain zone information for known networks on the data sender's local internet at any time, by sending it a Zone Information Request packet, or ZI-Req. A ZI-Req lists the numbers of networks for which the data receiver is requesting zone information.
データ受信装置はいつでもデータ送付者の地方のインターネットで知られているネットワークのためのゾーン情報を得ることができます、Zone情報Requestパケット、またはZI-Reqをそれに送ることによって。 ZI-Reqはデータ受信装置がゾーン情報を要求しているネットワークの数を記載します。
IMPORTANT: To prevent other exterior routers on a tunnel from sending endless streams of ZI-Req packets across the tunnel-causing what is referred to as a ZIP storm-an exterior router must not export information about a network until it has a complete zone list for that network.
重要: トンネルの上の他の外のルータがトンネル引き起こすことの向こう側のZI-Reqパケットの無限の流れにZIPと呼ばれるものを送るのを防ぐ、嵐、-1、それにはそのネットワークのための完全なゾーンリストがあるまで、外のルータはネットワークの情報をエクスポートしてはいけません。
Zone Information Response Packets
ゾーン情報応答パケット
When the data sender receives a ZI-Req, it responds by sending unsequenced Zone Information Response packets, or ZI-Rsp, to the data receiver. Zone information is transaction data-thus, its reliable delivery is not guaranteed. Figure 3-8 shows a zone-information request/response dialog between a data sender and a data receiver.
データ送付者がZI-Reqを受け取るとき、unsequenced Zone情報のResponseパケット、またはZI-Rspを送ることによって、応じます、データ受信装置に。信頼できる配信はその結果、ゾーン情報が変更用データであることが保証されません。 図3-8はデータ送付者とデータ受信装置の間のゾーン情報要求/応答対話を示しています。
<<Figure 3-8 Zone-information request/response dialog>>
<<数値3-8Zone-情報要求/応答対話>>。
Oppenheimer [Page 24] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[24ページ]RFC1504Appletalk
Recovering Lost Zone Information
回復はゾーン情報を失いました。
A data receiver enters a network-to-zone list association in its routing table for each network for which it receives a ZI-Rsp packet. If a data receiver that requested zone information for a network does not receive a complete zone list for that network, it must retransmit ZI-Req packets, requesting zone information for that network, until it receives that network's complete zone information.
データ受信装置はそれがZI-Rspパケットを受ける各ネットワークのためにネットワークからゾーンへのリスト協会を経路指定テーブルに入れます。 ネットワークのためのゾーン情報を要求したデータ受信装置がそのネットワークのための完全なゾーンリストを受け取らないなら、ZI-Reqパケットを再送しなければなりません、そのネットワークのためのゾーン情報を要求して、そのネットワークの完全なゾーン情報を受け取るまで。
To determine if any ZI-Rsp packets were lost, the data receiver periodically scans its routing table for networks for which the associated zone lists are incomplete-that is, for zone lists that do not include all zones associated with the networks. The data receiver sends a ZI-Req to each data sender from which it received incomplete zone information, listing the numbers of networks for which it has incomplete zone lists. The data sender responds to zone information requests by sending ZI-Rsp packets containing the requested information to the data receiver.
-すなわち、何かZI-Rspパケットが失われたなら、データ受信装置が関連ゾーンリストがそうであるネットワークのために定期的に経路指定テーブルをスキャンすることを決定する、不完全である、ネットワークに関連しているすべてのゾーンを含んでいるというわけではないゾーンリスト。 データ受信装置はそれが不完全なゾーン情報を受け取ったそれぞれのデータ送付者にZI-Reqを送ります、それが不完全なゾーンリストを持っているネットワークの数を記載して。 データ送付者は、データ受信装置に求められた情報を含むパケットをZI-Rspに送ることによって、ゾーン情報要求に応じます。
Using AURP-Tr for Initial Information Exchange
初期の情報交換にAURP-Trを使用します。
The following sections describe the use of AURP-Tr-the default transport-layer service for AURP-for initial information exchange.
以下のセクションが使用について説明する、AURP-Tr、-、デフォルトトランスポート層サービス、AURP、-、情報交換に頭文字をつけてください。
OPEN REQUEST PACKET: An exterior router sends an Open-Req packet to
リクエスト・パケットを開いてください: ルータがオープン-Reqパケットを送る外部
request that an AURP-Tr one-way connection with another exterior
router be established
別の外のルータとのAURP-Trの一方向関係が確立されるよう要求してください。
specify the connection ID for that connection
その接続に接続IDを指定してください。
pass the AURP version number, SUI flags, and optional data to the
other exterior router
AURPバージョン番号、SUI旗、および任意のデータをもう片方の外のルータに渡してください。
If the exterior router does not receive an Open-Rsp from the exterior router to which it sent an Open-Req, it must retransmit the Open-Req.
外のルータがそれがオープン-Reqを送った外のルータからオープン-Rspを受けないなら、それはオープン-Reqを再送しなければなりません。
OPEN RESPONSE PACKET: When using AURP-Tr, an exterior router sends an Open-Rsp to
応答パケットを開いてください: AURP-Trを使用して、外のルータはオープン-Rspをいつに送りますか。
acknowledge that a one-way connection has been established
一方向接続が確立されたと認めてください。
reject a connection
接続を拒絶してください。
return information about its environment, as well as any optional
data, to the exterior router from which it received an Open-Req
それがオープン-Reqを受けた外のルータに環境、およびどんな任意のデータの情報も返してください。
Oppenheimer [Page 25] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[25ページ]RFC1504Appletalk
If an exterior router receives an Open-Req on a one-way connection that is already open-that is, if it receives an Open-Req with the same connection ID as an open one-way connection-an Open-Rsp sent previously may have been lost. The exterior router receiving the duplicate Open-Req should send a duplicate Open-Rsp to the sending exterior router, unless it has already received some other packet on the connection-such as an RI-Req-indicating the existence of a fully established connection.
外のルータが既に一方向接続でのオープン-Reqを受ける、すなわち、戸外、同じ接続IDと共に戸外として一方向でオープン-Reqを受ける、接続、-1、以前に送られたオープン-Rspはなくされたかもしれません。 写しオープン-Reqを受ける外のルータは写しオープン-Rspを送付の外のルータに送るべきです、既にある他のパケットを受けていない場合オンである、接続そのようなもの、ロードアイランドのReq表示、完全に確立した接続の存在。
ROUTING INFORMATION RESPONSE PACKETS: When responding to a request for routing information using AURP-Tr, an exterior router sends a sequence of RI-Rsp packets to the exterior router requesting the information. However, an exterior router's complete list of network numbers often fits in a single RI-Rsp packet. Each RI-Rsp packet contains the following information:
経路情報応答パケット: AURP-Trを使用することでルーティング情報に関する要求に応じるとき、外のルータで、外のルータへのロードアイランド-Rspパケットの系列は情報を要求します。 しかしながら、外のルータのネットワーク・ナンバーに関する全リストはしばしば単一のロードアイランド-Rspパケットをうまくはめ込みます。 それぞれのロードアイランド-Rspパケットは以下の情報を含んでいます:
Connection ID: The connection ID identifies the specific one-way connection to which a packet belongs.
接続ID: 接続IDはパケットが所有特定の一方向接続を特定します。
Sequence number: The sequence number identifies an individual packet on a connection. Packets on a connection are numbered starting with the number 1.
一連番号: 一連番号は接続のときに個々のパケットを特定します。 接続でのパケットはNo.1をきっかけに付番されます。
The data sender sending routing information must wait for the data receiver to acknowledge that it has received each RI-Rsp packet in the sequence-by sending an RI-Ack packet-before sending the next RI- Rsp packet. Each RI-Rsp contains a flag that indicates whether it is the last packet in the sequence. In the last RI-Rsp in the sequence, this flag is set to 1. If the data sender receives no acknowledgment of an RI-Rsp from the data receiver within a specified period of time, it must retransmit the RI-Rsp.
データ送付者送付ルーティング情報は、以前ロードアイランド-Ackパケットに次のロードアイランドRspパケットを送らせながら近く系列でそれぞれのロードアイランド-Rspパケットを受けたと認めるのをデータ受信装置を待たなければなりません。 各ロードアイランド-Rspはそれが系列で最後のパケットであるかどうかを示す旗を含んでいます。 系列における最後のロードアイランド-Rspでは、この旗は1に設定されます。 データ送付者が指定された期間以内にデータ受信装置からロードアイランド-Rspの承認を全く受けないなら、それはロードアイランド-Rspを再送しなければなりません。
ROUTING INFORMATION RESPONSE PACKETS: When an exterior router receives an RI-Rsp, it verifies the packet's connection ID and sequence number. The connection ID must be the same as that in the Open-Req. The sequence number must be either
経路情報応答パケット: 外のルータがロードアイランド-Rspを受けるとき、それはパケットの接続IDと一連番号について確かめます。 接続IDはオープン-Reqのそれと同じであるに違いありません。 一連番号はどちらかであるに違いありません。
the last sequence number received, indicating that the previous
acknowledgment was lost or delayed, and that this is a duplicate
RI-Rsp the next number in the sequence, indicating that this
RI-Rsp contains new routing information
このロードアイランド-Rspが新しいルーティング情報を含むのを示して、受け取られた一連番号、前の承認が失われたか、または遅れて、これが写しロードアイランド-Rspであることを次が付番する示すのを系列で持続します。
If the connection ID or sequence number is invalid, the data receiver discards the packet. Figure 3-9 shows a dialog between a data sender and a data receiver in which the data receiver requests routing information, the data sender responds by sending its routing information, and the data receiver acknowledges the data sender's response. If the data sender receives no acknowledgment, it sends
接続IDか一連番号が無効であるなら、データ受信装置はパケットを捨てます。 データ送付者の応答を承諾します図3-9が、データ受信装置が、情報を発送して、データ送付者がルーティング情報、およびデータ受信装置を送ることによって応じるよう要求するデータ送付者とデータ受信装置の間の対話を示している。 データ送付者が承認を全く受けないなら、それは発信します。
Oppenheimer [Page 26] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[26ページ]RFC1504Appletalk
duplicate RI-Rsp packets until the data receiver responds with an acknowledgment.
データ受信装置が承認で応じるまで、ロードアイランド-Rspパケットをコピーしてください。
<<Figure 3-9 Routing-information request/response/acknowledgment
dialog>>
<<数値3-9ルート設定情報要求/応答/承認対話>>。
Once the data receiver has verified the information in the RI-Rsp, it responds with a Routing Information Acknowledgment packet, or RI-Ack, which contains the following information:
データ受信装置がいったんロードアイランド-Rspの情報について確かめると、経路情報Acknowledgmentパケット、またはロードアイランド-Ackと共に応じます:(Ackは以下の情報を含みます)。
Connection ID: The connection ID is the same as that in the RI-Rsp packet.
接続ID: 接続IDはロードアイランド-Rspパケットのそれと同じです。
Sequence number: The sequence number is the same as that in the RI- Rsp packet.
一連番号: 一連番号はロードアイランドRspパケットのそれと同じです。
Send zone information flag: The state of the send zone information (SZI) flag in an RI-Ack packet indicates whether the RI-Ack packet doubles as a ZI-Req packet. If the SZI flag is set to 1, the data receiver sends the zone information associated with the networks about which it sent routing information in the previous RI-Rsp.
ゾーン情報フラグを送ってください: 状態、ロードアイランド-AckパケットをZI-Reqパケットの役目も兼ねるか否かに関係なく、ロードアイランド-Ackパケットの(SZI)旗が示すゾーン情報を送ってください。 SZI旗が1に設定されるなら、データ受信装置はそれが前のロードアイランド-Rspのルーティング情報を送ったネットワークに関連しているゾーン情報を送ります。
Figure 3-10 shows a data receiver sending zone information to a data sender in response to a ZI-Req and in response to an RI-Ack, which optimizes the data flow.
図3-10は、データ受信装置がZI-Reqに対応してロードアイランド-Ackに対応してゾーン情報をデータ送付者に送るのを示します。Ackはデータフローを最適化します。
When the data sender receives an RI-Ack, it verifies that the RI-Ack corresponds to the outstanding RI-Rsp-that is, both packets have the same connection ID and sequence number. Once the data sender has verified the information in the RI-Ack, it responds by sending the next RI-Rsp in the sequence, if any.
データ送付者がロードアイランド-Ackを受け取るとき、ロードアイランド-Ackが傑出に対応することを確かめる、そうするロードアイランドRsp、両方、パケットには、同じ接続IDと一連番号があります。 データ送付者がいったんロードアイランド-Ackの情報について確かめると、それは、系列でもしあれば次のロードアイランド-Rspを送ることによって、応じます。
<<Figure 3-10 Nonoptimized and optimized flows of zone information>>
<<数値3-10ゾーン情報>>のNonoptimizedと最適化された流れ
ZONE INFORMATION RESPONSE PACKETS: If the data sender receives an RI-Ack with its SZI flag set to 1, it responds by sending ZI-Rsp packets that contain the zone information associated with the networks about which it sent routing information in the RI-Rsp being acknowledged-just as it would if it received a ZI-Req for those networks.
ゾーン情報応答パケット: データ送付者がSZI旗のセットでロードアイランド-Ackを1に受け取るなら、ロードアイランド-Rspにそれがルーティング情報を送ったネットワークに関連しているゾーン情報を含むZI-Rspパケットがただ承認させていることによって、それはそれらのネットワークのためにZI-Reqを受けるなら応じるように応じます。
The data sender sends RI-Rsp and ZI-Rsp packets as independent data streams. It sends RI-Rsp packets as sequenced data and ZI-Rsp packets as transaction data. If the data sender receives an RI-Ack with its SZI flag set to 1, it sends an unsequenced series of ZI-Rsp packets that contain the following information:
独立しているデータが流れるとき、データ送付者はロードアイランド-RspとZI-Rspにパケットを送ります。それは、変更用データとして配列されるとしてのロードアイランド-Rspパケットにデータを送って、パケットをZI-Rspに送ります。 データ送付者がSZI旗のセットでロードアイランド-Ackを1に受け取るなら、以下の情報を含む非配列されたシリーズのZI-Rspパケットを送ります:
Connection ID: The connection ID is the same as that in the
接続ID: 接続IDはそのコネと同じです。
Oppenheimer [Page 27] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[27ページ]RFC1504Appletalk
associated RI-Req.
関連ロードアイランド-Req。
Network number and zone list tuples: The exterior router sends the zone information associated with each network number in the corresponding RI-Rsp.
ネットワーク・ナンバーとゾーンはtuplesを記載します: 外のルータは対応するロードアイランド-Rspの各ネットワーク・ナンバーに関連しているゾーン情報を送ります。
Reobtaining Routing Information
経路情報をReobtainingします。
An exterior router can reobtain another exterior router's complete routing information at any time, by sending an RI-Req packet. An exterior router might need to reobtain complete routing information for a one-way connection on which it is the data receiver under the following circumstances:
外のルータは外のルータの別のものがロードアイランド-Reqパケットを送ることによって情報をいつでも発送するのを完成するreobtainをそうすることができます。 外のルータはそれが以下の状況でデータ受信装置である一方向接続のために完全なルーティング情報をreobtainに必要とするかもしれません:
During the initial routing-information exchange, the exterior
router set the SUI flags in the Open-Req to disable updates. The
exterior router can subsequently poll the other exterior router on
the connection by sending an RI-Req to that exterior router to
determine whether any of its routing information has changed.
初期のルーティング情報交換の間、外のルータは、アップデートを無効にするためにオープン-ReqにSUI旗をはめ込みました。 ルーティング情報のどれかが変化したかどうか決定するためにロードアイランド-Reqをその外のルータに送ることによって、外のルータは接続のときに次に、もう片方の外のルータに投票できます。
The exterior router set the SUI flags to request updates, but
suspects that the routing information for the other exterior router
on the connection is incorrect or obsolete. The exterior router
should send an RI-Req to the other exterior router to obtain its
complete, updated routing information.
SUIが要求に旗を揚げさせる外のルータセットは、接続でのもう片方の外のルータのためのルーティング情報が不正確であるか、または時代遅れであるとアップデートしますが、疑います。 外のルータは、完全で、アップデートされたルーティング情報を得るためにロードアイランド-Reqをもう片方の外のルータに送るべきです。
Whenever an exterior router receives an RI-Req from an exterior router requesting updated routing information, it responds by sending RI-Rsp packets, just as it does when it first receives an RI-Req. The data sender also resets the SUI flags for that one-way connection, so they correspond to those in the RI-Req.
外のルータがアップデートされたルーティング情報を要求する外のルータからロードアイランド-Reqを受けるときはいつも、ロードアイランド-Rspパケットを送ることによって、応じます、最初にロードアイランド-Reqを受けるとき、ちょうどするように。 また、データ送付者がその一方向接続のためのSUI旗をリセットするので、それらはロードアイランド-Reqのそれらに対応しています。
If the data sender is sending other sequenced update information when it receives an RI-Req, it cannot respond to the RI-Req until the data receiver acknowledges the last outstanding packet in the sequence. If AURP uses an underlying transport-layer service that does not provide reliable delivery, such as AURP-Tr, it may be necessary for the data receiver to retransmit an RI-Req.
データ送付者であるなら、ロードアイランド-Reqを受けるとき、受信機が承認するデータまでロードアイランド-Reqに応じることができないという他の配列されたアップデート情報を送るのは、系列で最後の傑出しているパケットですか? AURPが基本的なトランスポート層サービスを利用するなら、それはデータ受信装置が再送するのがAURP-Trなどのように必要であるかもしれない信頼できる配信にロードアイランド-Reqを提供しません。
Updating Routing Information
経路情報をアップデートします。
Once an exterior router receives the routing and zone information for another exterior router's local internet, if the receiving exterior router has set the SUI flags in the Open-Req to request updates, the data sender notifies the data receiver of any subsequent changes to that information.
外のルータがいったん別の外のルータの地方のインターネットのためのルーティングとゾーン情報を受け取ると、受信の外のルータがアップデートを要求するためにオープン-ReqにSUI旗をはめ込んだなら、データ送付者はその情報へのどんなその後の変化のデータ受信装置にも通知します。
Oppenheimer [Page 28] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[28ページ]RFC1504Appletalk
Informed-Routers List
知識があるルータリスト
An exterior router maintains an informed-routers list containing the network address of each exterior router that has requested dynamic updating of routing information. Once an exterior router has sent routing information for its local internet to other exterior routers on the tunnel, it must reliably send updated routing information to all accessible exterior routers in its informed-routers list whenever its routing information changes.
外のルータはルーティング情報のダイナミックなアップデートを要求したそれぞれの外のルータのネットワーク・アドレスを含む知識があるルータリストを維持します。 外のルータがトンネルでいったん地方のインターネットのためのルーティング情報を他の外のルータに送ると、情報変化を発送するとき、それは知識があるルータリストのすべてのアクセスしやすい外のルータにアップデートされたルーティング情報を確かに送らなければなりません。
Sending Routing Information Update Packets
送付経路情報アップデートパケット
An exterior router communicates changes in its routing information by sending Routing Information Update, or RI-Upd, packets to another exterior router. When the routing information for an exterior router's local internet changes, the exterior router need not send an RI-Upd immediately. Generally, an exterior router buffers the update information, then sends updates periodically. The exterior router must wait at least an update interval between sending updates. The value of this update interval
外のルータは、経路情報Update、またはロードアイランド-Upd(別の外のルータへのパケット)を送ることによって、ルーティング情報における変化を伝えます。 外のルータの地方のインターネットのためのルーティング情報がすぐに変化するとき、外のルータはロードアイランド-Updを送る必要はありません。 一般に、外のルータは、アップデート情報をバッファリングして、次に、定期的にアップデートを送ります。 外のルータは少なくとも送付アップデートのアップデート間隔を待たなければなりません。 このアップデート間隔の値
cannot be less than ten seconds
10秒未満であることができません。
should be specifiable by a network administrator
ネットワーク管理者は明記できるべきです。
It is possible that more than one update event for a particular network might occur within one update interval. One of these events might supercede another-for example, a Network Added event followed by a Network Deleted event for the same network. In this case, the exterior router can represent the two events logically as one event. Under AURP, an exterior router can have only one event pending for a given network. An exterior router can combine any series of events for a network into a single pending event. In Figure 3-11, a state diagram shows the update event that an exterior router should have pending for a network, based on the other events that have occurred during the update interval.
特定のネットワークのための1つ以上のアップデートイベントが1回のアップデート間隔以内に起こるのは、可能です。 これらのイベントの1つは例えば、別のものでスーパー割譲されるかもしれません、とNetwork Addedイベントが同じネットワークのためにNetwork Deletedイベントで続きました。 この場合、外のルータは1つのイベントとして2つのイベントを論理的に表すことができます。 AURPの下では、外のルータは与えられたネットワークに、未定の1つのイベントしか持つことができません。 外のルータはネットワークのためにどんなシリーズのイベントもただ一つの未定のイベントに結合できます。 図3-11では、州のダイヤグラムはネットワークに未定の状態で外のルータが持つべきであるアップデートイベントを示しています、アップデート間隔の間に起こっている他のイベントに基づいて。
<<Figure 3-11 A state diagram showing pending update events>>
<<数値3-11未定のアップデートイベント>>を示しているA州のダイヤグラム
Four of the states correspond to four pending update events. Two states indicate that no update event is pending:
4つの州が4つの未定のアップデートイベントに対応しています。 2つの州が、どんなアップデートイベントも未定でないことを示します:
Net Up-indicates that no update event is pending for a network
in the exterior router's local internet
ネットは、外のルータの地方のインターネットにおけるネットワークには、どんなアップデートイベントも未定でないことをUp示します。
Net Down-indicates that no update event is pending for a network in
another exterior router's local internet or the network does not
exist
ネットが、別の外のルータの地方のインターネットにおけるネットワークには、どんなアップデートイベントも未定でないことをDown示すか、またはネットワークは存在していません。
Oppenheimer [Page 29] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[29ページ]RFC1504Appletalk
A single RI-Upd packet may contain different types of update events- for example, several Network Added events and several Network Deleted events. For information about update events, see the section "Routing-Information Update Events" later in this chapter.
単一のロードアイランド-Updパケットは例えば、異なったタイプのアップデートイベント、いくつかのNetwork Addedイベント、およびいくつかのNetwork Deletedイベントを含むかもしれません。 アップデートイベントの情報に関しては、後で本章で「経路情報アップデートイベント」というセクションを見てください。
A data sender should send an RI-Upd packet to an exterior router in its informed-routers list only if the packet contains one or more update events of a type indicated by the SUI flags of the last Open- Req or RI-Req received from that exterior router. Because an RI-Upd that contains one or more events of a type requested by an exterior router may also contain events of types not requested, an exterior router must be able to handle events of all types. Thus, a data sender can send an RI-Upd that contains various types of update events to all exterior routers that have requested update events of any of those types.
パケットが最後のオープンReqかその外のルータから受け取られたロードアイランド-ReqのSUI旗で示されたタイプの1つ以上のアップデートイベントを含む場合にだけ、データ送付者は知識があるルータリストの外のルータにロードアイランド-Updパケットを送るべきです。 また、外のルータによって要求されたタイプの1つ以上のイベントを含むロードアイランド-Updが要求されなかったタイプのイベントを含むかもしれないので、外のルータはすべてのタイプのイベントを扱うことができなければなりません。 したがって、データ送付者はそういったタイプの人のどれかのアップデートイベントを要求したすべての外のルータに様々なタイプのアップデートイベントを含むロードアイランド-Updを送ることができます。
Sending Updates Following the Initial Exchange of Routing Information
経路情報の初期の交換に続く送付アップデート
While a data sender has update events pending-that is, when update events have occurred but the data sender has not yet sent RI-Upd packets for those events-another exterior router may establish a new connection with the data sender. The data sender must present consistent routing information to all exterior routers on the tunnel, on both existing connections and any new connections. For example, if a pending update event indicated that a new network had become available, the newly connected exterior router could be informed of that network's presence on the internet either by
データ送付者にはアップデートイベントがある、未定である、-それはそうです、いつ、アップデートイベントが起こりましたが、データ送付者は確立していませんが、外のルータがそうするイベント別のもののための送られたロードアイランド-Updパケットはデータ送付者との新しい接続を確立するか。 データ送付者はトンネルの上のすべての外のルータに一貫したルーティング情報を提示しなければなりません、既存の接続とどんな新しい接続の両方でも。 例えば、未定のアップデートイベントが、新しいネットワークが利用可能になったのを示すなら、インターネットでそのネットワークの存在について新たに接続された外のルータは知らすことができるでしょうに。
sending it an RI-Rsp packet including routing information for the
new network
新しいネットワークのための情報を発送するのを含むロードアイランド-Rspパケットをそれに送ります。
sending it an RI-Rsp packet that does not include routing
information for the new network, then sending it the RI-Upd packet
that includes the pending update event
新しいネットワークのための情報を発送するのを含んでいないロードアイランド-Rspパケットをそれに送って、次に、未定のアップデートイベントを含んでいるロードアイランド-Updパケットをそれに送ります。
AURP does not specify a scheme for sending update information following the initial exchange of routing information on a new connection. However, the Appendix, "Implementation Details," describes one possible method of doing this.
AURPはアップデート情報を新しい接続のルーティング情報の初期の交換に続かせることの体系を指定しません。 しかしながら、「実装の詳細」というAppendixはこれをする1つの可能なメソッドを説明します。
Using AURP-Tr to Update Routing Information
経路情報をアップデートするのにAURP-Trを使用します。
The following sections describe the use of AURP-Tr for sending routing-information updates.
以下のセクションはAURP-Trの送付ルーティング情報最新版の使用について説明します。
ROUTING INFORMATION UPDATE PACKETS: Each RI-Upd packet contains the following information:
経路情報アップデートパケット: それぞれのロードアイランド-Updパケットは以下の情報を含んでいます:
Oppenheimer [Page 30] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[30ページ]RFC1504Appletalk
Connection ID: The connection ID identifies the specific one-way connection to which the RI-Upd belongs.
接続ID: 接続IDはロードアイランド-Updが属する特定の一方向接続を特定します。
Sequence number: The sequence number identifies an individual RI-Upd on a connection.
一連番号: 一連番号は接続のときに個々のロードアイランド-Updを特定します。
If an update cannot be contained in one RI-Upd packet, the data sender must send a sequence of RI-Upd packets. While the data sender need not wait for the duration of an update interval before sending each RI-Upd packet in a sequence, it must wait for the data receiver to acknowledge that it has received the RI-Upd packet that is currently outstanding before sending the next RI-Upd packet in the sequence.
1つのロードアイランド-Updパケットにアップデートを含むことができないなら、データ送付者はロードアイランド-Updパケットの系列を送らなければなりません。 次々にそれぞれのロードアイランド-Updパケットを送る前にデータ送付者がアップデート間隔の持続時間を待つ必要はない間、それは、系列で次のロードアイランド-Updパケットを送る前に現在傑出しているロードアイランド-Updパケットを受けたと認めるのをデータ受信装置を待たなければなりません。
If the data sender sending an RI-Upd does not receive an acknowledgment, or RI-Ack, from the data receiver within a specified period of time, the data sender should periodically retransmit the RI-Upd until it receives an acknowledgment from the data receiver. Once the data sender retransmits the RI-Upd a specified number of times, if it does not receive an RI-Ack, it should assume that the one-way connection on which it is the data sender is down. For more information about routers going down, see the section "Using AURP-Tr to Detect Routers Going Down" later in this chapter.
ロードアイランド-Updを送るデータ送付者が指定された期間以内にデータ受信装置から承認、またはロードアイランド-Ackを受け取らないなら、データ受信装置から承認を受けるまで、データ送付者はロードアイランド-Updを定期的に再送するべきです。データ送付者がいったんロードアイランド-Updを再送すると、指定された数は回それであるならロードアイランド-Ackを受けないで、それは、それがデータ送付者である一方向接続が下がっていると仮定するべきです。 落ちるルータに関する詳しい情報に関しては、後で本章でセクション「ルータを検出するのにAURP-Trを使用落ちるること」を見てください。
ROUTING INFORMATION ACKNOWLEDGMENT PACKET: When a data receiver receives an RI-Upd, it verifies the packet's connection ID and sequence number. The connection ID must be the same as that in the Open-Req for the connection. The sequence number must be either:
経路情報確認応答パケット: データ受信装置がロードアイランド-Updを受けるとき、それはパケットの接続IDと一連番号について確かめます。 接続に、接続IDはオープン-Reqのそれと同じであるに違いありません。 一連番号はどちらかであるに違いありません:
the last sequence number received, indicating that the previous
acknowledgment was lost or delayed, and that this is a duplicate
RI-Upd
前の承認が失われたか、または遅れて、これが写しロードアイランド-Updであることを示して、受け取られた最後の一連番号
the next number in the sequence, indicating that the RI-Upd
contains new routing information
ロードアイランド-Updが新しいルーティング情報を含むのを示す系列の次の数
If the sequence number has any other value, the data receiver ignores the RI-Upd. Once the data receiver has verified the RI-Upd packet's connection ID and sequence number, it responds by sending a Routing Information Acknowledgment packet, or RI-Ack, which contains the following information:
一連番号に他の値があるなら、データ受信装置はロードアイランド-Updを無視します。 データ受信装置がいったんロードアイランド-Updパケットの接続IDと一連番号について確かめると、以下の情報を含む経路情報Acknowledgmentパケット、またはロードアイランド-Ackを送ることによって、応じます:
Connection ID: The connection ID is the same as that in the RI-Upd packet.
接続ID: 接続IDはロードアイランド-Updパケットのそれと同じです。
Sequence number: The sequence number is the same as that in the RI- Upd packet.
一連番号: 一連番号はロードアイランドUpdパケットのそれと同じです。
Oppenheimer [Page 31] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[31ページ]RFC1504Appletalk
Figure 3-12 shows a data receiver responding to an RI-Upd by sending an RI-Ack.
図3-12は、データ受信装置がロードアイランド-Ackを送ることによってロードアイランド-Updに応じるのを示します。
<<Figure 3-12 A routing-information update/acknowledgment dialog>>
<<数値3-12Aルーティング情報アップデート/承認対話>>。
When a data sender receives an RI-Ack, it verifies that the RI-Ack corresponds to the outstanding RI-Upd-that is, both packets have the same connection ID and sequence number. Once the data sender has verified the information in the RI-Ack, it responds by sending the next RI-Upd in the sequence, if any.
aデータ送付者がロードアイランド-Ackを受け取るとき、ロードアイランド-Ackが傑出に対応することを確かめる、そうするロードアイランドUpd、両方、パケットには、同じ接続IDと一連番号があります。 データ送付者がいったんロードアイランド-Ackの情報について確かめると、それは、系列でもしあれば次のロードアイランド-Updを送ることによって、応じます。
Routing-Information Update Events
経路情報アップデートイベント
An RI-Upd packet may contain any of five different types of routing- information update events. The following sections describe these events.
ロードアイランド-Updパケットは5つの異なったタイプのルーティング情報アップデートイベントのいずれも含むかもしれません。 以下のセクションはこれらのイベントについて説明します。
NETWORK ADDED EVENT: An exterior router sends a Network Added (NA) event under the following circumstances:
ネットワークはイベントを加えました: 外のルータはNetwork Added(NA)イベントを以下の状況の下に送ります:
A new network that appears in the exterior router's routing table
is in the exterior router's local internet and is not hidden-that
is, it is an exported network.
外のルータの経路指定テーブルに現れる新しいネットワークが外のルータの地方のインターネットにはあって、すなわち、それは隠されない、エクスポートしているネットワーク。
The port through which an exterior router accesses a network
changes from a tunneling port to another port on the router
and the network is not hidden.
外のルータがネットワークにアクセスするポートはルータでトンネリングポートから別のポートに変化します、そして、ネットワークは隠されません。
If a network in an exterior router's routing table becomes accessible across the tunnel, the exterior router does not send an NA event. An exterior router sends only split-horizoned routing information to other exterior routers on the tunnel.
外のルータの経路指定テーブルのネットワークがトンネルの向こう側にアクセスしやすくなるなら、外のルータはNAイベントを送りません。 外のルータはトンネルで分裂でhorizonedされたルーティング情報だけを他の外のルータに送ります。
An NA event lists the network numbers associated with the new network and the network's distance in hops. Another exterior router can request the zone information associated with the new network at any time by sending a ZI-Req, once it receives an RI-Upd containing an NA event for the network.
NAイベントはホップで新しいネットワークとネットワークの距離に関連しているネットワーク・ナンバーを記載します。 別の外のルータはいつでもZI-Reqを送ることによって、新しいネットワークに関連しているゾーン情報を要求できます、ネットワークのためのNAイベントを含んでいて、いったんロードアイランド-Updを受けると。
When using AURP-Tr, an exterior router can request zone information for new networks by setting the SZI bit in an RI-Ack that it sends in response to an RI-Upd. If a data sender receives an RI-Ack with its SZI flag set to 1, the data sender sends the zone information associated with each new network for which it sent an NA event in the RI-Upd.
AURP-Trを使用するとき、外のルータは、それがロードアイランド-Updに対応して送るロードアイランド-AckにSZIビットをはめ込むことによって、新しいネットワークのためのゾーン情報を要求できます。 データ送付者がSZI旗のセットでロードアイランド-Ackを1に受け取るなら、データ送付者はそれがロードアイランド-UpdでNAイベントを送ったそれぞれの新しいネットワークに関連しているゾーン情報を送ります。
Figure 3-13 shows a data receiver responding to an RI-Upd by sending an RI-Ack in which the SZI bit is set to 1, optimizing the flow of
SZIビットは1に設定されます、流れを最適化してどれについて図3-13は、データ受信装置がロードアイランド-Ackを送ることによってロードアイランド-Updに応じるのを示すか。
Oppenheimer [Page 32] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[32ページ]RFC1504Appletalk
zone information by causing the data sender to respond with a ZI-Rsp.
データ送付者がZI-Rspと共に応じることを引き起こすのによるゾーン情報。
<<Figure 3-13 An optimized flow of zone information>>
<<数値3-13Anはゾーン情報>>の流れを最適化しました。
NETWORK DELETED EVENT: An exterior router sends a Network Deleted (ND) event if an exported network that was formerly accessible through its local internet no longer appears in its routing table. An ND event lists the network numbers associated with the deleted network.
ネットワークはイベントを削除しました: 以前地方のインターネットを通してアクセスしやすかったエクスポートしているネットワークがもう経路指定テーブルに現れないなら、外のルータはNetwork Deleted(ノースダコタ)イベントを送ります。 ノースダコタイベントは削除されたネットワークに関連しているネットワーク・ナンバーを記載します。
NETWORK ROUTE CHANGE EVENT: An exterior router sends a Network Route Change (NRC) event if the path to an exported network through its local internet changes to a path through a tunneling port, causing split-horizoned processing to eliminate that network's routing information. An NRC event lists the network numbers associated with the network to which the path changed.
ルート変化イベントをネットワークでつないでください: 地方のインターネットを通したエクスポートしているネットワークへの経路がトンネリングポートを通して経路に変化するなら、外のルータはNetwork Route Change(NRC)イベントを送ります、分裂でhorizonedされた処理がそのネットワークのルーティング情報を排除することを引き起こして。 NRCイベントは経路が変化したネットワークに関連しているネットワーク・ナンバーを記載します。
NETWORK DISTANCE CHANGE EVENT: An exterior router sends a Network Distance Change (NDC) event if the distance to an exported network accessible through its local internet changes. An NDC event indicates the network to which the distance changed and the network's distance in hops. An exterior router must send an NDC event even if the distance to a network changes to 15 hops. The exterior router that receives an NDC event with a hop count of 15 should process that event just as it would an ND event.
距離変化イベントをネットワークでつないでください: 地方のインターネットを通してアクセスしやすいエクスポートしているネットワークへの距離が変化するなら、外のルータはNetwork Distance Change(NDC)イベントを送ります。 NDCイベントはホップで距離が変化したネットワークとネットワークの距離を示します。 ネットワークへの距離が15のホップに変化しても、外のルータはNDCイベントを送らなければなりません。 ちょうどノースダコタイベントを処理するように15のホップカウントでNDCイベントを受ける外のルータはそのイベントを処理するべきです。
ZONE NAME CHANGE EVENT: This event is reserved for future use.
ゾーン改名イベント: このイベントは今後の使用のために予約されます。
Processing Update Events
処理アップデートイベント
According to the architectural model, a data receiver that is processing an event contained in an RI-Upd packet updates the corresponding information in its central routing table. For example, if a data receiver receives an RI-Upd containing an ND event or an NRC event, it sets the corresponding network's routing-table entry to BAD. The data receiver then initiates a notify-neighbor process, by sending RTMP data packets that identify bad entries in its routing table to routers on its local internet.
建築モデルに従って、イベントがロードアイランド-Updパケットに含んだ処理であるデータ受信装置は中央の経路指定テーブルの対応する情報をアップデートします。 例えば、ノースダコタイベントかNRCイベントを含んでいて、データ受信装置がロードアイランド-Updを受けるなら、それは対応するネットワークの経路指定テーブルエントリーをBADに設定します。 次に、データ受信装置は隣人に通知しているプロセスを開始します、地方のインターネットで経路指定テーブルで悪いエントリーをルータに特定するデータ・パケットをRTMPに送ることによって。
Processing Inconsistent Update Events
矛盾したアップデートイベントを処理します。
If the data receiver's copy of the data sender's routing table does not match that in the data sender's current routing table, it is possible that the data receiver might receive an RI-Upd containing an event that is incongruous with its current routing-table information. For example, this might occur if the information in the data sender's routing table were changing during its initial exchange of routing information with the data receiver, as described in the section
データ送付者の経路指定テーブルに関するデータ受信装置のコピーがデータ送付者の現在の経路指定テーブルでそれに合っていないなら、現在の経路指定テーブル情報と不適当なイベントを含んでいて、データ受信装置がロードアイランド-Updを受けるのは、可能です。 例えば、データ送付者の経路指定テーブルの情報がデータ受信装置によるルーティング情報の初期の交換の間、変化するなら、これは起こるでしょうに、セクションで説明されるように
Oppenheimer [Page 33] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[33ページ]RFC1504Appletalk
"Sending Updates Following the Initial Exchange of Routing Information" earlier in this chapter. The data receiver might receive an RI-Upd that contains an ND, NRC, or NDC event for a network not known to be in the data sender's routing table; or an NA event for a network already known to be in its routing table. The data receiver should
より早く本章で「経路情報のInitial ExchangeをUpdates Followingに送ります」。 データ受信装置はデータ送付者の経路指定テーブルにあるのは知られないネットワークのためのノースダコタ、NRC、またはNDCイベントを含むロードアイランド-Updを受けるかもしれません。 または、経路指定テーブルにあるのが既に知られていたネットワークのためのNAイベント。 データ受信装置はそうするべきです。
ignore ND and NRC events for unknown networks
未知のネットワークのためにノースダコタとNRCイベントを無視してください。
process an NDC event for an unknown network as an NA event
未知のネットワークのためにNAイベントとしてNDCイベントを処理してください。
process an NA event for a known network as an NDC event
知られているネットワークのためにNDCイベントとしてNAイベントを処理してください。
Maintaining a Central Routing Table
中央の経路指定テーブルを維持します。
According to the architectural model, an exterior router maintains a separate routing table for each other exterior router on a tunnel. In a typical implementation, however, an exterior router maintains a central routing table that contains information about each path to each network known to that exterior router-including its port, next internet router (IR), and distance in hops.
建築モデルに従って、外のルータは、トンネルの上で互いのための別々の経路指定テーブルが外のルータであることを支持します。 しかしながら、典型的な実装では、外のルータはホップにポートをルータで含むその外部に知られている各ネットワーク、次のインターネットルータ(IR)、および距離に各経路の情報を含む中央の経路指定テーブルを維持します。
If no loops exist across a tunnel, an exterior router can reach a network that is accessible through that tunnel through only one exterior router, as shown in Figure 3-14. Such a network is accessible neither through the exterior router's local internet nor through any other exterior router on the tunnel. Thus, the central routing table would contain only one path for that network.
輪が全くトンネルの向こう側に存在していないなら、外のルータは1つの外のルータだけを通してそのトンネルを通ってアクセスしやすいネットワークに達することができます、図3-14に示されるように。 そのようなネットワークは外のルータの地方のインターネットもトンネルの上のいかなる他の外でないルータもを通してアクセスしやすいです。 したがって、中央の経路指定テーブルはそのネットワークのための1つの経路だけを含んでいるでしょう。
If a loop exists across a tunnel, an exterior router may be able to access a network through two or more exterior routers on the tunnel, or through both its local internet and an exterior router. Thus, when a loop exists across a tunnel, the central routing table may contain more than one path for each network. Figure 3-14 shows two examples of internets on which loops exist.
輪がトンネルの向こう側に存在しているなら、外のルータはトンネルの上の2つ以上の外のルータを通して、または、地方のインターネットと外のルータの両方を通してネットワークにアクセスできるかもしれません。 輪がトンネルの向こう側に存在するとき、したがって、中央の経路指定テーブルは各ネットワークあたり1つ以上の経路を含むかもしれません。 図3-14は輪が存在するインターネットに関する2つの例を示しています。
<<Figure 3-14 Internets with and without loops>>
<<数値3-14輪の>>のあるなしにかかわらずInternets
Maintaining an Alternative-Paths List
迂回経路リストを維持します。
If a loop exists across a tunnel and an exterior router maintains a single central routing table, that table must include an alternative-paths list for each network known to the exterior router. This alternative-paths list contains the routing information that an exterior router might otherwise maintain in separate routing tables for the other exterior routers on a tunnel. An entry for each alternative path to a network consists of the address of the alternative next IR for that network and the network's distance
輪がトンネルの向こう側に存在していて、外のルータが単一の中央の経路指定テーブルを維持するなら、そのテーブルは外のルータに知られている各ネットワークのための迂回経路リストを含まなければなりません。 この迂回経路リストは外のルータが他の外のルータのために別の方法でトンネルの上で別々のルーティングでテーブルを維持するかもしれないというルーティング情報を含んでいます。 ネットワークへの各迂回経路のためのエントリーはそのネットワークとネットワークの距離への次の代替のIRのアドレスから成ります。
Oppenheimer [Page 34] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[34ページ]RFC1504Appletalk
through that next IR.
その次のIRで。
Because RTMP periodically retransmits information about alternative paths, the exterior router's alternative-paths list needs to provide information only about alternative paths to networks across tunneling ports. Thus, the alternative-paths list for a network provides complete information about all paths to that network across tunnels- but not necessarily about all paths through the exterior router's local internet.
RTMPが定期的に迂回経路の情報を再送するので、外のルータの迂回経路リストは、トンネリングポートの向こう側に迂回経路だけの情報をネットワークに提供する必要があります。 したがって、ネットワークのための迂回経路リストは、外のルータの地方のインターネットを通してすべての経路に関してトンネルの向こう側にすべての経路の完全な情報をそのネットワークに提供しますが、必ず提供するというわけではありません。
An exterior router must maintain an alternative-paths list, because once a data sender has reliably sent routing information to a data receiver, the data sender does not retransmit that information. Even though a path may not currently be the optimal path to a network, an exterior router must maintain information about that path, in the event that it later becomes the optimal path.
外のルータは迂回経路リストを維持しなければなりません、データ送付者がいったんルーティング情報をデータ受信装置に確かに送ると、データ送付者がその情報を再送しないので。 現在、経路はネットワークへの最適経路でないかもしれませんが、外のルータはその経路の情報を保守しなければなりません、後で最適経路になる場合。
NOTE: Zone information is unaffected by the path taken to a network. Therefore, an exterior router need not maintain duplicate zone information in the alternative-paths list.
以下に注意してください。 ゾーン情報はネットワークに取られた経路のそばで影響を受けないです。 したがって、外のルータは迂回経路リストの写しゾーン情報を保守する必要はありません。
Using the Alternative-Paths List in Event Processing
イベント処理に迂回経路リストを使用します。
An exterior router uses its alternative-paths list when processing events.
イベントを処理するとき、外のルータは迂回経路リストを使用します。
PROCESSING A NETWORK ADDED EVENT: If an exterior router receives an NA event, it searches its central routing table for the network indicated in the event.
ネットワークを処理すると、イベントは加えました: 外のルータがNAイベントを受けるなら、それはイベントで示されたネットワークのために中央の経路指定テーブルを捜します。
If the exterior router finds no entry for that network in its
central routing table, it creates a new entry using the routing
information contained in the NA event.
外のルータが中央の経路指定テーブルのそのネットワークに関してエントリーを全く見つけないなら、それは、NAイベントに含まれたルーティング情報を使用することで新しいエントリーを作成します。
If the exterior router finds an existing entry for that network in
its central routing table and the next IR for that entry is not
the exterior router that sent the event, it determines whether the
NA event provides a better path to that network.
外のルータが中央の経路指定テーブルのそのネットワークに関して既存のエントリーを見つけて、そのエントリーのための次のIRがイベントを送った外のルータでないなら、それは、NAイベントが、より良い経路をそのネットワークに提供するかどうか決定します。
If the NA event provides a better path to the network or the
state of the routing-table entry for that network is BAD, the
exterior router replaces the current entry with the routing
information contained in the NA event. In the current entry, if
the path to the network is through a tunnel, as indicated by
the next IR, the exterior router transfers the current entry to
the network's alternative-paths list.
NAイベントが、より良い経路をネットワークに提供するか、そのネットワークのための経路指定テーブルエントリーの状態がBADであるなら、外のルータは現在のエントリーをNAイベントに含まれたルーティング情報に取り替えます。 現在のエントリーでは、トンネルを通ってネットワークへの経路が次のIRで示されるようにあるなら、外のルータがネットワークの迂回経路リストに現在のエントリーを移します。
If the NA event does not provide a better path to the network,
NAイベントが、より良い経路をネットワークに提供しないなら
Oppenheimer [Page 35] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[35ページ]RFC1504Appletalk
the exterior router adds the routing information contained in
the NA event to the alternative-paths list for the network.
外のルータはNAイベントにネットワークのための迂回経路リストに含まれたルーティング情報を加えます。
If the exterior router finds an existing entry for that network,
in which the next IR is the exterior router that sent the event,
the exterior router should process the NA event just as it would
an NDC event.
外のルータがそのネットワーク(次のIRはイベントを送った外のルータである)に関して既存のエントリーを見つけるなら、ちょうどNDCイベントを処理するように外のルータはNAイベントを処理するべきです。
PROCESSING A NETWORK DELETED EVENT: If an exterior router receives an ND event, it searches its central routing table for the network indicated in the event.
ネットワークを処理すると、イベントは削除されました: 外のルータがノースダコタイベントを受けるなら、それはイベントで示されたネットワークのために中央の経路指定テーブルを捜します。
If the exterior router finds no entry for that network in its
central routing table, it ignores the event. See the section
"Processing Inconsistent Update Events" earlier in this chapter.
外のルータが中央の経路指定テーブルのそのネットワークに関してエントリーを全く見つけないなら、それはイベントを無視します。 より早く本章で「処理の矛盾したアップデートイベント」というセクションを見てください。
If the exterior router that is the data receiver determines that
the exterior router that sent the ND event is the next IR for that
network and there is an alternative-paths list for the network, the
data receiver replaces the network's current routing information
with the entry in the network's alternative-paths list that
provides the shortest distance to that network and removes that
entry from the network's alternative-paths list. If the network's
alternative-paths list contains more than one entry providing the
distance that constitutes the shortest distance to the network, the
data receiver can use any of those entries.
データ受信装置である外のルータが、ノースダコタイベントを送った外のルータがそのネットワークのための次のIRであることを決定して、ネットワークのための迂回経路リストがあれば、データ受信装置はネットワークの現在のルーティング情報をそのネットワークに最短距離を提供して、ネットワークの迂回経路リストからそのエントリーを移すネットワークの迂回経路リストにおけるエントリーに取り替えます。 ネットワークの迂回経路リストが最短距離をネットワークに構成する距離を提供する1つ以上のエントリーを含んでいるなら、データ受信装置はそれらのエントリーのいずれも使用できます。
If the exterior router that is the data receiver determines that
the exterior router that sent the ND event is the next IR for that
network and there is no alternative-paths list for the network, the
data receiver sets the network's routing-table entry to BAD, then
initiates a notify-neighbor process.
データ受信装置である外のルータが、ノースダコタイベントを送った外のルータがそのネットワークのための次のIRであることを決定して、ネットワークのための迂回経路リストが全くなければ、データ受信装置は、ネットワークの経路指定テーブルエントリーをBADに設定して、隣人に通知しているプロセスを開始します。
If the exterior router that is the data receiver determines that
the exterior router that sent the ND event is not the next IR for
that network, the data receiver searches that network's
alternative-paths list for an entry in which the next IR is the
data sender and removes that entry from the list.
データ受信装置である外のルータが、ノースダコタイベントを送った外のルータがそのネットワークのための次のIRでないことを決定するなら、データ受信装置は、次のIRがデータ送付者であるエントリーとしてそのネットワークの迂回経路リストを捜して、リストからそのエントリーを移します。
PROCESSING A NETWORK ROUTE CHANGE EVENT: If an exterior router receives an NRC event, it processes that event as an ND event. Generally, an NRC event should not cause an exterior router to set the state of a network's routing-table entry to BAD. An NRC event indicates that the data sender has an alternative path to the network through the tunnel. The data receiver either is already aware of or will soon discover this alternative path.
ネットワークルートを処理して、イベントを変えてください: 外のルータがNRCイベントを受けるなら、それはノースダコタイベントとしてそのイベントを処理します。 一般に、NRCイベントで、外のルータはネットワークの経路指定テーブルエントリーの状態をBADに設定するべきではありません。 NRCイベントは、データ送付者がトンネルを通ってネットワークに迂回経路を持っているのを示します。 どちらかが既に意識しているか、またはすぐそうするデータ受信装置はこの迂回経路を発見します。
Oppenheimer [Page 36] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[36ページ]RFC1504Appletalk
PROCESSING A NETWORK DISTANCE CHANGE EVENT: If an exterior router receives an NDC event with a hop count of 15, it processes that event just as it would an ND event. Otherwise, it searches its central routing table for the network indicated in the event.
ネットワーク距離を処理して、イベントを変えてください: 外のルータが15のホップカウントでNDCイベントを受けるなら、それはちょうどノースダコタイベントを処理するようにそのイベントを処理します。 さもなければ、それはイベントで示されたネットワークのために中央の経路指定テーブルを捜します。
If the exterior router finds no entry for that network in its
central routing table, it processes that event as an NA event.
外のルータが中央の経路指定テーブルのそのネットワークに関してエントリーを全く見つけないなら、それはNAイベントとしてそのイベントを処理します。
If the exterior router that is the data receiver determines that
the exterior router that sent the NDC event is the next IR for the
network, the data receiver replaces the distance to that network
that is currently in its central routing table with the distance
indicated in the NDC event.
データ受信装置である外のルータが、NDCイベントを送った外のルータがネットワークのための次のIRであることを決定するなら、データ受信装置は現在、距離がNDCイベントで示されている中央の経路指定テーブルにあるそのネットワークに距離を置き換えます。
If the exterior router that is the data receiver determines that
the exterior router that sent the NDC event is not the next IR for
the network, the data receiver
外のルータであるなら、すなわち、データ受信装置は、NDCイベントを送った外のルータがネットワークのための次のIRでないことを決定します、データ受信装置
replaces the distance in the corresponding entry in the network's
alternative-paths list with the distance indicated in the NDC event
creates an entry in the alternative-paths list that contains the
routing information in the NDC event, if it finds no entry for that
network in the alternative-paths list
距離がNDCイベントで示されているリストがエントリーを全く見つけないならNDCイベントにおけるルーティング情報を含む迂回経路リストにおけるエントリーを作成するネットワークの迂回経路での迂回経路のネットワークが記載する対応するエントリーで距離を置き換えます。
Finally, regardless of whether the central routing table indicates that the exterior router that sent the NDC event is the network's next IR, the data receiver compares the distances in entries in the network's alternative-paths list to the distance in its central routing table. If an entry in the alternative-paths list contains a shorter path to the network, the exterior router transfers that entry to the central routing table. This ensures that the exterior router's central routing table contains the shortest path to the network.
最終的に、中央の経路指定テーブルが、NDCイベントを送った外のルータがネットワークの次のIRであることを示すかどうかにかかわらず、データ受信装置はネットワークの迂回経路リストにおけるエントリーで中央の経路指定テーブルの距離に距離をたとえます。 迂回経路リストにおけるエントリーが、より短い経路をネットワークに含んでいるなら、外のルータはそのエントリーを中央の経路指定テーブルに移します。 これは、外のルータの中央の経路指定テーブルがネットワークに最短パスを含むのを確実にします。
If the data receiver replaces the entry currently in its central
routing table with that in the NDC event and the current entry
provides a path to the network through a tunnel, the data receiver
transfers the current entry to the network's alternative-paths
list.
データ受信装置が現在、中央の経路指定テーブルでNDCイベントでエントリーをそれに取り替えて、現在のエントリーがトンネルを通して経路をネットワークに提供するなら、データ受信装置はネットワークの迂回経路リストに現在のエントリーを移します。
If the data receiver transfers an entry in the network's
alternative-paths list to its central routing table, it removes
that entry from the alternative-paths list.
データ受信装置がネットワークの迂回経路リストにおけるエントリーを中央の経路指定テーブルに移すなら、それは迂回経路リストからそのエントリーを取り除きます。
RESPONDING TO EVENTS IN THE LOCAL INTERNET: An exterior router that uses AURP must respond appropriately to events that originate in its local internet. Such events occur when the routing information for a network in the exterior router's local internet changes and another path to that network exists through the tunnel. An exterior router
ローカルのインターネットにおけるイベントに以下を反応させること。 AURPを使用する外のルータは適切に地方のインターネットで起こるイベントに応じなければなりません。 外のルータの地方のインターネット変化におけるネットワークとそのネットワークへの別の経路のためのルーティング情報がトンネルを通って存在していると、そのようなイベントは起こります。 外のルータ
Oppenheimer [Page 37] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[37ページ]RFC1504Appletalk
handles such events as follows:
ハンドル、以下のそのようなイベント:
If the exterior router replaces the current routing-table entry for
a network with routing information provided by an event originating
in its local internet-that is, provided by RTMP-and the current
path to the network is through a tunnel, the exterior router
transfers the current entry to the network's alternative-paths
list.
そして、外のルータがネットワークのために現在の経路指定テーブルエントリーをすなわち、提供された地方のインターネットで起こるイベントで提供するルーティング情報に取り替える、RTMP、-、トンネルを通ってネットワークへの現在の経路があって、外のルータはネットワークの迂回経路リストに現在のエントリーを移します。
If the exterior router sets the state of a routing-table entry to
BAD or removes an entry from its central routing table, the
exterior router replaces that entry with the entry in the
alternative-paths list that provides the shortest distance to the
network in the entry being replaced.
外のルータが経路指定テーブルエントリーの状態をBADに設定するか、または中央の経路指定テーブルからエントリーを移すなら、外のルータはそのエントリーを取り替えられるエントリーにおけるネットワークに最短距離を提供する迂回経路リストにおけるエントリーに取り替えます。
If the distance to a network in the exterior router's local
internet changes, the exterior router compares the distances in
entries in the network's alternative-paths list to the distance in
its central routing table. If an entry in the alternative-paths
list provides a shorter distance to the network, the exterior
router transfers that entry to its central routing table. This
ensures that the exterior router's central routing table contains
the shortest path to the network.
外のルータの地方のインターネットにおけるネットワークへの距離が変化するなら、外のルータはネットワークの迂回経路リストにおけるエントリーで中央の経路指定テーブルの距離に距離をたとえます。 迂回経路リストにおけるエントリーが、より短い距離をネットワークに提供するなら、外のルータはそのエントリーを中央の経路指定テーブルに移します。 これは、外のルータの中央の経路指定テーブルがネットワークに最短パスを含むのを確実にします。
Router-Down Notification
下にルータ通知
Prior to going down, or becoming inactive, an exterior router must notify all other exterior routers in its informed-routers list that it is going down. An exterior router does this by using the underlying transport-layer service to close its connection with each exterior router.
落ちるか、または不活発になる前に、外のルータは、知識があるルータリストでそれが落ちる予定であるように他のすべての外のルータに通知しなければなりません。 外のルータは、それぞれの外のルータとの関係を終えるのに基本的なトランスポート層サービスを利用することによって、これをします。
Sending a Router Down Packet
ルータ下にパケットを送ります。
Optionally, an exterior router can send a Router Down packet, or RD packet, to each exterior router before it goes down. An RD packet contains an error code that indicates the exterior router's reason for terminating its connection with each exterior router.
任意に、落ちる前に外のルータはそれぞれの外のルータへのRouter Downパケット、またはRDパケットを送ることができます。 RDパケットは外のルータのそれぞれの外のルータとの関係を終える理由を示すエラーコードを含んでいます。
Generally, only the exterior router functioning as the data sender on a one-way connection sends RD packets. However, if just a single one-way connection exists between two exterior routers, the exterior router functioning as the data receiver on that connection can send an RD packet.
一方向接続のときにデータ送付者として機能する外のルータだけがパケットをRDに送ります。 しかしながら、まさしく単独の一方向接続が2つの外のルータの間に存在しているなら、その接続のときにデータ受信装置として機能する外のルータはRDパケットを送ることができます。
Using AURP-Tr to Notify Other Routers That a Router Is Going Down
ルータが落ちているように他のルータに通知するのにAURP-Trを使用します。
When using AURP-Tr, an exterior router sends an RD packet to
AURP-Trを使用して、外のルータはRDパケットをいつに送りますか。
Oppenheimer [Page 38] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[38ページ]RFC1504Appletalk
notify another exterior router that it is terminating a connection
接続を終えているように別の外のルータに通知してください。
pass an error code that indicates its reason for terminating the
connection
接続を終える理由を示すエラーコードを通過してください。
As shown in Figure 3-15, once the data receiver verifies the RD packet's connection ID, it acknowledges that it received the RD packet by sending an RI-Ack. Then, the data sender terminates the connection.
図3-15に示されるように、データ受信装置がいったんRDパケットの接続IDについて確かめると、それは、ロードアイランド-Ackを送ることによってRDパケットを受けたと認めます。 そして、データ送付者は接続を終えます。
<<Figure 3-15 Acknowledging an RD packet>>
RDパケット>>あたりの<<図3-15Acknowledging
If a Router Goes Down Without Notifying Other Routers
ルータが他のルータに通知しないで落ちるなら
If an exterior router crashes or goes down without sending an RD packet, or becomes inaccessible due to a network problem, other exterior routers on the tunnel must be able to discover that the exterior router is down. Generally, the underlying transport-layer service provides a mechanism for informing an exterior router that an exterior router in its informed-routers list has gone down or become inaccessible.
外のルータがRDパケットを送らないでダウンするか、落ちる、またはネットワーク問題のために近づきがたくなるなら、トンネルの上の他の外のルータは、外のルータが下がっていると発見できなければなりません。 一般に、知識があるルータリストの外のルータが落ちるか、または近づきがたくなったことを外のルータに知らせるのに基本的なトランスポート層サービスはメカニズムを提供します。
If an exterior router determines that another exterior router is down, it must
外のルータが、別の外のルータが下がっていることを決定するなら、それは決定しなければなりません。
remove that exterior router from its informed-routers list
知識があるルータリストからその外のルータを取り除いてください。
remove that exterior router's routing information from all of its
routing tables
経路指定テーブルのすべてからその外のルータのルーティング情報を取り除いてください。
close any one-way connections with that exterior router
その外のルータとのあらゆる一方向関係を終えてください。
If an exterior router rediscovers an exterior router that had previously gone down, it must again exchange initial routing information with that exterior router.
外のルータが以前に落ちた外のルータを再発見するなら、それは再びその外のルータと初期のルーティング情報を交換しなければなりません。
Using AURP-Tr to Detect Routers Going Down
ルータを検出するのにAURP-Trを落ちる使用すること。
An exterior router using AURP-Tr associates a last-heard-from timer with each exterior router from which it has received routing information-that is, with each one-way connection on which it is the data receiver. Each time the exterior router receives an RI-Rsp, RI- Upd, or ZI-Rsp over a connection-verifying that its connection with the data sender is still active-it resets the last-heard-from timer for that connection.
AURP-Trを使用する外のルータがそれがルーティングを受けたそれぞれの外のルータに最後に聞かれたタイマを関連づける、すなわち、情報、それぞれ道の接続、受信機データEachがそれがどれであるかに関して外のルータを調節するかがデータ送付者との接続がまだそうであるa接続検証の上にロードアイランド-Rsp、ロードアイランドUpdかZI-Rspを受ける、アクティブである、-、それ、その接続のための最後に聞かれたタイマをリセットします。
For each one-way connection on which it is the data receiver, the exterior router has a last-heard-from timeout value. If a
それがデータ受信装置であるそれぞれ道の接続のために、外のルータには、最後に聞かれたタイムアウト値があります。 aです。
Oppenheimer [Page 39] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[39ページ]RFC1504Appletalk
connection's last-heard-from timer reaches that timeout value, the data receiver sends a Tickle packet over that connection. If the data sender on the connection is still accessible, it responds with a Tickle-Ack, as shown in Figure 3-16. When the data receiver receives the Tickle-Ack, it resets the last-heard-from timer for that connection. If the data receiver receives no Tickle-Ack-even after retransmitting the Tickle several times-it assumes that the connection is down.
接続の最後に聞かれたタイマはそのタイムアウト値に達して、データ受信装置はその接続の上にTickleパケットを送ります。 接続でのデータ送付者がまだアクセスしやすいなら、それはTickle-Ackと共に図3-16に示されるように応じます。 データ受信装置がTickle-Ackを受けるとき、それはその接続のための最後に聞かれたタイマをリセットします。 データ受信装置が再送した後にTickle-Ackさえ受けない、Tickle、何度か、-、それ、接続が下がっていると仮定します。
<<Figure 3-16 Acknowledging a Tickle packet>>
Tickleパケット>>あたりの<<図3-16Acknowledging
If the exterior router determines that the connection is down and an associated one-way connection exists on which it is the data sender, it should send a null RI-Upd over that connection to determine whether that one-way connection is still active.
外のルータが、接続が下がっていることを決定して、それがデータ送付者である関連一方向接続が存在しているなら、それは、その一方向接続がまだ活発であるかどうか決定するためにヌルロードアイランド-Updをその接続の上に送るべきです。
If the data receiver on the connection is still accessible, it responds with an RI-Ack, as shown in Figure 3-17. If the data sender receives no RI-Ack-even after retransmitting the null RI-Upd several times-it determines that the one-way connection on which it is the data sender is also down.
接続でのデータ受信装置がまだアクセスしやすいなら、それはロードアイランド-Ackと共に図3-17に示されるように応じます。 データ送付者が、いいえを受ける、ロードアイランドAck、同等である、再送した後、ヌルロードアイランド-Upd、何度か、-、それ、また、それがデータ送付者である一方向接続も下がっていることを決定します。
<<Figure 3-17 Acknowledging an RI-Upd packet>>
ロードアイランド-Updパケット>>あたりの<<図3-17Acknowledging
The value of the last-heard-from timeout should be configurable. The minimum last-heard-from timeout should be 30 seconds. If a connection's last-heard-from timeout is greater than two minutes-the tickle-before-data time-and the data receiver has not reset the connection's last-heard-from timer for at least this tickle-before- data time, the data receiver must send a Tickle to the data sender before forwarding an AppleTalk data packet to it. If the data sender on the connection is still accessible, it responds with a Tickle-Ack. When the data receiver receives the Tickle-Ack, it resets the last- heard-from timer for that connection. If the data receiver receives no Tickle-Ack, even after retransmitting the Tickle, it assumes that the data sender is no longer accessible and closes the connection.
最後に聞かれたタイムアウトの値は構成可能であるべきです。 最小の最後に聞かれたタイムアウトは30秒であるべきです。 そして、接続の最後に聞かれたタイムアウトが2以上である、分、-、データの前にくすぐってください、時間、-、データ受信装置は少なくともこれのために-以前データ時間をくすぐって接続の最後に聞かれたタイマをリセットしていなくて、AppleTalkデータ・パケットをそれに送る前に、データ受信装置はデータ送付者にTickleを送らなければなりません。 接続でのデータ送付者がまだアクセスしやすいなら、それはTickle-Ackと共に応じます。 データ受信装置がTickle-Ackを受けるとき、それはその接続のための最後の聞かれたタイマをリセットします。 Tickleを再送さえした後にさえデータ受信装置がTickle-Ackを全く受けないなら、それは、データ送付者がもうアクセスしやすくないと思って、接続を終えます。
Obtaining Zone Information
ゾーン情報を得ます。
AURP supports two commands that allow an exterior router to obtain routing information for zones rather than for networks-the Get Domain Zone List (GDZL) command and the Get Zone Nets (GZN) command. These commands constitute request/response transactions, and are similar to ZI-Req and ZI-Rsp. An exterior router sends these commands unsequenced over a connection.
AURPが外のルータがむしろゾーンのためのルーティング情報を得ることができる2つのコマンドをサポートする、ネットワーク、-、Get Domain Zone List(GDZL)コマンドとGet Zoneネット(GZN)は命令します。 これらのコマンドは、要求/応答トランザクションを構成して、ZI-ReqとZI-Rspと同様です。 外のルータは接続の上で非配列されたこれらのコマンドを送ります。
NOTE: Under AURP, the implementation of the Get Domain Zone List command and the Get Zone Nets command in an exterior router is
以下に注意してください。 AURPの下では、外のルータにおけるGet Domain Zone ListコマンドとGet Zoneネットコマンドの実装はそうです。
Oppenheimer [Page 40] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[40ページ]RFC1504Appletalk
optional. However, an exterior router must at least be able to return an error to a GDZL-Req or a GZN-Req.
任意。 しかしながら、外のルータはGDZL-ReqかGZN-Reqに誤りを少なくとも返すことができなければなりません。
Get Domain Zone List Command
ドメインゾーンリストコマンドを得てください。
The Get Domain Zone List command, or GDZL, allows an exterior router to obtain a zone list for an internet. As shown in Figure 3-18, GDZL functions similarly to the ZIP GetZoneList command. However, a GDZL- Rsp returns a split-horizoned zone list-that is, it returns only the zones in the exterior router's local internet, rather than the exterior router's entire zone list. A GDZL-Rsp does not return zones in networks that are accessible through the tunnel, unless those zones are also in networks that are accessible through the exterior router's local internet.
Get Domain Zone Listコマンド、またはGDZLが外のルータにインターネットのためのゾーンリストを得させます。 図3-18に示されるように、GDZLは同様にZIP GetZoneListコマンドに機能します。 しかしながら、GDZL- Rspは外のルータの全体のゾーンよりむしろ外のルータの地方のインターネットにおけるゾーンだけが記載するすなわち、それを記載されたリターンを分裂でhorizonedされたゾーンに返します。 GDZL-Rspはトンネルを通ってアクセスしやすいネットワークでゾーンを返しません、外のルータの地方のインターネットを通してアクセスしやすいネットワークにもそれらのゾーンがない場合。
<<Figure 3-18 Get Domain Zone List request/response dialog>>
<<数値3-18Get Domain Zone List要求/応答対話>>。
Get Zone Nets Command
ネットが命令するゾーンを得てください。
The Get Zone Nets command, or GZN, allows an exterior router to obtain a list of the networks in an exterior router's local internet that are associated with a particular zone name. As shown in Figure 3-19, GZN functions similarly to ZI-Req and ZI-Rsp, but a GZN-Req packet contains a single zone name and GZN-Rsp packets contain network tuples that have the same format as the tuples in an RI-Rsp. A GZN-Rsp returns network tuples only for networks that are accessible through the exterior router's local internet.
Get Zoneネットのコマンド、またはGZNが外のルータに外のルータの地方のインターネットにおける特定のゾーン名に関連しているネットワークのリストを得させます。 GZN-Reqパケットはただ一つのゾーン名を含んでいます、そして、図3-19に示されるように、GZNは同様にZI-ReqとZI-Rspに機能しますが、GZN-Rspパケットはロードアイランド-Rspにtuplesと同じ形式を持っているネットワークtuplesを含んでいます。 GZN-Rspは外のルータの地方のインターネットを通してアクセスしやすいネットワークのためだけにネットワークtuplesを返します。
<<Figure 3-19 Get Zone Nets request/response dialog>>
<<数値3-19Get Zoneネット要求/応答対話>>。
Using AURP-Tr to Process Sequence Numbers
一連番号を処理するのにAURP-Trを使用します。
When an exterior router acting as a data receiver sends an Open-Req to establish a one-way connection, it expects the data sender to respond by sending sequenced data packets, starting with the sequence number 1. The data receiver's response to each packet that it receives depends on the packet's sequence number:
データ受信装置として機能する外のルータが一方向接続を証明するためにオープン-Reqを送るとき、発信することによって反応させるデータ送付者がデータ・パケットを配列したと予想します、一連番号1から始まって。 それが受ける各パケットへのデータ受信装置の応答をパケットの一連番号に依存します:
Whenever the data receiver receives an RI-Rsp, RI-Upd, or RD packet
that has the expected sequence number and connection ID, it sends
an RI-Ack packet having that sequence number, then increases the
sequence number that it expects by one, until the sequence number
reaches 65,535. Sequence numbers wrap around and the sequence
number 0 is reserved, so the sequence number 1 follows 65,535.
Thus, when comparing sequence numbers, an exterior router
interprets the sequence number 65,535 as one less than the sequence
number 1.
データ受信装置がロードアイランド-Rsp、ロードアイランド-Upd、またはRDパケットを受けるときはいつも、それには予想された一連番号と接続IDがあって、ロードアイランド-Ackパケットにその一連番号を持たせて、次に、1で予想する一連番号を増強します、一連番号が6万5535に達するまで。 一連番号が巻きつけられて、一連番号0が予約されているので、一連番号1は6万5535に続きます。 一連番号を比較するとき、したがって、外のルータは一連番号1ほど1として一連番号65,535を解釈しません。
Oppenheimer [Page 41] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[41ページ]RFC1504Appletalk
If the data receiver expects sequence number n and receives a
packet with the sequence number n-1, that packet was delayed and is
a duplicate of another packet already received. The data receiver
must retransmit an RI-Ack packet, because the data sender may not
have received the RI-Ack packet previously sent-that is, the RI-Ack
may have been lost.
データ受信装置が一連番号n-1で一連番号nを予想して、パケットを受けるなら、そのパケットは、遅らせられて、既に受け取られた別のパケットの写しです。 データ受信装置はロードアイランド-Ackパケットを再送しなければなりません、データ送付者が以前にロードアイランド-Ackパケットを受けていないかもしれないので-送って、それがそう、ロードアイランド-Ackはなくされたかもしれません。
If the data receiver expects sequence number n and receives a
packet with the sequence number n+1, it should discard the packet
and terminate the one-way connection on which it is the data
receiver. Because AURP-Tr supports only one outstanding
transaction at a time, the receipt of such a packet indicates that
the connection is out of sync.
データ受信装置が一連番号n+1で一連番号nを予想して、パケットを受けるなら、それは、パケットを捨てて、データ受信装置である一方向接続を終えるべきです。AURP-Trが一度に1つの傑出しているトランザクションだけをサポートするので、そのようなパケットの領収書は、接続が同期しているのを示します。
If the data receiver expects sequence number n and receives a
packet with a sequence number other than n-1, n, or n+1, the packet
was delayed and is a duplicate of another packet already received.
The data receiver need not send an RI-Ack, because the data sender
must have received an RI-Ack for that sequence number prior to
sending a packet with the sequence number n-1. The data receiver
should discard the packet.
データ受信装置がn-1以外の一連番号、n、またはnで+1に一連番号nを予想して、パケットを受けるなら、パケットは、遅らせられて、既に受け取られた別のパケットの写しです。 データ受信装置はロードアイランド-Ackを送る必要はありません、一連番号n-1でパケットを送る前にデータ送付者がその一連番号のためにロードアイランド-Ackを受け取ったに違いないので。 データ受信装置はパケットを捨てるはずです。
NOTE: If the sequence numbers have not wrapped around, a sequence number greater than n+1 indicates that the connection is out of sync.
以下に注意してください。 一連番号が巻きつけられていないなら、n+1より大きい一連番号は、接続が同期しているのを示します。
Using AURP-Tr to Process Connection IDs
接続IDを処理するのにAURP-Trを使用します。
If an exterior router acting as either a data receiver or a data sender on a one-way connection receives a packet from an exterior router with which it has a one-way connection, it checks the connection ID in the packet to verify that the packet was sent on that connection. If the packet contains a connection ID that does not match that expected for the connection, the exterior router discards the packet.
データ受信装置かデータ送付者を一方向接続に機能させる外のルータがそれが一方向接続がある外のルータからパケットを受けるなら、それは、パケットがその接続に送られたことを確かめるためにパケットで接続IDをチェックします。 パケットが接続のために予想されたそれに合っていない接続IDを含んでいるなら、外のルータはパケットを捨てます。
If a data sender receives an Open-Req from an exterior router with which it already has a connection and the connection ID does not match that for the connection already established, it should not discard the packet without verifying whether the connection is still active. The receipt of such a packet may indicate that the data receiver on the connection has been restarted and has opened a new one-way connection, without first terminating its original connection. The exterior router acting as the data sender should send a null RI-Upd over the connection to determine whether it is still active. If the data sender receives an RI-Ack in response to the null RI-Upd, it discards the Open-Req and the original connection remains active. If the data sender receives no RI-Ack after retransmitting the null RI-Upd, it closes the original connection, then sends an
データ送付者がそれが既に接続がある外のルータからオープン-Reqを受け取って、接続IDが既に確立された接続のためにそれに合っていないなら、接続がまだ活発であるかどうか確かめない、それはパケットを捨てるべきではありません。 そのようなパケットの領収書は、接続でのデータ受信装置が再出発されて、新しい一方向接続を開いたのを示すかもしれません、最初にオリジナルの接続を終えないで。 データ送付者として機能する外のルータは、それがまだアクティブであるかどうか決定するためにヌルロードアイランド-Updを接続の上に送るべきです。 データ送付者がヌルロードアイランド-Updに対応してロードアイランド-Ackを受け取るなら、オープン-Reqを捨てます、そして、オリジナルの接続はアクティブなままで残っています。 ヌルロードアイランド-Updを再送した後にデータ送付者がロードアイランド-Ackを全く受け取らないなら、それは、オリジナルの接続を終えて、発信します。
Oppenheimer [Page 42] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[42ページ]RFC1504Appletalk
Open-Rsp to the next Open-Req received.
次のオープン-Reqへの開いているRspは受信しました。
NOTE: An exterior router can act as the data sender on only a single one-way connection between itself and a given exterior router. That is, multiple one-way connections in the same direction cannot exist between two exterior routers.
以下に注意してください。 外のルータはデータ送付者としてそれ自体と与えられた外のルータとの単独の一方向関係だけに機能できます。 すなわち、同じ方向との複数の一方向接続は2つの外のルータの間に存在できません。
When establishing a one-way connection with a given data sender, a data receiver using AURP-Tr must send an Open-Req that has a different connection ID from that used in its last connection with the data sender. Otherwise, if the last connection to the data sender had terminated abnormally and the new connection used the same connection ID, the data sender might determine that the last connection was still active and interpret the Open-Req as a retransmission of the Open-Req for the last connection. The data sender might respond to the Open-Req by sending an Open-Rsp or ignore the Open-Req, but would not open a new connection.
与えられたデータ送付者との一方向接続を確立するとき、AURP-Trを使用するデータ受信装置はデータ送付者との最後の接続に使用されるそれから異なった接続IDを持っているオープン-Reqを送らなければなりません。 さもなければ、データ送付者との最後の接続が異常に終わって、新しい接続が同じ接続IDを使用するなら、データ送付者は、最後の接続のためにオープン-Reqの「再-トランスミッション」として最後の接続がまだ活発であったと決心して、オープン-Reqを解釈するでしょうに。 データ送付者は、オープン-Rspを送ることによってオープン-Reqに応じるか、またはオープン-Reqを無視するかもしれませんが、新しい接続を開かないでしょう。
If a data receiver's implementation of AURP-Tr cannot guarantee the use of different connection IDs on successive connections with a given data sender, the data receiver must send an RI-Req immediately after it establishes a connection with a data sender. If the data sender already has a connection with the data receiver, it will send an RI-Rsp with a sequence number other than 1. The data receiver should then terminate that connection and open a new connection using a different connection ID.
データ受信装置のAURP-Trの実装が与えられたデータ送付者との連続した接続の異なった接続IDの使用を保証できないなら、データ送付者と共に取引関係を築く直後データ受信装置はロードアイランド-Reqを送らなければなりません。 データ送付者にデータ受信装置との接続が既にあると、それは1以外の一連番号と共にロードアイランド-Rspを送るでしょう。 データ受信装置は、異なった接続IDを使用することで次に、その接続を終えて、新しい接続を開くはずです。
Using Retransmission Timers Under AURP-Tr
AURP-Trの下で再送信タイマーを使用します。
When an AppleTalk tunnel exists through a foreign network's internet, the delay and loss characteristics of the tunnel's underlying foreign network system complicate the setting of retransmission timers. A physical connection can be built between two exterior routers using different media-for example, a single Ethernet LAN, a fast point-to- point link, an IP internet, or a slow link over an asynchronous modem. It is important to minimize performance degradation due to
AppleTalkトンネルが外国ネットワークのインターネットを通して存在していると、トンネルの基本的な外国ネットワーク・システムの遅れと損失の特性は再送信タイマーの設定を複雑にします。 2つの外のルータの間で非同期モデムの上で例えば、異なったメディア、ただ一つのイーサネットLAN、ポイントからポイントへの速いリンク、IPインターネット、または遅いリンクを使用することで物理接続を組み込むことができます。 それは、性能退行を最小にするために重要です。
packets being dropped or delayed by the underlying foreign network
system
基本的な外国ネットワーク・システムで下げられるか、または遅れるパケット
the inefficient use of the underlying foreign network system's
resources due to excessive retransmissions
過度の「再-トランスミッション」による基本的な外国ネットワーク・システムのリソースの効率の悪い使用
Most higher-level transport-layer services provide guaranteed packet delivery. It is not necessary to retransmit AURP packets when using such transport-layer services. When using AURP-Tr, an exterior router should employ an adaptive retransmission algorithm whenever possible. An adaptive retransmission strategy like that used in TCP
ほとんどの、よりハイレベルのトランスポート層サービスが保証されたパケット配信を提供します。 そのようなトランスポート層サービスを利用するとき、AURPパケットを再送するのは必要ではありません。 AURP-Trを使用するとき、可能であるときはいつも、外のルータは適応型の再送信アルゴリズムを使うべきです。 TCPで使用されるそのような適応型の「再-トランスミッション」戦略
Oppenheimer [Page 43] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[43ページ]RFC1504Appletalk
maintains the estimated times required to send a packet and receive
an acknowledgment-that is, average round-trip times
およそ回がパケットを送って、受信するのが必要であると主張する、すなわち、承認平均する、往復の回
maintains standard deviations from the average round-trip times
平均した往復の回から標準偏差を維持します。
derives retransmission timers from the average round-trip times
While AURP does not specify an adaptive retransmission algorithm,
the use of such an algorithm is recommended.
While AURPが適応型の再送信アルゴリズムを指定しないで、そのようなアルゴリズムの使用がお勧めであるという平均した往復の回から再送信タイマーを得ます。
NOTE: Often, long intervals exist between AURP packets sent successively on a connection by an exterior router-for example, between RI-Upd packets. Therefore, an adaptive retransmission algorithm used with AURP should give more weight to packets sent recently over a connection than would be appropriate for a general data-stream protocol like TCP.
以下に注意してください。 しばしば、長い間隔は相次ぐ例えば、外のルータによって接続に送られたAURPパケット、ロードアイランド-Updパケットの間に存在しています。 したがって、AURPと共に使用される適応型の再送信アルゴリズムはTCPのような一般的なデータ・ストリームプロトコルに適切であるだろうより多くの重さを最近接続の上に送られたパケットに与えるべきです。
When an exterior router initially opens a connection, no transaction history is available. It is recommended that the retransmission algorithm use a truncated, exponential backoff scheme for the initial Open-Req sequence, because the exterior router with which the data receiver is establishing a connection may be inaccessible or down. An exterior router should not retransmit an Open-Req at a rate faster than once every two seconds.
外のルータが初めは接続を開くとき、どんな取引履歴も利用可能ではありません。 再送信アルゴリズムが初期のオープン-Req系列に端が欠けていて、指数のbackoff体系を使用するのは、お勧めです、データ受信装置が取引関係を築いている外のルータが近づきがたいか、または下がるかもしれないので。 外のルータはレートで2秒あたりの一度より速くオープン-Reqを再送するべきではありません。
Hiding Local Networks From Remote Networks
リモートネットワークから企業内情報通信網を隠します。
As described in the section "Hiding Local Networks From Tunnels" in Chapter 2, a network administrator can configure an exterior router to hide specific networks in its local internet from networks connected to other exterior routers on the tunnel. When exchanging routing information with other exterior routers on the tunnel, the exterior router exports no routing information for hidden networks in its local internet to exterior routers from which those networks are hidden.
第2章に「Tunnelsから企業内情報通信網を隠す」というセクションで説明されるように、ネットワーク管理者はトンネルで他の外のルータに接続されたネットワークから地方のインターネットにおける特定のネットワークを隠すために外のルータを構成できます。 トンネルで他の外のルータとルーティング情報を交換するとき、外のルータは地方のインターネットでそれらのネットワークが隠される外のルータに隠されたネットワークのためのルーティング情報を全くエクスポートしません。
An exterior router using AURP does not include routing information for hidden networks in RI-Rsp, RI-Upd, or GZN-Rsp packets sent to exterior routers from which those networks are hidden. The exterior router also excludes from GDZL-Rsp packets any zones that appear only in the zone lists of hidden networks.
AURPを使用する外のルータは、それらのネットワークが隠されるロードアイランド-Rsp、ロードアイランド-Upd、または外のルータに送られたGZN-Rspパケットの隠されたネットワークのための情報を発送するのを含んでいません。 また、外のルータはGDZL-Rspパケットから隠されたネットワークのゾーンリストだけに現れるどんなゾーンも除きます。
To maintain network-level security, an exterior router should discard any AppleTalk data packet sent to a network in its local internet by an exterior router from which that network is hidden.
ネットワークレベルセキュリティを維持するために、外のルータはそのネットワークが隠される外のルータで地方のインターネットでネットワークに送られたどんなAppleTalkデータ・パケットも捨てるべきです。
NOTE: An exterior router hides a network by excluding the routing information for that network from RI-Rsp, RI-Upd, GZN-Rsp, and GDZL- Rsp packets. However, network management packets-such as RTMP Route
以下に注意してください。 外のルータは、ロードアイランド-Rsp、ロードアイランド-Upd、GZN-Rsp、およびGDZL- Rspパケットにそのネットワークのためのルーティング情報を入れないようにすることによって、ネットワークを隠します。 しかしながら、ネットワークマネージメント、パケットそのようなもの、RTMP Route
Oppenheimer [Page 44] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[44ページ]RFC1504Appletalk
Data Response (RDR) packets that are not split horizoned, and Simple Network Management Protocol (SNMP) packets-should include the routing information for hidden networks. For detailed information about the effects of AURP on network management, see the section "Network Management" in Chapter 4.
horizonedされていた状態で分けられないデータResponse(RDR)パケット、およびSimple Network Managementプロトコル(SNMP)、パケット、-、隠されたネットワークのためのルーティング情報を含めるべきであってください。 ネットワークマネージメントへのAURPの効果の詳細な情報に関しては、第4章の「ネットワークマネージメント」というセクションを見てください。
AURP Packet Format
AURPパケット・フォーマット
An exterior router encapsulates both AURP packets and AppleTalk data packets using the same headers. Before forwarding AURP packets across a tunnel, an exterior router encapsulates the AURP packets in packets of the tunnel's underlying foreign network system-by adding the headers required by that network system. For more information about these headers, see the sections "Forwarding Data," "AppleTalk Data- Packet Format," and "AppleTalk Data-Packet Format for IP Tunneling" in Chapter 2.
外のルータは、同じヘッダーを使用することでAURPパケットとAppleTalkデータ・パケットの両方をカプセルに入れります。 トンネルの向こう側にパケットをAURPに送る前に、ヘッダーがそのネットワーク・システムが必要であると言い足しながら、外のルータは近くトンネルの基本的な外国ネットワークシステムのパケットでAURPパケットをカプセルに入れります。 これらのヘッダーに関する詳しい情報に関しては、第2章の「推進データ」、「AppleTalkデータパケット・フォーマット」、および「IPトンネリングのためのAppleTalkデータ・パケット形式」というセクションを見てください。
When using AURP-Tr in conjunction with TCP/IP, an exterior router encapsulates AURP packets in UDP packets prior to forwarding them across an IP tunnel through UDP port 387. When another exterior router on the tunnel receives the UDP packets at UDP port 387, it decapsulates the packets.
TCP/IPに関連してAURP-Trを使用するとき、UDPポート387を通してIPトンネルの向こう側にそれらを進める前に、外のルータはUDPパケットでパケットをAURPにカプセルに入れります。 トンネルの上の別の外のルータがUDPポート387でUDPパケットを受けるとき、それはパケットをdecapsulatesします。
Domain Headers in AURP Packets
AURPパケットのドメインヘッダー
When forwarding AURP packets across a tunnel, an exterior router adds a domain header immediately preceding each packet. A domain header contains additional addressing information, including its source domain identifier and destination domain identifier (DI). The last two bytes of the domain header are set to 0003, indicating that the packet is an AURP packet rather than an AppleTalk packet. AURP data follows the domain header. Figure 3-20 shows the protocol headers, the domain header, and the routing data header that encapsulate a routing data packet sent across an IP tunnel.
トンネルの向こう側にパケットをAURPに送るとき、外のルータはすぐに各パケットに先行するドメインヘッダーを加えます。 ドメインヘッダーはそのソースドメイン識別子と目的地ドメイン識別子(DI)を含む追加アドレス指定情報を含んでいます。 ドメインヘッダーの最後の2バイトは0003に設定されます、パケットがAppleTalkパケットよりむしろAURPパケットであることを示して。 AURPデータはドメインヘッダーに続きます。 図3-20は、プロトコルヘッダー、ドメインヘッダー、およびルーティングがデータ・パケットであるとカプセル化するルーティングデータヘッダーがIPトンネルの向こう側に発信したのを示します。
<<Figure 3-20 A routing data packet on an IP tunnel>>
<<数値3-20IPトンネル>>の上のAルーティングデータ・パケット
An exterior router interprets the domain identifiers in the domain header of an AURP packet differently from those in the domain headers of an AppleTalk data packet. Only network entities with AppleTalk addresses have domain identifiers associated with them. Exterior routers do not have AppleTalk addresses on the tunnel-thus, they do not have true domain identifiers.
外のルータはAppleTalkデータ・パケットのドメインヘッダーでAURPパケットのドメインヘッダーでドメイン識別子をそれらと異なって解釈します。 AppleTalkアドレスがあるネットワーク実体だけには、それらに関連しているドメイン識別子があります。 外のルータには、その結果、トンネルに関するAppleTalkアドレスがなくて、またそれらに本当のドメイン識別子がありません。
DESTINATION DOMAIN IDENTIFIER: The destination DI in an AURP packet's domain header is the DI that is associated with any network numbers corresponding to networks that reside in the receiving exterior router's domain. Only ZI-Req packets include such network numbers.
目的地ドメイン識別子: AURPパケットのドメインヘッダーの目的地DIは受信外のルータのドメインにあるネットワークに対応するどんなネットワーク・ナンバーにも関連しているDIです。 ZI-Reqパケットだけがそのようなネットワーク・ナンバーを含んでいます。
Oppenheimer [Page 45] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[45ページ]RFC1504Appletalk
Whenever possible, a domain header should specify a destination DI- that is, the DI for the networks that reside in the domain of the exterior router that is to receive the packet. When an exterior router sends an Open-Req to open a connection, the destination DI is not yet known. However, under the current version of AURP, the exterior router can either derive the destination DI from the destination's IP address or, on point-to-point links, include the null DI.
可能であるときはいつも、ドメインヘッダーは目的地DIを指定するべきです、パケットを受けることになっている外のルータのドメインにあるネットワークのためのDI。 外のルータが接続を開くためにオープン-Reqを送るとき、目的地DIはまだ知られていません。 しかしながら、外のルータは、AURPの最新版の下では、目的地のIPアドレスから目的地DIを得るか、またはポイントツーポイント接続の上にヌルDIを含むことができます。
SOURCE DOMAIN IDENTIFIER: The source DI in an AURP packet's domain header is the DI that is associated with any network numbers corresponding to networks that reside in the sending exterior router's domain. RI-Rsp, RI-Upd, ZI-Rsp, and GZN-Rsp packets include such network numbers. A domain header should always specify a source DI-that is, the DI for the networks that reside in the domain of the exterior router that is sending the packet.
ソースドメイン識別子: AURPパケットのドメインヘッダーというソースDIは発信している外のルータのドメインにあるネットワークに対応するどんなネットワーク・ナンバーにも関連しているDIです。 ロードアイランド-Rsp、ロードアイランド-Upd、ZI-Rsp、およびGZN-Rspパケットはそのようなネットワーク・ナンバーを含んでいます。 ドメインヘッダーがいつもソースを指定するべきである、すなわち、DI、パケットを送る外のルータのドメインにあるネットワークのためのDI。
Routing Data Headers in AURP Packets
AURPパケットのルート設定データヘッダー
The routing data header that immediately precedes the AURP data in a routing data packet consists of an AURP-Tr header and an AURP header. The AURP-Tr header consists of the following fields:
すぐにルーティングデータ・パケットでAURPデータに先行するルーティングデータヘッダーはAURP-TrヘッダーとAURPヘッダーから成ります。 AURP-Trヘッダーは以下の分野から成ります:
Connection ID: The contents of this two-byte field identify the specific one-way connection to which a packet belongs.
接続ID: この2バイトの分野の内容はパケットが所有特定の一方向接続を特定します。
Sequence number: The contents of this two-byte field identify an individual packet on a connection.
一連番号: この2バイトの分野の内容は接続のときに個々のパケットを特定します。
The AURP header consists of these fields:
AURPヘッダーはこれらの分野から成ります:
Command code: This two-byte field identifies the command type. For information about command types, see the next section, "Command Types."
コマンドコード: この2バイトの分野はコマンドタイプを特定します。 コマンドタイプの情報に関しては、次のセクション、「コマンドタイプ」を見てください。
Flags: This two-byte field may contain different flags, depending on the command code. For information about flags, see the section "Routing Flags" later in this chapter.
旗: コマンドコードによって、この2バイトの分野は異なった旗を含むかもしれません。 旗の情報に関しては、後で本章で「ルート設定旗」というセクションを見てください。
Command Types
コマンドタイプ
AURP defines the command types shown in Table 3-1:
AURPはTable3-1で見せられたコマンドタイプを定義します:
Oppenheimer [Page 46] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[46ページ]RFC1504Appletalk
Table 3-1 Command types
テーブル3-1 Commandはタイプします。
Command
Command type Abbreviation code Subcode
コマンドCommandはAbbreviationコードSubcodeをタイプします。
Routing Information Request RI-Req 1 - Routing Information Response RI-Rsp 2 - Routing Information Acknowledgment RI-Ack 3 - Routing Information Update RI-Upd 4 - Router Dow RD 5 - Zone Information Request ZI-Req 6 1 Zone Information Response ZI-Rsp 7 1 and 2 Get Zones Net Request GZN-Req 6 3 Get Zones Net Response GZN-Rsp 7 3 Get Domain Zone List Request GDZL-Req 6 4 Get Domain Zone List Response GDZL-Rsp 7 4 Open Request Open-Req 8 - Open Response Open-Rsp 9 - Tickle - 14 - Tickle Acknowledgment Tickle-Ack 15 -
情報を発送して、ロードアイランド-Req1--経路情報応答ロードアイランド-Rsp2--経路情報承認ロードアイランド-Ack3--経路情報最新版ロードアイランド-Upd4--ルータダウを要求してください、5--情報要求ZI-Req6 1ゾーン情報応答ZI-Rsp7 1と2を第区分してください; ネットの要求GZN-Req6 3がネットの応答GZN-Rsp7 3がGDZL-Req6 4が8(開いている応答開いているRsp9)がくすぐるドメインゾーンリスト応答GDZL-Rsp7 4の開いている要求開いているReq--14--くすぐり承認くすぐり-Ack15を得るドメインゾーンリスト要求を届けるゾーンを届けるゾーンを得てください、-
Routing Flags
ルート設定旗
AURP defines the flags shown in Table 3-2. All other flags are reserved. A data sender should set reserved flags to 0. A data receiver should ignore reserved flags.
AURPはTable3-2で見せられた旗を定義します。 他のすべての旗が予約されています。 データ送付者は予約された旗を0に設定するべきです。 データ受信装置は予約された旗を無視するはずです。
Table 3-2 Flags
テーブル3-2 旗
Flag Event Command types Bit
旗のEvent CommandはBitをタイプします。
Send update information (SUI) flag NA Open-Req and RI-Req 14
Send update information (SUI) flag ND and NRC Open-Req and RI-Req 13
Send update information (SUI) flag NDC Open-Req and RI-Req 12
Send update information (SUI) flag ZC Open-Req and RI-Req 11
Last flag - RI-Rsp and GDZL-Rsp 15
Remapping active flag - Open-Rsp 14
Hop-count reduction active flag - Open-Rsp 13
Reserved environment flags - - 12
and 11
Send zone information (SZI) flag - RI-Ack 14
Send update information (SUI) flag NA Open-Req and RI-Req 14 Send update information (SUI) flag ND and NRC Open-Req and RI-Req 13 Send update information (SUI) flag NDC Open-Req and RI-Req 12 Send update information (SUI) flag ZC Open-Req and RI-Req 11 Last flag - RI-Rsp and GDZL-Rsp 15 Remapping active flag - Open-Rsp 14 Hop-count reduction active flag - Open-Rsp 13 Reserved environment flags - - 12 and 11 Send zone information (SZI) flag - RI-Ack 14
Figure 3-21 shows the routing flags in Open-Req and RI-Req packets.
図3-21はオープン-Reqとロードアイランド-Reqパケットにルーティング旗を示しています。
<<Figure 3-21 Routing flags in Open-Req and RI-Req packets>>
<<数値3-21オープン-Reqとロードアイランド-Reqパケット>>のルート設定旗
Figure 3-22 shows the routing flags in all packets other than Open- Req and RI-Req packets.
図3-22はオープンReqとロードアイランド-Reqパケット以外のすべてのパケットにルーティング旗を示しています。
Oppenheimer [Page 47] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[47ページ]RFC1504Appletalk
<<Figure 3-22 Routing flags in other packets>>
<<数値3-22他のパケット>>のルート設定旗
Open Request Packet
開いているリクエスト・パケット
An Open-Req packet initiates the establishment of a one-way connection with a data sender. Figure 3-23 shows the format of an Open-Req packet. When sending an Open-Req packet, an exterior router inserts the next available connection ID in the packet's AURP-Tr header and sets its sequence number to 0. The AURP header of an Open-Req contains the command code 8. Its flag bytes contain send update information (SUI) flags. For the current version of AURP, the version number is 1.
オープン-Reqパケットはデータ送付者との一方向接続の設立を開始します。 図3-23はオープン-Reqパケットの書式を示しています。 オープン-Reqパケットを送るとき、外のルータは、次の利用可能な接続IDをパケットのAURP-Trヘッダーに挿入して、0に一連番号を設定します。 オープン-ReqのAURPヘッダーはコマンドコード8を含んでいます。 フラグバイトが含んでいる、アップデート情報(SUI)に旗を送ってください。 AURPの最新版のために、バージョン番号は1です。
An Open-Req packet's option data field contains
データ・フィールドが含むオープン-Reqパケットのオプション
an option count-indicating the number of option tuples to follow
続くオプションtuplesの数をカウントして示すオプション
the option tuples
オプションtuples
When the data sender receives an Open-Req, it can discard the option tuples for any options it does not implement. For information about option tuples, see the section "Option Tuples" later in this chapter.
データ送付者がオープン-Reqを受け取るとき、それは実装しない少しのオプションのためにもオプションtuplesを捨てることができます。 オプションtuplesの情報に関しては、後で本章で「オプションTuples」というセクションを見てください。
<<Figure 3-23 Open-Req packet format>>
<<数値3-23オープン-Reqパケット・フォーマット>>。
Open Response Packet
開いている応答パケット
When the data sender receives an Open-Req, it responds by sending an Open-Rsp packet to establish a one-way connection with the data receiver. Figure 3-24 shows the format of an Open-Rsp packet. In its AURP-Tr header, an Open-Rsp packet contains the connection ID from the associated Open-Req packet and the sequence number 0. The AURP header of an Open-Rsp contains the command code 9 and its flag bytes contain environment flags that provide information about the data sender's environment-such as whether network-number remapping or hop-count reduction is active. For information about network-number remapping and hop-count reduction, see the sections "Network-Number Remapping" and "Hop-Count Reduction," respectively, in Chapter 4.
データ送付者がオープン-Reqを受け取るとき、それは、データ受信装置との一方向接続を証明するためにオープン-Rspパケットを送ることによって、応じます。図3-24はオープン-Rspパケットの書式を示しています。 AURP-Trヘッダーでは、オープン-Rspパケットは関連オープン-Reqパケットと一連番号0からの接続IDを含んでいます。 オープン-RspのAURPヘッダーがコマンドコード9を含んでいて、フラグバイトがデータ送付者のものの情報を提供する環境旗を含んでいる、環境そのようなもの、ネットワーク・ナンバー再写像かホップカウントであることにかかわらず、減少は活発です。 ネットワーク・ナンバー再写像とホップカウント減少の情報に関しては、第4章でそれぞれセクション「ネットワーク・ナンバーRemapping」と「ホップカウント減少」を見てください。
<<Figure 3-24 Open-Rsp packet format>>
<<数値3-24オープン-Rspパケット・フォーマット>>。
An Open-Rsp packet's option data field contains
データ・フィールドが含むオープン-Rspパケットのオプション
a two-byte field that indicates either
the nominal rate at which the data sender sends updates-in
multiples of ten seconds
an error code-which is a negative number-if the data sender
cannot accept the connection
データ送付者が10秒の中のアップデート倍数にエラーコードを送るノミナルレートを示す2バイトの分野、-、どれ、負数であるか、-、データ送付者は接続を受け入れることができません。
Oppenheimer [Page 48] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[48ページ]RFC1504Appletalk
an option count-indicating the number of option tuples to follow
続くオプションtuplesの数をカウントして示すオプション
the option tuples
オプションtuples
For information about error codes, see the section "Error Codes" later in this chapter. For information about option tuples, see the next section, "Option Tuples."
エラーコードの情報に関しては、後で本章で「エラーコード」というセクションを見てください。 オプションtuplesの情報に関しては、次のセクション、「オプションTuples」を見てください。
Option Tuples
オプションTuples
Both Open-Req and Open-Rsp packets contain option tuples. An option tuple contains a one-byte length field that indicates the length of the remainder of the tuple, a one-byte type code, and an optional data field, as shown in Figure 3-25.
オープン-Reqとオープン-Rspパケットの両方がオプションtuplesを含んでいます。 オプションtupleはtupleの残りの長さ、1バイトのタイプコード、および任意のデータ・フィールドを示す1バイトの長さの分野を含んでいます、図3-25に示されるように。
<<Figure 3-25 Option tuples>>
<<数値3-25Option tuples>>。
AURP currently defines the option-type codes shown in Table 3-3:
AURPは現在、Table3-3に示されたオプションタイプコードを定義します:
Table 3-3 Option-type codes
テーブル3-3 Option-タイプコード
Option types Type codes
オプションはTypeコードをタイプします。
Authentication 1 Reserved for future use 2-255
今後の使用2-255のための認証1Reserved
Routing Information Request Packet
経路情報リクエスト・パケット
An RI-Req packet requests the data sender to send RI-Rsp packets. Figure 3-26 shows the format for an RI-Req packet. When sending an RI-Req packet, an exterior router inserts the connection ID for the connection on which it is the data receiver in the packet's AURP-Tr header and sets the packet's sequence number to 0. The AURP header of an RI-Req contains the command code 1 and its flag bytes contain the send update information (SUI) flags.
ロードアイランド-Reqパケットは、ロードアイランド-Rspパケットを送るようデータ送付者に要求します。 図3-26はロードアイランド-Reqパケットのために書式を示しています。 ロードアイランド-Reqパケットを送るとき、外のルータはそれがパケットのパケットの一連番号のAURP-Trヘッダーとセットで0へのデータ受信装置である接続のために接続IDを挿入します。 ロードアイランド-ReqのAURPヘッダーが1とそのフラグバイトが含むコマンドコードを含んでいる、アップデート情報(SUI)に旗を送ってください。
<<Figure 3-26 RI-Req packet format>>
<<数値3-26ロードアイランド-Reqパケット・フォーマット>>。
Routing Information Response Packet
経路情報応答パケット
When the data sender receives an RI-Req, it responds by sending a sequence of RI-Rsp packets. Figure 3-27 shows the format of an RI-Rsp packet. When sending an RI-Rsp packet, a data sender inserts the connection ID from the associated RI-Req in the RI-Rsp packet's AURP-Tr header and sets its sequence number to the next number in the sequence. The AURP header of an RI-Rsp packet contains the command code 2. In the last packet in a sequence of RI-Rsp packets, the
データ送付者がロードアイランド-Reqを受け取るとき、それは、ロードアイランド-Rspパケットの系列を送ることによって、応じます。 図3-27はロードアイランド-Rspパケットの書式を示しています。 ロードアイランド-Rspパケットを送るとき、データ送付者はロードアイランド-Rspパケットの一連番号のAURP-Trヘッダーとセットにおける関連ロードアイランド-Reqから次の数までの接続IDを系列に挿入します。 ロードアイランド-RspパケットのAURPヘッダーはコマンドコード2を含んでいます。 次々にのロードアイランド-Rspパケットの最後のパケットで
Oppenheimer [Page 49] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[49ページ]RFC1504Appletalk
last-flag bit is set to 1.
最後のフラグビットは1に設定されます。
<<Figure 3-27 RI-Rsp packet format>>
<<数値3-27ロードアイランド-Rspパケット・フォーマット>>。
An RI-Rsp packet's routing data field contains zero or more routing tuples, which have a format similar to those in RTMP packets. An AURP tuple for a nonextended network is different from an RTMP tuple for an extended network in one respect-the range flag, or the sixth byte, in an AURP tuple for a nonextended network is set to 0. Figure 3-28 shows nonextended and extended network tuples in an RI-Rsp packet.
ロードアイランド-Rspパケットのルーティングデータ・フィールドは、tuples(RTMPパケットにそれらと同様の形式を持っている)を発送しながら、ゼロか以上を含んでいます。 拡大ネットワークにおいて、「非-広げ」られたネットワークのためのAURP tupleが1でRTMP tupleと異なっている、敬意、-、範囲旗、または6番目のバイトが「非-広げ」られたネットワークのためのAURP tupleに0に設定されます。 図3-28ショーは、ロードアイランド-Rspパケットでネットワークtuplesを「非-広げ」て、広げました。
<<Figure 3-28 Nonextended and extended network tuples>>
<<数値3-28Nonextendedと拡大ネットワークtuples>>。
Routing Information Acknowledgment Packet
経路情報確認応答パケット
When a data receiver receives an RI-Rsp, RI-Upd, or RD packet, it responds by sending an RI-Ack packet. Figure 3-29 shows the format of an RI-Ack packet. When sending an RI-Ack packet, a data receiver inserts the connection ID and sequence number from the associated RI-Rsp, RI-Upd, or RD packet in the RI-Ack packet's AURP-Tr header. The AURP header of an RI-Ack contains the command code 3. If the data receiver sends an RI-Ack using AURP-Tr, in response to an RI-Rsp or RI-Upd packet that contains an NA event, its flag bytes contain the send zone information flag. An RI-Ack packet contains no data.
データ受信装置がロードアイランド-Rsp、ロードアイランド-Upd、またはRDパケットを受けるとき、それは、ロードアイランド-Ackパケットを送ることによって、応じます。 図3-29はロードアイランド-Ackパケットの書式を示しています。 ロードアイランド-Ackパケットを送るとき、データ受信装置は接続IDと一連番号を関連ロードアイランド-Rsp、ロードアイランド-Upd、またはRDパケットからロードアイランド-AckパケットのAURP-Trヘッダーに挿入します。 ロードアイランド-AckのAURPヘッダーはコマンドコード3を含んでいます。 データ受信装置がAURP-Trを使用することでロードアイランド-Ackを送るなら、ロードアイランド-Rspかロードアイランド-Updパケットに対応してそれはNAイベントを含んでいます、フラグバイト、含有、ゾーン情報フラグを送ってください。 ロードアイランド-Ackパケットはデータを全く含んでいません。
<<Figure 3-29 RI-Ack packet format>>
<<数値3-29ロードアイランド-Ackパケット・フォーマット>>。
Routing Information Update Packet
経路情報アップデートパケット
The occurrence of specified events requires the data sender to send an RI-Upd packet. Figure 3-30 shows the format of an RI-Upd packet. When sending an RI-Upd packet, a data sender inserts the connection ID for the current connection in the RI-Upd packet's AURP-Tr header and sets its sequence number to the next number in the sequence. The AURP header of an RI-Upd contains the command code 4 and its flag bytes are set to 0.
指定されたイベントの発生は、データ送付者がロードアイランド-Updパケットを送るのを必要とします。 図3-30はロードアイランド-Updパケットの書式を示しています。 ロードアイランド-Updパケットを送るとき、データ送付者は、現在の接続のためにロードアイランド-UpdパケットのAURP-Trヘッダーに接続IDを挿入して、次の数への一連番号を系列にはめ込みます。 ロードアイランド-UpdのAURPヘッダーはコマンドコード4を含んでいます、そして、フラグバイトは0に設定されます。
<<Figure 3-30 RI-Upd packet format>>
<<数値3-30ロードアイランド-Updパケット・フォーマット>>。
An RI-Upd packet's data field contains one or more event tuples. An event tuple for a nonextended network consists of a one-byte event code, the network number, and the distance to that network. An event tuple for an extended network consists of a one-byte event code, the first network number in the range of network numbers, the distance to the network, and the last network number in the range of network numbers. Figure 3-31 shows nonextended and extended network tuples in an RI-Upd packet.
ロードアイランド-Updパケットのデータ・フィールドは1つ以上のイベントのtuplesを含んでいます。 「非-広げ」られたネットワークのためのイベントtupleはそのネットワークに1バイトのイベントコード、ネットワーク・ナンバー、および距離から成ります。 拡大ネットワークのためのイベントtupleは1バイトのイベントコード、ネットワーク・ナンバーの範囲における最初のネットワーク・ナンバー、ネットワークへの距離、およびネットワーク・ナンバーの範囲における最後のネットワーク・ナンバーから成ります。 図3-31ショーは、ロードアイランド-Updパケットでネットワークtuplesを「非-広げ」て、広げました。
Oppenheimer [Page 50] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[50ページ]RFC1504Appletalk
<<Figure 3-31 Nonextended and extended network event tuples>>
<<数値3-31Nonextendedと拡大ネットワークイベントtuples>>。
AURP currently defines the event codes shown in Table 3-4:
AURPは現在、Table3-4に示されたイベントコードを定義します:
Table 3-4 Event codes
テーブル3-4 Eventコード
Event Abbreviation Event code
イベントAbbreviation Eventコード
Null event 0 Network Added event NA 1 Network Deleted event ND 2 Network Route Change event NRC 3 Network Distance Change event NDC 4 Zone Change event ZC 5
ヌルイベントのNetwork Distance ChangeイベントNDC4Zone Change0Network AddedイベントNA1Network Deletedイベントノースダコタ2Network Route ChangeイベントNRC3イベントZC5
A null event tuple contains no event data. The format of NA, ND, NRC, and NDC event tuples differs, depending on whether the event pertains to a nonextended or an extended network. The distance field does not apply to ND or NRC event tuples and should be set to 0. The ZC event tuple is not yet defined.
ヌルイベントtupleはイベントデータを全く含んでいません。 NA、ノースダコタNRC、およびNDCイベントtuplesの形式は異なります、イベントが「非-広げ」られたaか拡大ネットワークに関係するかどうかによって。 距離分野は、ノースダコタかNRCイベントtuplesに適用しないで、0に設定されるべきです。 ZCイベントtupleはまだ定義されていません。
An RI-Upd packet should never contain two events that pertain to the same network. However, to ensure consistent behavior in the event that an exterior router receives a packet containing multiple events for one network, an exterior router should always process events in the order in which they occur in the RI-Upd packet. Thus, if an exterior router were to receive an RI-Upd that contained an NA event, then an ND event for the same network, the exterior router would delete the network from its routing table.
ロードアイランド-Updパケットは同じネットワークに関係する2つのイベントを決して含むはずがありません。 しかしながら、それらがロードアイランド-Updパケットに起こるオーダーで一貫した振舞いが外のルータが1つのネットワーク、外のルータのために複数のイベントを含むパケットを受ける場合いつもイベントを処理するべきであるのを保証するために。 したがって、次に、同じネットワークのためのノースダコタイベント外のルータがNAイベントを含んだロードアイランド-Updを受け取ることであったなら、外のルータは経路指定テーブルからネットワークを削除するでしょう。
Router Down Packet
ルータ下にパケット
An exterior router should send an RD packet before it goes down. Figure 3-32 shows the format of an RD packet. When sending an RD packet, an exterior router inserts the connection ID for the current connection in the RD packet's AURP-Tr header. If the data sender sends an RD packet, it sets its sequence number to the next number in the sequence. If the data receiver sends an RD packet, it sets its sequence number to 0. The AURP header of an RD packet contains the command code 5 and its flag bytes are set to 0.
落ちる前に外のルータはRDパケットを送るべきです。 図3-32はRDパケットの書式を示しています。 RDパケットを送るとき、外のルータはRDパケットのAURP-Trヘッダーという現在の接続のために接続IDを挿入します。 データ送付者がRDパケットを送るなら、それは次の数への一連番号を系列にはめ込みます。 データ受信装置がRDパケットを送るなら、それは0に一連番号を設定します。 RDパケットのAURPヘッダーはコマンドコード5を含んでいます、そして、フラグバイトは0に設定されます。
<<Figure 3-32 RD packet format>>
<<数値3-32RDパケット・フォーマット>>。
An RD packet's data field contains a two-byte error code that indicates the exterior router's reason for going down. For information about the error codes, see the section "Error Codes" later in this chapter.
RDパケットのデータ・フィールドは外のルータの落ちる理由を示す2バイトのエラーコードを含んでいます。 エラーコードの情報に関しては、後で本章で「エラーコード」というセクションを見てください。
Oppenheimer [Page 51] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[51ページ]RFC1504Appletalk
Zone Information Request/Response Transactions
ゾーン情報要求/応答トランザクション
An exterior router returns information about its zones through request/response transactions. Three types of zone requests-ZI-Req, GDZL-Req, and GZN-Req-share the same command code and have subcodes that indicate the actual request type. Three types of zone responses-ZI-Rsp, GDZL-Rsp, and GZN-Rsp-share another command code and have subcodes that indicate the actual response type.
外のルータは要求/応答トランザクションを通してゾーンの情報を返します。 そして、3つのタイプのゾーン要求-ZI-Req、GDZL-Req、および同じGZN-Req共有しているコマンドコード、実際の要求タイプを示す部分符号を持ってください。 3つのタイプ、GDZL-Rsp、応答-ZI-Rspを区分してください、そして、別のコマンドコードをGZN-Rsp共有してください、そして、実際の応答タイプを示す部分符号を持ってください。
ZONE INFORMATION REQUEST PACKET: A ZI-Req packet causes the data sender to send ZI-Rsp packets. Figure 3-33 shows the format of a ZI- Req packet. When sending a ZI-Req packet, an exterior router inserts the connection ID for the connection on which it is the data receiver in the packet's AURP-Tr header and sets the packet's sequence number to 0. The AURP header of a ZI-Req contains the command code 6 and its flag bytes are set to 0.
ゾーン情報リクエスト・パケット: ZI-Reqパケットで、データ送付者はパケットをZI-Rspに送ります。 図3-33はZI- Reqパケットの書式を示しています。 ZI-Reqパケットを送るとき、外のルータはそれがパケットのパケットの一連番号のAURP-Trヘッダーとセットで0へのデータ受信装置である接続のために接続IDを挿入します。 ZI-ReqのAURPヘッダーはコマンドコード6を含んでいます、そして、フラグバイトは0に設定されます。
<<Figure 3-33 ZI-Req packet format>>
<<数値3-33ZI-Reqパケット・フォーマット>>。
A ZI-Req packet's data field contains the subcode 1 and a two-byte network number for each network about which the exterior router is requesting zone information. The network number for an extended network is the first network number in its range of network numbers.
ZI-Reqパケットのデータ・フィールドは部分符号1と外のルータがゾーン情報を要求しているそれぞれのネットワークの2バイトのネットワーク・ナンバーを含んでいます。 拡大ネットワークのネットワーク・ナンバーはネットワーク・ナンバーの範囲で最初のネットワーク・ナンバーです。
ZONE INFORMATION RESPONSE PACKET: There are two types of ZI-Rsp packets-nonextended ZI-Rsp packets and extended ZI-Rsp packets. The format of a nonextended ZI-Rsp packet is similar to that of a nonextended AppleTalk ZIP Reply packet. When the data sender receives a ZI-Req and the zone list for the network or networks for which that ZI-Req requested zone information fits in one ZI-Rsp packet, it sends a nonextended ZI-Rsp.
ゾーン情報応答パケット: 2つのタイプのZI-Rspパケット-nonextended ZI-Rspパケットと拡張ZI-Rspパケットがあります。 nonextended ZI-Rspパケットの形式は「非-広げ」られたAppleTalk ZIP Replyパケットのものと同様です。 データ送付者がそのZI-Reqが、ゾーン情報が1つのZI-Rspパケットをうまくはめ込むよう要求したネットワークかネットワークのためのZI-Reqとゾーンリストを受け取るとき、それはnonextended ZI-Rspを送ります。
An extended ZI-Rsp packet is similar to an extended AppleTalk ZIP Reply packet. When the data sender receives a ZI-Req and the zone list for a network about which that ZI-Req requested zone information does not fit in a single ZI-Rsp packet, it sends a sequence of extended ZI-Rsp packets.
拡張ZI-Rspパケットは拡張AppleTalk ZIP Replyパケットと同様です。 データ送付者がそのZI-Reqが、ゾーン情報が単一のZI-Rspパケットをうまくはめ込まないよう要求したネットワークのためのZI-Reqとゾーンリストを受け取るとき、それは拡張ZI-Rspパケットの系列を送ります。
Figure 3-34 shows the format of a ZI-Rsp packet. When sending a ZI- Rsp packet, a data sender inserts the connection ID from the associated ZI-Req packet in the packet's AURP-Tr header and sets the packet's sequence number to 0. A ZI-Rsp packet's AURP header contains the command code 7 and its flag bytes are set to 0. The subcode 1 indicates a nonextended ZI-Rsp packet, while the subcode 2 indicates an extended ZI-Rsp packet.
図3-34はZI-Rspパケットの書式を示しています。 ZI- Rspパケットを送るとき、データ送付者は、接続IDを関連ZI-ReqパケットからパケットのAURP-Trヘッダーに挿入して、パケットの一連番号を0に設定します。 ZI-RspパケットのAURPヘッダーはコマンドコード7を含んでいます、そして、フラグバイトは0に設定されます。 部分符号1はnonextended ZI-Rspパケットを示しますが、部分符号2は拡張ZI-Rspパケットを示します。
<<Figure 3-34 ZI-Rsp packet format>>
<<数値3-34ZI-Rspパケット・フォーマット>>。
Oppenheimer [Page 52] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[52ページ]RFC1504Appletalk
A ZI-Rsp packet's data field contains the requested zone information. Its format is similar to that of a ZIP Reply packet.
ZI-Rspパケットのデータ・フィールドは要求されたゾーン情報を含んでいます。 形式はZIP Replyパケットのものと同様です。
In a nonextended ZI-Rsp packet, the first two bytes of the data field should indicate the number of tuples contained in the packet, while the remaining bytes constitute network number/zone name tuples. Within the packet, all of the tuples for a given network must be contiguous. NOTE: When sending a nonextended ZI-Rsp packet, an exterior router should attempt to specify the correct number of zone tuples. However, an exterior router receiving a nonextended ZI-Rsp packet should process all tuples contained in the packet, regardless of the number indicated in the header.
nonextended ZI-Rspパケットでは、データ・フィールドの最初の2バイトはパケットに含まれたtuplesの数を示すべきです、残っているバイトがネットワーク・ナンバー/ゾーン名前tuplesを構成しますが。 パケットの中では、与えられたネットワークのためのtuplesのすべてが隣接であるに違いありません。 以下に注意してください。 nonextended ZI-Rspパケットを送るとき、外のルータは、ゾーンtuplesの適度の数を指定するのを試みるべきです。 しかしながら、nonextended ZI-Rspパケットを受ける外のルータはパケットに含まれたすべてのtuplesを処理するべきです、ヘッダーで示された数にかかわらず。
Network number/zone name tuples in a nonextended ZI-Rsp packet can use either the long tuple format or the optimized tuple format. A long network number/zone name tuple contains a network number, followed by the length of the zone name, and the zone name.
nonextended ZI-Rspパケットのネットワーク・ナンバー/ゾーン名前tuplesは長いtuple形式か最適化されたtuple形式のどちらかを使用できます。 長いネットワーク・ナンバー/ゾーン名前tupleはネットワーク・ナンバーを含んでいます、続いて、ゾーン名の長さ、およびゾーン名を含みます。
Using the optimized tuple format, an exterior router can compress a nonextended ZI-Rsp packet in which more than one network contains the same zone name in its zone list. If the high-order bit of the length byte for a given zone name is set to 1, the following 15 bits represent an offset from the length byte of the first zone name in the packet's data field to the actual location of the zone name length and the zone name. Whenever possible, it is recommended that an exterior router send optimized ZI-Rsp packets. All exterior routers must be able to receive optimized ZI-Rsp packets.
最適化されたtuple形式を使用して、外のルータは1つ以上のネットワークがゾーンリストの同じゾーン名を含むnonextended ZI-Rspパケットを圧縮できます。 与えられたゾーン名のための長さのバイトの高位のビットが1に設定されるなら、以下の15ビットはパケットのデータ・フィールドの最初のゾーン名の長さのバイトから長さというゾーン名とゾーン名の実際の場所までのオフセットを表します。 可能であるときはいつも、外のルータが最適化されたZI-Rspパケットを送るのは、お勧めです。 すべての外のルータが最適化されたZI-Rspパケットを受けることができなければなりません。
In an extended ZI-Rsp packet, the first two bytes of the data field indicate the total number of tuples in the zone list for the network or networks for which the corresponding ZI-Req requested zone information. The remaining bytes in the data field of an extended ZI-Rsp packet consist of network number/zone name tuples. All tuples in a single extended ZI-Rsp packet must contain the same network number. However, for consistency with the format of network number/zone name tuples in nonextended ZI-Rsp packets, the network number precedes each zone name in an extended ZI-Rsp packet. Duplicate zone names never exist in extended ZI-Rsp packets- therefore, extended ZI-Rsp packets use the long tuple format, rather than the optimized tuple format.
拡張ZI-Rspパケットでは、データ・フィールドの最初の2バイトは対応するZI-Reqがゾーン情報を要求したネットワークかネットワークのためのゾーンリストのtuplesの総数を示します。 拡張ZI-Rspパケットのデータ・フィールドの残っているバイトはネットワーク・ナンバー/ゾーン名前tuplesから成ります。 単一の拡張ZI-Rspパケットのすべてのtuplesが同じネットワーク・ナンバーを含まなければなりません。 しかしながら、ネットワーク・ナンバー/ゾーン名前tuplesの形式がnonextended ZI-Rspパケットにある一貫性のために、ネットワーク・ナンバーは拡張ZI-Rspパケットのそれぞれのゾーン名に先行します。 したがって、写しゾーン名は拡張ZI-Rspパケットに決して存在していなくて、拡張ZI-Rspパケットは最適化されたtuple形式よりむしろ長いtuple形式を使用します。
Figure 3-35 shows the long tuple and optimized tuple formats for a ZI-Rsp packet.
図3-35はZI-Rspパケットのために長いtupleと最適化されたtupleに書式を示しています。
<<Figure 3-35 Long and optimized tuple formats>>
<<数値3-35Longと最適化されたtupleは>>をフォーマットします。
GET DOMAIN ZONE LIST REQUEST PACKET: A Get Domain Zone List Request packet, or GDZL-Req, requests the data sender to send GDZL-Rsp
ドメインゾーンリストリクエスト・パケットを手に入れてください: Get Domain Zone List Requestパケット、またはGDZL-Reqが、GDZL-Rspを送るようデータ送付者に要求します。
Oppenheimer [Page 53] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[53ページ]RFC1504Appletalk
packets. Figure 3-36 shows the format for a GDZL-Req packet. When sending a GDZL-Req packet, an exterior router inserts the connection ID for the connection on which it is the data receiver in the packet's AURP-Tr header and sets its sequence number to 0. The AURP header of a GDZL-Req contains the command code 6 and its flag bytes are set to 0.
パケット。 図3-36はGDZL-Reqパケットのために書式を示しています。 GDZL-Reqパケットを送るとき、外のルータはそれがパケットの一連番号のAURP-Trヘッダーとセットで0へのデータ受信装置である接続のために接続IDを挿入します。 GDZL-ReqのAURPヘッダーはコマンドコード6を含んでいます、そして、フラグバイトは0に設定されます。
<<Figure 3-36 GDZL-Req packet format>>
<<数値3-36GDZL-Reqパケット・フォーマット>>。
A GDZL-Req packet's data field contains the subcode 4 and the start index in the data sender's zone list at which to begin returning GDZL-Rsp packets.
GDZL-Reqパケットのデータ・フィールドはパケットをGDZL-Rspに返し始めるデータ送付者のゾーンリストに部分符号4とスタートインデックスを含んでいます。
GET DOMAIN ZONE LIST RESPONSE PACKET: When the data sender receives a GDZL-Req, it responds by sending a GDZL-Rsp packet. Figure 3-37 shows the format of a GDZL-Rsp packet. When sending a GDZL-Rsp packet, a data sender inserts the connection ID from the associated GDZL-Req packet in the packet's AURP-Tr header and sets its sequence number to 0. The AURP header of a GDZL-Rsp contains the command code 7 and its flag bytes are set to 0, except in the last packet containing zone information, which has its last flag set to 1.
ドメインゾーンリスト応答パケットを手に入れてください: データ送付者がGDZL-Reqを受け取るとき、それは、GDZL-Rspパケットを送ることによって、応じます。 図3-37はGDZL-Rspパケットの書式を示しています。 GDZL-Rspパケットを送るとき、データ送付者は、接続IDを関連GDZL-ReqパケットからパケットのAURP-Trヘッダーに挿入して、0に一連番号を設定します。 GDZL-RspのAURPヘッダーはコマンドコード7を含んでいます、そして、フラグバイトは0に設定されます、ゾーン情報を含む最後のパケットを除いて。情報は最後の旗を1に設定します。
<<Figure 3-37 GDZL-Rsp packet format>>
<<数値3-37GDZL-Rspパケット・フォーマット>>。
A GDZL-Rsp packet's data field contains the subcode 4, the start index from the associated GDZL-Req, and the zone list. If the data sender does not support the GDZL-Req, it should set the start index to -1.
GDZL-Rspパケットのデータ・フィールドは部分符号4、関連GDZL-Reqからのスタートインデックス、およびゾーンリストを含んでいます。 データ送付者がGDZL-Reqをサポートしないなら、それはスタートインデックスを-1に設定するべきです。
GET ZONES NET REQUEST PACKET: A Get Zones Net Request packet, or GZN-Req, requests the data sender to send zone information for one specific zone. Figure 3-38 shows the format of a GZN-Req packet. When sending a GZN-Req packet, an exterior router inserts the connection ID for the connection on which it is the data receiver in the packet's AURP-Tr header and sets its sequence number to 0. The AURP header of a GZN-Req contains the command code 6 and its flag bytes are set to 0.
ネットのリクエスト・パケットをゾーンに手に入れてください: Get ZonesネットRequestパケット、またはGZN-Reqが、1つの特定のゾーンのためのゾーン情報を送るようデータ送付者に要求します。 図3-38はGZN-Reqパケットの書式を示しています。 GZN-Reqパケットを送るとき、外のルータはそれがパケットの一連番号のAURP-Trヘッダーとセットで0へのデータ受信装置である接続のために接続IDを挿入します。 GZN-ReqのAURPヘッダーはコマンドコード6を含んでいます、そして、フラグバイトは0に設定されます。
<<Figure 3-38 GZN-Req packet format>>
<<数値3-38GZN-Reqパケット・フォーマット>>。
A GZN-Req packet's data field contains the subcode 3 and the name of the zone about which the GZN-Req is requesting zone information.
GZN-Reqパケットのデータ・フィールドはGZN-Reqがゾーン情報を要求している部分符号3とゾーンの名前を含んでいます。
GET ZONES NET RESPONSE PACKET: When the data sender receives a GZN- Req, it responds by sending a GZN-Rsp packet, containing the requested zone information. Figure 3-39 shows the format of a GZN-Rsp packet. When sending a GZN-Rsp packet, a data sender inserts the connection ID from the associated GZN-Req packet in the GZN-Rsp
ネットの応答パケットをゾーンに手に入れてください: データ送付者がGZN- Reqを受け取るとき、それは、要求されたゾーン情報を含んでいて、GZN-Rspパケットを送ることによって、応じます。 図3-39はGZN-Rspパケットの書式を示しています。 GZN-Rspパケットを送るとき、データ送付者はGZN-Rspの関連GZN-Reqパケットから接続IDを挿入します。
Oppenheimer [Page 54] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[54ページ]RFC1504Appletalk
packet's AURP-Tr header and sets the GZN-Rsp packet's sequence number to 0. The AURP header of a GZN-Rsp contains the command code 7 and its flag bytes are set to 0.
パケットの0へのGZN-Rspパケットの一連番号のAURP-Trヘッダーとセット。 GZN-RspのAURPヘッダーはコマンドコード7を含んでいます、そして、フラグバイトは0に設定されます。
<<Figure 3-39 GZN-Rsp packet format>>
<<数値3-39GZN-Rspパケット・フォーマット>>。
A GZN-Rsp packet's data field contains the subcode 3, the zone name from the associated GZN-Req, the total number of network tuples for that zone, and as many network tuples as can fit in the packet. These tuples have the same format as those in RI-Rsp packets. If the data sender has no information about the zone, it returns a GZN-Rsp in which the number of network tuples is 0. If the data sender does not support the GZN-Req, it should set the number of network tuples to -1.
GZN-Rspパケットのデータ・フィールドは部分符号3、関連GZN-Reqからのゾーン名、そのゾーンへのネットワークtuplesの総数、およびパケットをうまくはめ込むことができるのと同じくらい多くのネットワークtuplesを含んでいます。 これらのtuplesには、ロードアイランド-Rspパケットのそれらと同じ形式があります。 データ送付者にゾーンの情報が全くないなら、それはネットワークtuplesの数が0であるGZN-Rspを返します。 データ送付者がGZN-Reqをサポートしないなら、それはネットワークtuplesの数を-1に設定するべきです。
TICKLE PACKET: The data receiver sends a Tickle packet to verify that the data received from the data sender is still valid. Figure 3-40 shows the format of a Tickle packet. When sending a Tickle packet, an exterior router inserts the connection ID for the connection on which it is the data receiver in the packet's AURP-Tr header and sets its sequence number to 0. The AURP header of a Tickle contains the command code 14 and its flag bytes are set to 0. A Tickle packet contains no data.
パケットをくすぐってください: データ受信装置は、データ送付者から受け取られたデータがまだ有効であることを確かめるためにTickleパケットを送ります。 図3-40はTickleパケットの書式を示しています。 Tickleパケットを送るとき、外のルータはそれがパケットの一連番号のAURP-Trヘッダーとセットで0へのデータ受信装置である接続のために接続IDを挿入します。 TickleのAURPヘッダーはコマンドコード14を含んでいます、そして、フラグバイトは0に設定されます。 Tickleパケットはデータを全く含んでいません。
<<Figure 3-40 Tickle packet format>>
<<数値3-40Tickleパケット・フォーマット>>。
TICKLE ACKNOWLEDGMENT PACKET: When the data sender receives a Tickle, it responds by sending a Tickle-Ack packet. Figure 3-41 shows the format of a Tickle-Ack. When sending a Tickle-Ack, a data sender inserts the connection ID from the associated Tickle in the Tickle- Ack packet's AURP-Tr header and sets its sequence number to 0. The AURP header of a Tickle-Ack packet contains the command code 15 and its flag bytes are set to 0. A Tickle-Ack packet contains no data.
確認応答パケットをくすぐってください: データ送付者がTickleを受け取るとき、それは、Tickle-Ackパケットを送ることによって、応じます。 図3-41はTickle-Ackの書式を示しています。 Tickle-Ackを送るとき、データ送付者は、接続IDを関連TickleからTickle- AckパケットのAURP-Trヘッダーに挿入して、0に一連番号を設定します。 Tickle-AckパケットのAURPヘッダーはコマンドコード15を含んでいます、そして、フラグバイトは0に設定されます。 Tickle-Ackパケットはデータを全く含んでいません。
<<Figure 3-41 Tickle-Ack packet format>>
<<数値3-41Tickle-Ackパケット・フォーマット>>。
Error Codes
エラーコード
Open-Rsp and RD packets contain error codes. AURP currently defines the error codes listed in Table 3-5.
開いているRspとRDパケットはエラーコードを含んでいます。 AURPは現在、Table3-5に記載されたエラーコードを定義します。
Table 3-5 Error codes
テーブル3-5 Errorコード
Error code Error
エラーコードError
-1 Normal connection close -2 Routing loop detected -3 Connection out of sync
-1の普通の接続近い-2ルート設定輪は同期していなく-3Connectionを検出しました。
Oppenheimer [Page 55] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[55ページ]RFC1504Appletalk
-4 Option-negotiation error -5 Invalid version number -6 Insufficient resources for connection -7 Authentication error
接続-7Authentication誤りのための-4オプション交渉誤り-5InvalidバージョンNo.-6Insufficientリソース
4. REPRESENTING WIDE AREA NETWORK INFORMATION
4. 広域ネットワーク情報を表します。
This chapter describes optional features of AURP-some of which can also be implemented on routers that use RTMP rather than AURP for routing-information propagation. It provides detailed information about the presentation of wide area network information by exterior routers to nodes on their local internets or to other exterior routers, including:
本章はまた、ルーティング情報伝播にAURPよりむしろRTMPを使用するルータでどれを実装することができるかについていくつかAURPに関するオプション機能について説明します。 それは外のルータで地元のインターネットのノード、または、他の外のルータに広域ネットワーク情報のプレゼンテーションの詳細な情報を提供します、である:
basic security-both network hiding and device hiding
基本的なセキュリティの両方ネットワーク隠れることとデバイス隠れること
remapping of remote network numbers
リモートネットワーク・ナンバーの再写像
internet clustering
インターネットクラスタリング
loop detection
輪の検出
hop-count reduction
ホップカウント減少
hop-count weighting
ホップカウントの重さ
backup paths
バックアップ道
network management
ネットワークマネージメント
Network Hiding
ネットワーク隠れること
An exterior router can hide networks by importing or exporting routing information only about specific networks.
ルーティングが特定のネットワークだけの情報であるとインポートするか、またはエクスポートすることによって、外のルータはネットワークを隠すことができます。
Importing Routing Information About Specific Networks
ルート設定が特定のネットワークに関する情報であるとインポートします。
A network administrator can configure a tunneling port on an exterior router to import only a subset of the routing information that it receives through the tunnel. To do so, the administrator hides specific networks connected to other exterior routers on the tunnel from the exterior router's local internet. For example, an exterior router can import only that routing information received from specific exterior routers, or routing information for networks in a specific network range or zone. By importing routing information only about specific networks, an exterior router can greatly reduce
ネットワーク管理者は、トンネルを通って受信するというルーティング情報の部分集合だけをインポートするために外のルータのトンネリングポートを構成できます。 そうするために、管理者はトンネルで外のルータの地方のインターネットから他の外のルータに接続された特定のネットワークを隠します。 例えば、外のルータは、情報が特定の外のルータから受けたそのルーティング、または唯一のルーティングが特定のネットワーク範囲かゾーンのネットワークのための情報であるとインポートすることができます。 ルーティングが特定のネットワークだけの情報であるとインポートすることによって、外のルータは大いに減少できます。
Oppenheimer [Page 56] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[56ページ]RFC1504Appletalk
the amount of routing information maintained by routers on its
local internet
地方のインターネットでルータによって保守されたルーティング情報の量
the number of zones and devices that are visible to devices on its
local internet
地方のインターネットでデバイスに目に見えるゾーンとデバイスの数
Exporting Routing Information About Specific Networks
ルート設定が特定のネットワークに関する情報であるとエクスポートします。
A network administrator can configure a tunneling port on an exterior router to export only a subset of its local internet's routing information-by hiding from other exterior routers on the tunnel specific networks in its local internet. For more information about hiding networks from other exterior routers, see the section "Hiding Local Networks From Tunnels" in Chapter 2.
ネットワーク管理者は、地方のインターネットで近くトンネルの上に他の外のルータから隠れる地方のインターネットのルーティング情報の特定のネットワークの部分集合だけをエクスポートするために外のルータのトンネリングポートを構成できます。 他の外のルータからネットワークを隠すことに関する詳しい情報に関しては、第2章の「Tunnelsから企業内情報通信網を隠す」というセクションを見てください。
Device Hiding
デバイス隠れること
A router can prevent a device in its local internet from being visible to other nodes on a specific part or all other parts of the internet by not forwarding Name Binding Protocol (NBP) LkUp-Reply packets from that device. Hiding a device prevents nodes on the part of the internet from which it is hidden from knowing the name of the hidden device, making it more difficult for those nodes to access the hidden device. Any AppleTalk Phase 2 router can hide devices.
ルータは、地方のインターネットにおけるデバイスがLkUp-回答パケットをそのデバイスからName Bindingプロトコル(NBP)に送らないことによって特定の部分の上の他のノードかインターネットの他のすべての部分に目に見えるのを防ぐことができます。 デバイスを隠すと、ノードは隠されたデバイスの名前を知っているそれを隠されるインターネット側の防がれます、それらのノードが隠されたデバイスにアクセスするのをより難しくして。 どんなAppleTalk Phase2ルータもデバイスを隠すことができます。
Advantages and Disadvantages
利点と損失
Device hiding is a flexible security mechanism that is appropriate for organizations that do not require true device-specific security. It is not a substitute for device-specific security. Device hiding can provide a degree of security on devices for which no other form of security exists-such as LaserWriter printers.
デバイス隠れることは本当のデバイス特有のセキュリティを必要としない組織に、適切なフレキシブルなセキュリティー対策です。 それはデバイス特有のセキュリティの代用品ではありません。 デバイス隠れることがセキュリティどんな他のものも形成しないデバイスでセキュリティの度合いを提供できる、存在、-、LaserWriterプリンタ。
A user can write a program that can obtain access to a hidden device using its AppleTalk address. Device hiding cannot secure a device from a user that is not using NBP to access the device.
ユーザはAppleTalkアドレスを使用することで隠されたデバイスへのアクセスを得ることができるプログラムを書くことができます。 デバイス隠れることはデバイスにアクセスするのにNBPを使用していないユーザからデバイスを固定できません。
Device hiding does not provide true device-specific security. Many devices require device-specific security-for example, AppleShare file servers. Device-specific security can provide various levels of security, and may allow a network administrator to grant access privileges based on registered users and groups.
デバイス隠れることは本当のデバイス特有のセキュリティを提供しません。 多くのデバイスが例えば、デバイス特有のセキュリティ、AppleShareファイルサーバーを必要とします。 デバイス特有のセキュリティは、様々なレベルのセキュリティを前提とすることができて、ネットワーク管理者が登録ユーザとグループに基づくアクセス権を与えるのを許容するかもしれません。
Configuring Device Hiding on a Port
ポートの上のデバイス隠れることを構成します。
When configuring a port on a router that implements device hiding, a network administrator should be able to hide any device that is accessible through that port from the other ports on the router. The
デバイス隠れることを実装するルータのポートを構成するとき、ネットワーク管理者はルータの他のポートからどんなそのポートを通してアクセスしやすいデバイスも隠すことができるべきです。 The
Oppenheimer [Page 57] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[57ページ]RFC1504Appletalk
device being hidden need not reside on the network connected directly to the port being configured.
隠されるデバイスは構成されていて、直接ポートに接続されたネットワークに住む必要はありません。
An administrator should be able to specify the ports from which to hide a device-either specific ports or all other ports.
管理者はどちらかデバイスの特定のポートか他のすべてのポートを隠すポートを指定できるべきです。
When hiding devices, an administrator should be able to specify that a list of devices either be hidden or visible. The device list should include device names and device types-for example, We-B- Nets:AFPServer. An administrator should also be able to hide all devices of a given type-for example, all LaserWriter printers-or all devices of all types.
デバイスを隠すとき、管理者は、デバイスのリストが隠されると指定するのにおいて有能であるか、または目に見えるべきです。 または、We-Bは網状になります: デバイスリストは装置名と例えばデバイスタイプを含んでいるはずです、また、AFPServer管理者は例えば、与えられたタイプのすべてのデバイスを隠すことができるべきです、すべてのLaserWriter、プリンタ、-、すべてのすべてのデバイスがタイプされます。
Filtering NBP LkUp-Reply Packets
NBP LkUp-回答パケットをフィルターにかけます。
To implement device hiding, a router selectively filters NBP LkUp- Reply packets. When a port's configuration specifies that devices accessible through the port be hidden, the router
デバイス隠れることを実装するために、ルータは選択的にNBP LkUp回答パケットをフィルターにかけます。 ポートの構成が、ポートを通してアクセスしやすいデバイスが隠されると指定するときルータ
monitors all NBP LkUp-Reply packets received through that port-
called the incoming port
すべてのNBP LkUp-回答パケットが入って来るポートと呼ばれるそのポートを通して受けたモニター
determines the port through which it is to forward such a packet-
called the outgoing port
それが出発しているポートと呼ばれるそのようなパケットを進めることになっているポートを決定します。
obtains-from the port configuration for the incoming port-the list
of devices to be hidden from the outgoing port
入手、-、入来のためのポート構成、ポート、-、出発しているポート隠されるデバイスのリスト
determines whether it should filter all or part of an NBP LkUp-
Reply packet
それがNBP LkUp回答パケットのすべてか一部をフィルターにかけるべきであるかどうか決定します。
If a port's configuration does not specify that devices be
hidden from the outgoing port, the router forwards the packet.
ポートの構成が、出発しているポートデバイスを隠されると指定しないなら、ルータはパケットを進めます。
If a port's configuration specifies that devices be hidden from
the outgoing port, the router checks each tuple in the NBP LkUp-
Reply packet to determine whether it is from a device in the
port's list of hidden devices. It marks tuples from hidden
devices for deletion. Once the router scans the entire packet,
it forwards the packet if no tuples were marked for deletion; it
discards the packet if all tuples were marked for deletion; or,
if only some tuples were marked for deletion, it rebuilds the
packet without the tuples marked for deletion, then forwards the
packet.
ポートの構成が、出発しているポートデバイスを隠されると指定するなら、ルータは、それがポートの隠されたデバイスのリストでデバイスから来ているかを決定するためにNBP LkUp回答パケットの各tupleをチェックします。 それは削除のための隠されたデバイスからtuplesをマークします。 ルータがいったん全体のパケットをスキャンして、tuplesが全く削除のためにマークされなかったなら、パケットを進めます。 すべてのtuplesが削除のためにマークされたなら、それはパケットを捨てます。 または、いくらかだけのtuplesが削除のためにマークされたなら、それは、削除のためにマークされたtuplesなしでパケットを再建して、次に、パケットを進めます。
When the router rebuilds a packet, it adjusts the tuple count in the packet's NBP header to reflect the number of tuples remaining. If a rebuilt packet's DDP header contains a nonzero checksum, the router
ルータがパケットを再建するとき、それは、tuplesの残りの数を反映するようにパケットのNBPヘッダーでtupleカウントを調整します。 再建されたパケットのDDPヘッダーが非零チェックサム、ルータを含んでいるなら
Oppenheimer [Page 58] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[58ページ]RFC1504Appletalk
verifies the original checksum, then sets it to 0.
オリジナルのチェックサムについて確かめて、次に、0にそれを設定します。
This device-hiding scheme can handle both NBP Lookups and NBP Confirms, because a node responds to requests of either type with a LkUp-Reply packet.
このデバイスを隠す体系はNBP LookupsとNBP Confirmsの両方を扱うことができます、ノードがLkUp-回答パケットがあるタイプの要求に応じるので。
LkUp-Reply packets do not contain the names of zones in which devices reside. Thus, if two devices having the same name and type are accessible through a port, a network administrator can hide both devices or neither device, but not just one of the devices.
LkUp-回答パケットはデバイスが住んでいるゾーンの名前を含んでいません。 したがって、同じ名前とタイプがある2台のデバイスがポートを通してアクセスしやすいなら、ネットワーク管理者はちょうどデバイスの1つではなく、デバイスもデバイスの両方も隠すことができません。
When configuring ports on routers through which redundant paths to a device exist, a network administrator must hide that device on at least one port on each path to that device. Otherwise, only a router on which such a port was configured to hide the device would filter LkUp-Reply packets from the device. A router on which such a port was not configured to hide the device would not filter its LkUp-Reply packets. Figure 4-1 shows the proper configuration of device hiding when a loop exists on the internet.
デバイスへの冗長パスが存在するルータのポートを構成するとき、ネットワーク管理者は各経路の少なくとも1つのポートの上にそのデバイスをそのデバイスに隠さなければなりません。 そのようなポートがデバイスを隠すために構成されたルータだけがデバイスからLkUp-回答パケットをフィルターにかけるでしょう。 そのようなポートがデバイスを隠すために構成されなかったルータはLkUp-回答パケットをフィルターにかけないでしょう。 図4-1は、輪がいつインターネットに存在するかをデバイス隠れることの適切な構成に示します。
<<Figure 4-1 Device hiding when a loop exists on the internet>>
<<数値4-1輪がインターネット>>に存在していると隠れるDevice
Resolving Network-Numbering Conflicts
ネットワークに付番する闘争を解決します。
In addition to interconnecting different parts of one organization's internet, tunnels can interconnect the internets of multiple organizations. Each organization administrates its internet independently. Therefore, conflicting network numbers may exist on the internets, especially when many internets are interconnected. The following sections describe the methods that AURP uses to resolve various problems due to conflicting network numbers.
1つの組織のインターネットの異なった部品とインタコネクトすることに加えて、トンネルは複数の組織のインターネットとインタコネクトできます。 各組織は独自にインターネットを管理します。 したがって、特に多くのインターネットがインタコネクトされるとき、闘争ネットワーク・ナンバーはインターネットに存在するかもしれません。 以下のセクションはAURPが闘争するのによる様々な問題が数をネットワークでつなぐと決議するのに使用するメソッドを説明します。
Network-Number Remapping
ネットワーク・ナンバーRemapping
Network-number remapping resolves network-numbering conflicts, allowing network administrators to build very large internets. When configuring a port on an exterior router, an administrator can specify a range of AppleTalk network numbers to be used for imported networks-that is, networks that are accessible through half-routing or tunneling ports, for which the exterior router imports routing information from other exterior routers. The remapping range-the range of network numbers reserved for network-number remapping-must not conflict with any network numbers already in use on the exterior router's local internet.
ネットワーク管理者が非常に大きいインターネットを築き上げるのを許容して、ネットワーク・ナンバー再写像はネットワークに付番する闘争を解決します。 外のルータのポートを構成するとき、管理者はすなわち、ネットワークをネットワークでつないでインポートされて、使用されるさまざまな半分ルーティングでアクセスしやすいAppleTalkネットワーク番号かトンネリングポートを指定できます。(外のルータはポートに関してルーティングが他の外のルータからの情報であるとインポートします)。 再写像、範囲、-、どんなネットワーク・ナンバーも既に使用中の状態で闘争ではなく、ネットワーク・ナンバー再写像必須のために外のルータの地方のインターネットで予約されたネットワーク・ナンバーの範囲。
The exterior router maps the network numbers in incoming packets into the remapping range. It converts remapped network numbers back to their actual network numbers for outgoing packets. To nodes and
外のルータは入って来るパケットで再写像範囲にネットワーク・ナンバーを写像します。 それはそれらの出発しているパケットの実際のネットワーク・ナンバーに再写像しているネットワーク・ナンバーを変換して戻します。 そしてノード。
Oppenheimer [Page 59] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[59ページ]RFC1504Appletalk
routers within the exterior router's local internet, packets containing remapped network numbers apparently originate from or are being sent to networks having numbers in the remapping range.
外のルータの地方のインターネットの中のルータ、パケット含有を数が明らかに発するネットワークを再写像したか、または再写像範囲に数を持っているネットワークに送ります。
UNIQUE IDENTIFIERS: In a tunneling environment, many different internets may include AppleTalk networks that have the same network numbers. Therefore, each exterior router on an internet must associate a unique identifier (UI) with each network that it exports across the tunnel-that is, each network in its local internet that is not hidden. Generally, some type of global administration of UIs is necessary.
ユニークな識別子: トンネリング環境では、多くの異なったインターネットが同じネットワーク・ナンバーを持っているAppleTalkネットワークを含むかもしれません。 したがって、インターネットに関するそれぞれの外のルータはそれがすなわち、それぞれトンネルネットワークの向こう側に隠されない地方のインターネットでエクスポートする各ネットワークにユニークな識別子(UI)を関連づけなければなりません。 一般に、タイプのUIsのグローバルな管理が必要です。
On a given tunnel, each exterior router on which network-number remapping is active must have a unique domain identifier (DI). An exterior router using AURP derives a network's UI by concatenating the exterior router's DI-which is unique on the tunnel-with the packet's network number or range-which is unique within the exterior router's domain. For more information about domain identifiers, see the section "Domain Identifiers" in Chapter 2.
与えられたトンネルの上では、ネットワーク・ナンバー再写像がアクティブであるそれぞれの外のルータはユニークなドメイン識別子(DI)を持たなければなりません。 または、AURPを使用する外のルータが外のルータのものを連結することによってネットワークのUIを引き出す、DI、-、どれ、ユニークであるか、トンネル、-、パケットのネットワーク・ナンバー、範囲、-、どれ、外のルータのドメインの中でユニークであるか。 ドメイン識別子に関する詳しい情報に関しては、第2章の「ドメイン識別子」というセクションを見てください。
On a tunneling port, an exterior router refers to AppleTalk network numbers and network ranges using UIs. Whenever an exterior router sends or receives AppleTalk data packets across the tunnel, it refers to any network numbers or ranges in the packets-for example, in a packet's DDP header-by their UIs. For example, when an exterior router sends an RI- Rsp, which provides a list of network ranges for its local internet to other exterior routers on the tunnel, it lists the UIs corresponding to those network ranges. When an exterior router receives RI-Rsp packets from other exterior routers on the tunnel, it interprets the data in each packet as a list of UIs.
トンネリングポートの上では、外のルータは、UIsを使用することでAppleTalkネットワーク番号とネットワーク範囲を示します。 外のルータがトンネルの向こう側にAppleTalkデータ・パケットを送るか、または受けるときはいつも、それは、どんなネットワーク・ナンバーについても言及するか、または例えばパケット(近くパケットのDDPヘッダーのそれらのUIs)のねらいを定めます。 外のルータがロードアイランドRsp(トンネルの上で他の外のルータへの地方のインターネットにネットワーク範囲のリストを提供する)を送るとき、例えば、それはそれらのネットワーク範囲に対応するUIsを記載します。 外のルータがトンネルの上で他の外のルータからロードアイランド-Rspパケットを受けるとき、それはUIsのリストとして各パケットでデータを解釈します。
Network-number remapping should be an optional component of any tunneling scheme. An administrator should be able to configure a tunneling port with or without specifying network-number remapping. When network-number remapping is inactive on all of the exterior routers on a tunnel, each AppleTalk network number and range associated with the exterior routers must be unique.
ネットワーク・ナンバー再写像はどんなトンネリング体系の任意のコンポーネントであるべきです。 指定するか、またはネットワーク・ナンバー再写像を指定しないで、管理者はトンネリングポートを構成できるべきです。 ネットワーク・ナンバー再写像がトンネルで外のルータのすべてで不活発であるときに、外のルータに関連づけられたそれぞれのAppleTalkネットワーク番号と範囲はユニークであるに違いありません。
MAPPINGS: An exterior router uses the following process to map AppleTalk network numbers and ranges to UIs, and vice versa:
マッピング: 外のルータは、AppleTalkネットワーク番号を写像するのに以下のプロセスを使用して、UIsに変化します、そして、逆もまた同様です:
The exterior router logically maps network numbers in the exterior
router's local internet to the corresponding UIs before sending a
packet out the tunneling port, as shown in Figure 4-2. The UI
consists of the source DI in the domain header and the network
number from the packet. Therefore, the exterior router changes no
data in the packet to perform this mapping.
トンネリングポートからパケットを送る前に外のルータは外のルータの地方のインターネットにおけるネットワーク・ナンバーを対応するUIsに論理的に写像します、図4-2に示されるように。 UIはドメインヘッダーというソースDIとパケットからのネットワーク・ナンバーから成ります。 したがって、外のルータは、このマッピングを実行するためにパケットでデータを全く変えません。
Oppenheimer [Page 60] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[60ページ]RFC1504Appletalk
The exterior router logically maps UIs corresponding to local
networks in packets received through the tunneling port back to
their local network numbers before forwarding the packets to the
exterior router's local internet, as shown in Figure 4-2. The
exterior router changes no data in the packet. This mapping is the
inverse of the previous mapping.
外のルータの地方のインターネットにパケットを送る前に外のルータはトンネリングポートを通して受け取られたパケットの企業内情報通信網に対応するUIsをそれらの企業内情報通信網番号に論理的に写像して戻します、図4-2に示されるように。 外のルータはパケットでデータを全く変えません。 このマッピングは前のマッピングの逆です。
The exterior router maps UIs corresponding to network numbers for
remote networks-that is, networks connected to other exterior
routers on the tunnel-that are in packets received through the
tunneling port to network numbers in the remapping range configured
for the local internet, as shown in Figure 4-2. An exterior router
remaps network numbers from the following fields in this way:
外のルータ、リモートな状態で数をネットワークでつなぐために対応するUIsを写像する、すなわち、ネットワークがネットワークであることで他の外のルータに接続する、それにトンネルを堀るのがトンネリングポートを通して中の再写像範囲が地方のインターネットのために構成したネットワーク・ナンバーに受け取られたパケットにあります、図4-2に示されるように。 このように以下の分野からの外のルータ「再-地図」ネットワーク・ナンバー:
the source network number field in the DDP header of an
AppleTalk data packet
AppleTalkデータ・パケットのDDPヘッダーのソースネットワークナンバーフィールド
the NBP entity address field in an AppleTalk data packet
AppleTalkデータ・パケットのNBP実体アドレス・フィールド
the routing data field in an AURP routing-information packet
AURPルーティング情報パケットのルーティングデータ・フィールド
The exterior router maps network numbers in the remapping range
configured for the local internet back to the corresponding UIs
before sending packets out the tunneling port, as shown in Figure
4-2. This type of remapping applies only to network numbers that
reside in a destination network-number field of a DDP header in an
AppleTalk data packet. This mapping is the inverse of the previous
mapping.
パケットを出す前に再写像範囲のネットワーク・ナンバーが地方のインターネットのために構成した外のルータ地図は対応するUIsにトンネリングポートを支持します、図4-2に示されるように。 このタイプの再写像はAppleTalkデータ・パケットにDDPヘッダーの目的地ネットワーク・ナンバー分野にあるネットワーク・ナンバーだけに適用されます。 このマッピングは前のマッピングの逆です。
<<Figure 4-2 Mappings between local and remote internets' network
numbers and UIs>>
<<数値4-2地方の、そして、リモートなインターネットのネットワーク・ナンバーとUIs>>の間のMappings
NOTE: Network-number remapping changes an AppleTalk data packet's DDP header and may also change its data. Thus, if a packet contains a DDP checksum, when the exterior router remaps network numbers contained in the packet, it must verify that the checksum is correct, then set the checksum to 0. If the checksum is incorrect, the exterior router should discard the packet.
以下に注意してください。 ネットワーク・ナンバー再写像は、AppleTalkデータ・パケットのDDPヘッダーを変えて、また、データを変えるかもしれません。 したがって、外のルータ「再-地図」がパケットに含まれた数をネットワークでつなぐとき、パケットがDDPチェックサムを含んでいるなら、それは、チェックサムが正しいことを確かめて、次に、0にチェックサムを設定しなければなりません。 チェックサムが不正確であるなら、外のルータはパケットを捨てるべきです。
An exterior router can perform network-number remapping either statically or dynamically. Static remapping reserves specific network numbers in the remapping range for mapping specific UIs. Dynamic remapping assigns network numbers in the remapping range to networks as they become known to an exterior router.
外のルータは静的かダイナミックにネットワーク・ナンバー再写像を実行できます。 静的な再写像は、特定のUIsを写像するために再写像範囲で特定のネットワーク・ナンバーを予約します。 外のルータに知られるようになるとき、ダイナミックな再写像は再写像範囲でネットワークにネットワーク・ナンバーを配属します。
Static remapping is simpler to implement and provides a known mapping for use in network management. However, it may limit the number of UIs that an exterior router can import into its local internet.
静的な再写像は、実装するのが、より簡単であり、ネットワークマネージメントにおける使用のための知られているマッピングを提供します。 しかしながら、それは外のルータが地方のインターネットにインポートすることができるUIsの数を制限するかもしれません。
Oppenheimer [Page 61] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[61ページ]RFC1504Appletalk
Dynamic mapping requires a scheme for network number reuse, but may provide connectivity to a greater number of networks across a tunnel.
ダイナミックなマッピングは、ネットワーク・ナンバー再利用のために体系を必要としますが、トンネルの向こう側により大きい数のネットワークに接続性を提供するかもしれません。
To avoid having the same UI refer to two different networks when remapping network numbers dynamically, an exterior router should reuse network numbers in its remapping range only when no other network numbers are available. If a network goes down, an exterior router should not immediately reassign the UI that referred to that network to another network that just came up on the internet.
他のどんなネットワーク・ナンバーも有効でないときにだけ、ダイナミックにネットワーク・ナンバーを再写像するとき、同じUIに2つの異なったネットワークを示させるのを避けるために、外のルータは再写像範囲でネットワーク・ナンバーを再利用するべきです。 ネットワークが落ちるなら、外のルータはすぐに、ただインターネットに近づいた別のネットワークとそのネットワークを呼んだUIを再選任するべきではありません。
An exterior router connected to more than one tunnel should function as though it were two exterior routers-each connected to one tunnel and both connected to one AppleTalk internet. Thus, such an exterior router must use remapped network numbers when sending routing information across a tunnel about networks that are accessible through another tunnel.
1つ以上のトンネルに接続された外のルータはまるでそれがそれぞれ1つのトンネルに接続されて、ともに1つのAppleTalkインターネットに関連づけられた2つの外のルータであるかのように機能するべきです。 トンネルの向こう側に別のトンネルを通ってアクセスしやすいネットワークに関してルーティング情報を送るとき、したがって、外のルータが使用しなければならないそのようなものはネットワーク・ナンバーを再写像しました。
Network Numbers in Data
データのネットワーク・ナンバー
To remap network numbers properly, an exterior router must be aware of their presence within AppleTalk data packets. It is difficult to detect network numbers in data packets, because they could be anywhere within a data packet. For example, NBP includes network addresses as part of its data-in entity addresses. However, the data packets for very few protocols contain any network numbers. Some third-party protocols may contain network addresses in their data. Protocols that contain network addresses in their data may not function properly across remapping exterior routers.
remapネットワーク・ナンバーに、適切に、外のルータはAppleTalkデータ・パケットの中でそれらの存在を意識していなければなりません。 それらがデータ・パケットの中でどこでもあるかもしれないので、データ・パケットにネットワーク・ナンバーを検出するのは難しいです。 例えば、NBPは中のデータ実体アドレスの一部としてネットワーク・アドレスを含んでいます。 しかしながら、ほんのわずかなプロトコルのためのデータ・パケットはどんなネットワーク・ナンバーも含んでいます。 いくつかの第三者プロトコルがそれらのデータのネットワーク・アドレスを含むかもしれません。 外のルータを再写像することの向こう側にそれらのデータのネットワーク・アドレスを含むプロトコルは適切に機能しないかもしれません。
Packets used for network management-such as RTMP Route Data Response (RDR) and Simple Network Management Protocol (SNMP) packets-contain network numbers in their data. For detailed information about handling network numbers in SNMP packets, see the section "Network Management" later in this chapter.
RTMP Route Data Response(RDR)とSimple Network Managementプロトコル(SNMP)はネットワーク・ナンバーをパケットで含んでいます。パケット、使用される、ネットワークマネージメントそのようなもの、それらのデータで。 SNMPパケットの取り扱いネットワーク・ナンバーの詳細な情報に関しては、後で本章で「ネットワークマネージメント」というセクションを見てください。
Problems With Loops
輪に関する問題
Network-number remapping introduces some problems on an internet when loops exist across a tunnel. If network-number remapping is active, two AppleTalk internets connected by a tunnel should not be interconnected in any other way. If a redundant path to an internet exists, a remapped network range can loop back through that path to the exterior router that originally remapped the network range. When this occurs, two different network ranges-the network range actually configured and the remapping of the configured range-refer to one network.
輪がトンネルの向こう側に存在していると、ネットワーク・ナンバー再写像はインターネットでいくつかの問題を紹介します。 ネットワーク・ナンバー再写像がアクティブであるなら、いかなる他の方法でもトンネルによって接続された2つのAppleTalkインターネットとインタコネクトするべきではありません。 インターネットへの冗長パスが存在しているなら、再写像しているネットワーク範囲はその経路を通して元々ネットワーク範囲を再写像した外のルータに輪にされることができます。 構成は範囲で示されます。いつ、これは起こります、2の異なったネットワーク、範囲、-、実際に構成された範囲と再写像をネットワークでつなぐか、1つのネットワークに。
Oppenheimer [Page 62] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[62ページ]RFC1504Appletalk
The remapped network range apparently refers to a new network in the exterior router's local internet. Such a network is referred to as a shadow network. The exterior router cannot determine that it has received a network range that it had previously remapped, because there is no apparent difference between a remapped network range and an actual network range. Thus, unless an administrator configures an exterior router with an explicit list of networks to export, the exterior router again remaps the network range, then exports the remapped network range, sending it around the loop. The network range is remapped repeatedly until the apparent distance to the network exceeds the hop-count limit. Exterior routers that implement network-number remapping should avoid establishing such infinite loops. For information about preventing such loops, see the section "Routing Loops" later in this chapter.
再写像しているネットワーク範囲は外のルータの地方のインターネットで明らかに新しいネットワークを示します。 そのようなネットワークは影のネットワークと呼ばれます。 外のルータは、以前に再写像したネットワーク範囲を取ったことを決定できません、再写像しているネットワーク範囲と実際のネットワーク範囲の間には、どんな見かけの違いもないので。 したがって、管理者がネットワークの明白なリストで外のルータを構成しない場合、輪の周りにそれを送って、輸出、再び外のルータ「再-地図」へのネットワークは、及んで、次に、再写像しているネットワーク範囲をエクスポートします。 ネットワークへの角距離がホップカウント限界を超えるまで、ネットワーク範囲は繰り返して再写像されます。 ネットワーク・ナンバー再写像を実装する外のルータは、そのような無限ループを確立するのを避けるべきです。 そのような輪を防ぐことの情報に関しては、後で本章で「ルート設定輪」というセクションを見てください。
Redundant Paths
冗長パス
Under certain circumstances, it might be desirable to create a redundant path, which is a special type of loop. Redundant paths connect an internet to a tunnel through two or more exterior routers. If network-number remapping is active, all redundant exterior routers must use the same DI to represent the local internet-and must map UIs representing remote networks in incoming packets to the same local network numbers.
ある状況で、冗長パスを作成するのは望ましいかもしれません。(冗長パスは特別なタイプの輪です)。 冗長パスは2つ以上の外のルータを通してインターネットをトンネルに接続します。 そして、ネットワーク・ナンバー再写像がアクティブであるなら、すべての余分な外のルータが地方を表すのに同じDIを使用しなければならない、インターネット、-、入って来るパケットで同じ企業内情報通信網番号にリモートネットワークを代表する地図UIsはそうしなければなりません。
To allow redundant exterior routers to achieve such cooperation, a network administrator might configure all redundant exterior routers with the same DI and complete remapping information for all imported networks. Alternatively, a network administrator might configure one exterior router with this information and all redundant exterior routers could obtain the information from the configured exterior router. AURP does not currently support this functionality, but may do so in the future.
ネットワーク管理者は、余分な外のルータがそのような協力を実現するのを許容するために、同じDIですべての余分な外のルータを構成して、ネットワークであるとインポートされる限り、情報を再写像するのを完成するかもしれません。 あるいはまた、ネットワーク管理者は、この情報とすべての余分な外のルータがある1つの外のルータが構成された外のルータから情報を得るかもしれないのを構成するかもしれません。 AURPは現在この機能性をサポートしませんが、将来、そうするかもしれません。
Tunnels With Partial Network-Number Remapping
部分的なネットワーク・ナンバーRemappingをもっているTunnels
When network-number remapping is active on a tunneling port, an exterior router maps network numbers in packets received through the tunnel into the remapping range for its local internet. Because a network administrator configures network-number remapping on individual exterior routers, network-number remapping may be configured on some exterior routers on a tunnel, but not on others- potentially causing network-numbering conflicts due to partial network-number remapping. Whenever possible, an administrator should configure network-number remapping either on all exterior routers on a tunnel or on none of them. Otherwise, network-numbering conflicts are likely to occur on some of the exterior routers-especially on large, interorganizational internets.
ネットワーク・ナンバー再写像がトンネリングポートでアクティブであるときに、外のルータは地方のインターネットのためにトンネルを通って再写像範囲に受け取られたパケットでネットワーク・ナンバーを写像します。 ネットワーク管理者が個々の外のルータで再写像されるネットワーク・ナンバーを構成するので、ネットワーク・ナンバー再写像は、トンネルの上のいくつかの外のルータで構成されますが、潜在的に部分的なネットワーク・ナンバーによるネットワークに付番する闘争を引き起こす他のもの再写像に関して構成されるかもしれないというわけではありません。 可能であるときはいつも、管理者はトンネルの上のすべての外のルータの上、または、それらのどれかの上で再写像されないネットワーク・ナンバーを構成するべきです。 さもなければ、ネットワークに付番する闘争は大きいinterorganizationalインターネットに特に外のルータのいくつかに起こりそうです。
Oppenheimer [Page 63] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[63ページ]RFC1504Appletalk
In addition to potential network-numbering conflicts, partial network-number remapping and the lack of loop detection between nonremapping exterior routers may cause shadow copies of networks connected to more than one nonremapping exterior router to appear in the routing tables on remapping exterior routers.
潜在的ネットワークに付番する闘争に加えて、外のルータを再写像するとき、1つ以上のnonremappingの外のルータに接続されたネットワークの影のコピーは経路指定テーブルに部分的なネットワーク・ナンバー再写像と外のルータをnonremappingすることの間の輪の検出の不足で現れるかもしれません。
An exterior router on which network-number remapping is active performs loop detection. Therefore, when network-number remapping is active on all of the exterior routers on a tunnel, no loops can exist across the tunnel. However, exterior routers on which network-number remapping is not active do not perform loop detection. Thus, when network-number remapping is not active on some of the exterior routers on a tunnel, any loops that exist between nonremapping exterior routers are not detected.
ネットワーク・ナンバー再写像がアクティブである外のルータは輪の検出を実行します。 したがって、ネットワーク・ナンバー再写像がトンネルで外のルータのすべてでアクティブであるときに、輪は全くトンネルの向こう側に存在できません。 しかしながら、ネットワーク・ナンバー再写像がアクティブでない外のルータは輪の検出を実行しません。 ネットワーク・ナンバー再写像がトンネルで外のルータのいくつかでアクティブでないときに、したがって、外のルータをnonremappingするとき存在するどんな輪も検出されません。
In the example shown in Figure 4-3, shadow copies of all networks that are in the local internets of both exterior router B and exterior router C, on which network-number remapping is not active, appear in the routing table of exterior router A, on which network- number remapping is active.
図4-3の例では、ネットワーク・ナンバー再写像がアクティブでない外のルータBと外のルータCの両方の地方のインターネットにはあるすべてのネットワークの影のコピーは外のルータAの経路指定テーブルに現れます。(そこでは、ネットワーク数の再写像がアクティブです)。
<<Figure 4-3 A tunnel with partial network-number remapping>>
<<数値4-3部分的なネットワーク・ナンバーが>>を再写像しているAトンネル
Clustering Remapped Networks
クラスタリングRemappedネットワーク
Because a remapping range is a range of sequential network numbers, an exterior router can represent multiple remapped networks as a single extended network within its local internet-that is, it can cluster remapped networks. Clustering greatly reduces the size of the routing tables that are maintained and sent by routers within an internet, as well as the amount of RTMP traffic on the internet. Clustering may also reduce the amount of NBP traffic on an internet.
再写像範囲がさまざまな連続したネットワーク・ナンバーであるので外のルータがただ一つの拡大ネットワークとしてローカルの中で複数の再写像しているネットワークを代表することができる、インターネット、-それはそうです、それ、再写像しているネットワークをクラスタリングさせることができます。 クラスタリングはインターネットの中でルータによって維持されて、送られる経路指定テーブルのサイズを大いに減少させます、インターネットに関するRTMPトラフィックの量と同様に。 また、クラスタリングはインターネットでNBPトラフィックの量を減少させるかもしれません。
For example, as shown in Figure 4-4, if networks in an internet have the numbers 1, 100, and 1000, and an exterior router connected to a different part of the internet receives these network numbers across the tunnel, that exterior router might remap the network numbers to 21, 22, and 23. When sending RTMP packets within its local internet, the remapping exterior router can represent the three networks as a single extended network with a network range from 21 to 23. The zones associated with the extended network include all of the zones associated with the three imported network numbers.
例えば、図4-4に示されるように、インターネットにおけるネットワークにはNo.1、100、および1000があって、インターネットの異なった部分に関連づけられた外のルータがトンネルの向こう側にこれらのネットワーク・ナンバーを受けるなら、その外のルータは21、22、および23にネットワーク・ナンバーをremapするかもしれません。 地方のインターネットの中でパケットをRTMPに送るとき、再写像の外のルータはただ一つの拡大ネットワークとして21〜23までのネットワーク範囲で3つのネットワークを代表することができます。 拡大ネットワークに関連しているゾーンはネットワーク・ナンバーであるとインポートされる3に関連しているゾーンのすべてを含んでいます。
<<Figure 4-4 Clustering remapped network numbers>>
<<数値4-4Clustering remappedネットワーク・ナンバー>>。
An exterior router determines which remapped network numbers it should cluster. For example, an exterior router might create one cluster for each other exterior router on the tunnel. However, an
外のルータは、どれがそれがクラスタリングさせるべきであるネットワーク・ナンバーを再写像したかを決定します。 例えば、外のルータは外で互いのための1個のクラスタを作成するかもしれません。トンネルの上のルータ。 しかしながら
Oppenheimer [Page 64] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[64ページ]RFC1504Appletalk
exterior router can include no more than 255 zones in one cluster.
外のルータは1個のクラスタの255未満のゾーンを含むことができます。
An exterior router that implements clustering must maintain the actual network range and zone list for each network in a cluster. The exterior router monitors all NBP FwdReq packets to be forwarded across the tunnel-including those it generates in response to BrRq packets. It examines the DDP destination network number in each FwdReq packet to determine the cluster to which it is addressed. The exterior router then generates one FwdReq packet for each clustered network for which the FwdReq packet contains a zone name, and sends that packet to the next internet router for the network. The DDP destination network number in such a FwdReq packet corresponds to the starting network number of a network's actual network range.
クラスタリングを実装する外のルータはひとかたまりになって各ネットワークのための実際のネットワーク範囲とゾーンリストを維持しなければなりません。 外のルータはそれがBrRqパケットに対応して生成するトンネルを含むものの向こう側に進められるすべてのNBP FwdReqパケットをモニターします。 それは、それが扱われるクラスタを決定するためにそれぞれのFwdReqパケットでDDP目的地ネットワーク・ナンバーを調べます。 外のルータは、次に、FwdReqパケットがゾーン名を含むそれぞれのクラスタリングしているネットワークのために1つのFwdReqパケットを生成して、ネットワークのために次のインターネットルータにそのパケットを送ります。 そのようなFwdReqパケットのDDP目的地ネットワーク・ナンバーはネットワークの実際のネットワーク範囲の始めのネットワーク・ナンバーに対応しています。
A disadvantage of clustering is that clusters are static. An exterior router cannot notify its local internet that a specific network or zone in a cluster has gone down. An exterior router's implementation of clustering could allow a network administrator to initiate reclustering-in which the exterior router notifies the internet that an entire cluster has gone down, then creates a new cluster that does not include the networks that have gone down. However, such reclustering would cause a temporary loss of connectivity to those networks in the cluster that are still accessible. Therefore, an exterior router should not automatically recluster network numbers.
クラスタリングの不都合はクラスタが静的であるということです。 外のルータは、特定のネットワークかゾーンがひとかたまりになって落ちたことを地方のインターネットに通知できません。 外のルータのクラスタリングの実装は、ネットワーク管理者が中の外のルータが全体のクラスタが下ったインターネットに通知する再クラスタリングを開始するのを許容できて、次に、落ちたネットワークを含んでいない新しいクラスタを作成します。 しかしながら、そのような再クラスタリングが、クラスタのそれらのまだアクセスしやすいネットワークに接続性の一時的な損失をもたらすでしょう。 したがって、外のルータは自動的でなく「再-クラスタ」ネットワーク・ナンバーがそうするべきです。
REUSING NETWORK NUMBERS WITHIN A CLUSTER: Under certain conditions, an exterior router that implements clustering might reuse network numbers within a cluster. If a network went down, then came back up with the same zone list, an exterior router could map its network range into the same remapping range and include it in the same cluster. Otherwise, an exterior router should not reuse network numbers within a cluster, unless no other network numbers within the remapping range are available. In any case, an exterior router can reuse network numbers within a cluster only if a new network has a network range that fits in an unused range of network numbers within the cluster and a zone list that is a subset of the cluster's zone list.
クラスタの中にネットワーク・ナンバーを再利用します: 一定の条件の下で、クラスタリングを実装する外のルータはクラスタの中にネットワーク・ナンバーを再利用するかもしれません。 ネットワークが落ちて、次に、同じゾーンリストを思いついて戻すなら、外のルータは、同じ再写像範囲にネットワーク範囲を写像して、同じクラスタにそれを含むかもしれないでしょうに。 さもなければ、外のルータはクラスタの中にネットワーク・ナンバーを再利用するべきではありません、再写像範囲の中の他のネットワーク・ナンバーがないのが有効でない場合。 どのような場合でも、新しいネットワークにクラスタの中に未使用の範囲のネットワーク・ナンバーをうまくはめ込むネットワーク範囲とクラスタのゾーンリストの部分集合であるゾーンリストがある場合にだけ、外のルータはクラスタの中にネットワーク・ナンバーを再利用できます。
The implementation of clustering in an exterior router is complex. See the Appendix, "Implementation Details," for some ways in which clustering could be implemented.
外のルータでクラスタリングする実装は複雑です。 Appendix、クラスタリングを実装することができたいくつかの方法のための「実装の詳細」を見てください。
Zone-Name Management
ゾーン名の管理
To enhance zone-name management within an AppleTalk internet, AURP provides Get Domain Zone List and Get Zone Nets requests-which function similarly to the ZIP GetZoneList command and ZI-Req command, respectively. However, as when using RTMP and ZIP, if two networks in
AppleTalkインターネットの中でゾーン名の管理を機能アップするために、AURPがGet Domain Zone ListとGet Zoneにネットを供給する、要求、-、どれ、機能は同様にそれぞれZIP GetZoneListコマンドとZI-Reqに命令するか。 しかしながら、いつのRTMPを使用して、ZIP中の2つのネットワークであるか。
Oppenheimer [Page 65] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[65ページ]RFC1504Appletalk
an internet include zones that have the same zone name in their zone lists, exterior routers merge the zones into one zone-regardless of whether network-number remapping is active on one or more of the exterior routers.
にかかわらず、同じであるそれらのゾーンリスト、外部のルータがゾーンを合併するゾーン名のを持っているインターネットインクルードゾーン、1つ、ゾーン、-、ネットワーク・ナンバー再写像は外のルータの1つ以上でアクティブであるかどうか
Because AppleTalk data packets often contain zone names, AURP provides no means of remapping zone names. When importing or exporting zone names, an exterior router should not modify them in any way.
AppleTalkデータ・パケットがしばしばゾーン名を含んでいるので、AURPはゾーン名を再写像する手段を全く提供しません。 ゾーン名をインポートするか、またはエクスポートするとき、外のルータは何らかの方法でそれらを変更するべきではありません。
On a very large internet, zone names may become unmanageable. Therefore, an administrator should use domain-specific prefixes-such as Engineering or Sales-for zone names on such an internet. The use of a third-party hierarchical Chooser also might simplify zone-name management.
非常に大きいインターネットでは、ゾーン名は「非-処理しやす」になるかもしれません。 または、したがって、管理者がドメイン特有のそのようなものを前に置いているEngineeringを使用するべきである、Sales、-、ゾーンはそのようなものでインターネットを命名します。 第三者の階層的なChooserの使用もゾーン名の管理を簡素化するかもしれません。
Hop-Count Reduction
ホップカウント減少
Generally, an exterior router increases the hop count in the DDP header of an AppleTalk data packet by at least one when it forwards the packet across a tunnel. Once a packet traverses 15 routers-either local routers or exterior routers-its hop count exceeds the maximum. Thus, when an exterior router receives a packet through its tunneling port, it should examine that packet's DDP hop count before forwarding the packet. If the exterior router receives a packet with a hop count of 15 hops, it does not forward the packet to another router, but discards the packet.
トンネルの向こう側にパケットを進めるとき、一般に、外のルータはAppleTalkデータ・パケットのDDPヘッダーでホップカウントを少なくとも1つ増加させます。 一度、パケットが15個のどちらかルータローカルルータか外部を横断する、ルータ、-、それ、ホップカウントは最大を超えています。 外のルータがトンネリングポートを通してパケットを受けるとき、したがって、パケットを進める前に、それはそのパケットのDDPホップカウントを調べるべきです。 外のルータが15のホップのホップカウントでパケットを受けるなら、それは、別のルータにパケットを送りませんが、パケットを捨てます。
When a tunnel or point-to-point link connects AppleTalk internets, the distance that a packet must traverse can easily exceed 15 hops. A network administrator might need full connectivity between two internets at a distance exceeding 15 hops. If the distance across an exterior router's local internet is already at or near the 15-hop limit, the exterior router must reduce the perceived distance that a packet must traverse to allow the packet to reach a destination at a distance that exceeds 15 hops. To overcome DDP's 15-hop limit, an exterior router reduces the hop count in the DDP header of an Apple data packet received through a tunnel before forwarding the packet into its local AppleTalk internet. An exterior router should reduce the hop count only by the number of hops necessary to allow the packet to reach its destination without exceeding the hop-count limit.
トンネルかポイントツーポイント接続がAppleTalkインターネットを接続するとき、パケットが横断しなければならない距離は容易に15のホップを超えることができます。 ネットワーク管理者は、離れたまま15のホップを超えながら、2つのインターネットの間で完全な接続性を必要とするかもしれません。 限界において、または、ほぼ15ホップの限界で外のルータの地方のインターネットの向こう側の距離が既にあるなら、外のルータはパケットがパケットが15のホップを超えている距離で目的地に達するのを許容するために横断しなければならない知覚された距離を減少させなければなりません。 DDPの15ホップの限界に打ち勝つために、地方のAppleTalkインターネットにパケットを送る前に、外のルータはトンネルを通って受け取られたアップルデータ・パケットのDDPヘッダーでホップカウントを抑えます。 単にパケットがホップカウント限界を超えていなくて目的地に到着するのを許容するのに必要なホップの数に従って、外のルータはホップカウントを抑えるべきです。
When an exterior router receives a packet through the tunnel, it examines the routing-table entry for that packet's destination network to determine the remaining distance to that network. If the distance already traversed by the packet-the packet's current hop count-plus the distance to the destination network is less than 15
外のルータがトンネルを通ってパケットを受けるとき、そのパケットの送信先ネットワークがそのネットワークに残っている距離を測定するように、それは経路指定テーブルエントリーを調べます。 距離が既に横断した、パケット、-、パケットの現在のホップが-そのうえ、送信先ネットワークまで距離を数える、15未満です。
Oppenheimer [Page 66] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[66ページ]RFC1504Appletalk
hops, the exterior router simply forwards the packet. If adding the destination network's distance to the packet's current hop count causes the hop count to exceed 15 hops, the exterior router sets the hop count to the following value: 15 minus the distance in hops to the destination network. The exterior router then forwards the packet.
ホップであり、外のルータは単にパケットを進めます。 ホップカウントがパケットの現在のホップカウントへの送信先ネットワークの距離で15のホップを超えていると言い足すなら、外のルータは以下の値にホップカウントを設定します: 15 送信先ネットワークへのホップの距離を引いて。 そして、外のルータはパケットを進めます。
Using hop-count reduction, an exterior router must overcome the 15- hop limits imposed by both DDP and RTMP. To overcome RTMP's 15-hop limit, an exterior router should represent all networks accessible through the tunnel to routers in its local internet as one hop away when hop-count reduction is active on a tunneling port. This allows routers to maintain and send routing information about networks beyond the 15-hop limit and achieve full connectivity.
ホップカウント減少を使用して、外のルータはDDPとRTMPの両方によって課された15ホップ限界に打ち勝たなければなりません。 ホップカウント減少がトンネリングポートで活発であるときに、RTMPの15ホップの限界に打ち勝つために、外のルータは遠くでワンバウンドとしてトンネルを通って地方のインターネットにおけるルータにアクセスしやすいすべてのネットワークを代表するべきです。 これで、ルータは、ネットワークのルーティング情報を15ホップの限界を超えたところまで保守して、送って、完全な接続性を実現します。
Constraints on Hop-Count Reduction
ホップカウント減少の規制
An interdomain loop exists when a redundant path connects two parts of an internet that are connected through two exterior routers on a tunnel. The proper operation of hop-count reduction requires that no interdomain loops exist across a tunnel. For detailed information about interdomain loops see the next section, "Routing Loops."
冗長パスがトンネルの上の2つの外のルータを通して接続されるインターネットの2つの部品を接続するとき、interdomain輪は存在しています。 ホップカウント減少の適切な操作は、interdomain輪が全くトンネルの向こう側に存在しないのを必要とします。 interdomain輪の詳細な情報に関しては、「輪を発送し」て、次のセクションを見てください。
Because network-number remapping requires that no interdomain loops exist on the internet, an exterior router can perform hop-count reduction whenever network-number remapping is active, without any risk of a packet being forwarded in an infinite routing loop. Generally, an exterior router should not perform loop detection when network-number remapping is inactive.
ネットワーク・ナンバー再写像が、interdomain輪が全くインターネットに存在しないのを必要とするので、ネットワーク・ナンバー再写像がアクティブであるときはいつも、外のルータはホップカウント減少を実行できます、無限のルーティング輪で進められるパケットの少しもリスクなしで。 ネットワーク・ナンバー再写像が不活発であるときに、一般に、外のルータは輪の検出を実行するべきではありません。
Routing Loops
ルート設定輪
A routing loop exists when more than one path connects two exterior routers-both the path through the tunnel and a path through the exterior routers' local internets. When network-number remapping is not active on an exterior router, a routing loop can provide an alternative path to a network. However, when network-number remapping or hop-count reduction is active on an exterior router, all exterior routers must avoid establishing loops across the tunnel. Otherwise, if a routing loop went undetected, multiple routing-table entries that referred to the same actual AppleTalk networks using different remapping ranges might fill the routing tables of all of the exterior routers on a tunnel.
1つの経路がルータの2つの外の両方を接続するより多くときに、ルーティング輪は存在しています。トンネルを通る経路と外のルータの地方のインターネットを通した経路。 ネットワーク・ナンバー再写像が外のルータでアクティブでないときに、ルーティング輪は迂回経路をネットワークに提供できます。 しかしながら、ネットワーク・ナンバー再写像かホップカウント減少が外のルータで活発であるときに、すべての外のルータが、トンネルの向こう側に輪を確立するのを避けなければなりません。 さもなければ、ルーティング輪が察知されずにいるなら、異なった再写像範囲を使用することで同じ実際のAppleTalkネットワークについて言及した複数の経路指定テーブルエントリーがトンネルの上に外のルータのすべての経路指定テーブルをいっぱいにしているでしょうに。
First-Order Loops
一次輪
In a first-order loop, a pair of exterior routers that are performing network-number remapping across a tunnel are also connected through
また、一次輪では、トンネルの向こう側に再写像されるネットワーク・ナンバーを実行している1組の外のルータでは、接続されます。
Oppenheimer [Page 67] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[67ページ]RFC1504Appletalk
another path, on which there are no remapping exterior routers. In Figure 4-5, exterior routers A and B are remapping network numbers across an AppleTalk tunnel, and exterior router C-which is not remapping network numbers-creates a first-order routing loop. Exterior router A's network range, 1 through 4, loops back to it through the tunnel and may be remapped again.
別の経路。(そこには、どんな再写像の外のルータもありません)。 外のルータAとBがAppleTalkトンネル、および外のルータの向こう側に図4-5では、ネットワーク・ナンバーを再写像している、C、-、どれ、ネットワークが数で作成する再写像は一次ルーティング輪ではありませんか? 外のルータAのネットワーク範囲(1〜4)は、トンネルを通ってそれに輪にして戻って、再び再写像されるかもしれません。
<<Figure 4-5 A first-order loop>>
<<数値4-5A一次輪の>>。
Second-Order Loops
第2オーダー輪
In a second-order loop, one or more additional pairs of remapping exterior routers are in the loop. In Figure 4-6, exterior routers A and B are remapping network numbers across the AppleTalk tunnel that connects them, and another pair of exterior routers, C1 and C2-which are also performing remapping across the tunnel that connects them- creates a second-order routing loop. Exterior router A's network range, 1 through 4, is remapped by exterior router C2 to the network range 101 through 104, then loops back to exterior router A through the tunnel.
2番目のオーダー輪には、外のルータを再写像する追加1組以上が輪にあります。 そして、外のルータAとBはそれら、およびもう1組の外のルータを接続するAppleTalkトンネルの向こう側に図4-6では、ネットワーク・ナンバーを再写像しています、C1、C2、-、どれ、また、接続するトンネルの向こう側に再写像しながら働いているか、それら、-、2番目のオーダールーティング輪を作成します。 外のルータAのネットワーク範囲(1〜4)は、外のルータC2によって101〜104にネットワーク範囲に再写像されて、次に、トンネルを通って外のルータAに輪にして戻られます。
<<Figure 4-6 A second-order loop>>
<<数値4-6A2番目のオーダー輪の>>。
Self-Caused and Externally Caused Loops
自己に引き起こされた、外部的に引き起こされた輪
Routing loops can be either self-caused or externally caused. A self- caused loop results when the detecting exterior router itself comes on line. An externally caused loop results when another router comes on line somewhere on the internet, after the detecting router has been running for some time.
ルート設定輪は、自己に引き起こされる場合があるか、または外部的に引き起こされる場合があります。 検出の外のルータ自体が線をつくとき、自己は輪の結果を引き起こしました。 別のルータがインターネットのどこかの線をつくと、外部的に引き起こされた輪は結果として生じます、検出ルータがしばらく走っている後に。
Loop-Detection Process
輪検出の過程
The following sections describe the phases of the minimal loop- detection process that an exterior router must employ when either network-number remapping or hop-count reduction is active. An exterior router can implement an enhanced loop-detection scheme.
ネットワーク・ナンバー再写像かホップカウント減少のどちらかが活発であるときに、以下のセクションは外のルータが使わなければならない最小量の輪の検出の過程のフェーズについて説明します。 外のルータは高められた輪検出計画を実行できます。
LOOP-INDICATIVE ROUTING INFORMATION: A remapping exterior router should always examine routing information received through a tunnel for indications that a routing loop may exist. Loop-indicative routing information appears to refer to networks across the tunnel. However, it may actually refer to networks in the exterior router's own local internet if the networks' routing information has looped back through the tunnel.
輪の暗示した経路情報: 再写像の外のルータはいつもルーティング輪が存在するかもしれないという指摘のためにトンネルを通って受け取られたルーティング情報を調べるべきです。 輪の暗示したルーティング情報はトンネルの向こう側にネットワークを示すように見えます。 しかしながら、ネットワークのルーティング情報がトンネルを通って輪にされたなら、それは実際に外のルータの自己の地方のインターネットでネットワークを示すかもしれません。
In the following definition of loop-indicative information,
輪の暗示した情報の以下の定義で
Oppenheimer [Page 68] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[68ページ]RFC1504Appletalk
the network range for the network connected to a given port of an
exterior router is referred to as ns through ne
外のルータの与えられたポートに接続されたネットワークのためのネットワーク範囲はNeを通してナノ秒と呼ばれます。
the zone list for that network is referred to as z1 through zn
そのネットワークのためのゾーンリストはZnを通してz1と呼ばれます。
The routing information that a remapping exterior router receives through a tunneling port is loop indicative if both of the following conditions are true for some port on the router:
ルータのいくらかのポートに、以下の条件の両方が本当であるなら、再写像の外のルータがトンネリングポートを通して受信されるというルーティング情報は輪の暗示です:
The size of the network range in the routing information is ne-
ns+1.
ルーティング情報のネットワーク範囲のサイズはNeナノ秒+1です。
The zone list in the routing information consists precisely of z1
through zn.
ルーティング情報のゾーンリストはZnを通してまさにz1から成ります。
Thus, the routing information could represent a remapping of the network range for a network connected directly to one of the exterior router's ports.
したがって、ルーティング情報は直接外のルータのポートの1つに接続されたネットワークのためにネットワーク範囲の再写像を表すかもしれません。
An exterior router most commonly receives loop-indicative information at startup when the process of bringing up the tunnel may create a self-caused loop. An exterior router may also receive loop-indicative information if another router connects two AppleTalk domains that are already connected through the tunnel and creates an externally caused loop.
トンネルを持って来る過程が自己によって引き起こされた輪を作成するとき、外のルータは始動に最も一般的に輪の暗示した情報を受け取ります。 また、別のルータがトンネルを通って既につなげられる2つのAppleTalkドメインをつなげて、外部的に引き起こされた輪を作成するなら、外のルータは輪の暗示した情報を受け取るかもしれません。
If a remapping exterior router receives loop-indicative routing information through a tunnel, it should start a loop-investigation process. For information about the loop-investigation process, see the next section, "Loop-Investigation Process."
再写像の外のルータがトンネルを通って輪の暗示したルーティング情報を受け取るなら、それは輪調査の過程を始めるべきです。 輪調査の過程の情報に関しては、次のセクション、「輪調査の過程」を見てください。
LOOP-INVESTIGATION PROCESS: To confirm or deny the existence of a suspected loop, an exterior router performs a loop-investigation process, in which it sends an AppleTalk data packet out the tunneling port, then observes whether that packet loops back through a port connected to its local internet. The exterior router sends the packet to the address corresponding to its own address on the network that it suspects may actually be a shadow copy of a network connected directly to one of its ports.
輪調査の過程: 疑われた輪の存在を確認するか、または否定するために、外のルータは輪調査の過程を実行します。(それは、それでトンネリングポートからAppleTalkデータ・パケットを送って、次に、そのパケットが地方のインターネットにつなげられたポートを通して輪にされるかどうか観察します)。 外のルータはそれが実際に直接ポートの1つに接続されたネットワークの影のコピーであるかもしれないと疑うネットワークでそれ自身のアドレスに対応するアドレスにパケットを送ります。
LOOP PROBE PACKET: A Loop Probe packet is an AppleTalk data packet that an exterior router sends out a tunneling port to confirm or deny the existence of a loop. It is a new type of RTMP packet and has the function code 4. Figure 4-7 shows the format of a Loop Probe packet.
徹底的調査パケットを輪にしてください: Loop Probeパケットは外のルータが輪の存在を確認するか、または否定するためにトンネリングポートを出すAppleTalkデータ・パケットです。 それは、新しいタイプのRTMPパケットであり、機能コード4を持っています。 図4-7はLoop Probeパケットの書式を示しています。
<<Figure 4-7 Loop Probe packet format>>
<<数値4-7Loop Probeパケット・フォーマット>>。
The source node ID and source network number in a Loop Probe packet
Loop ProbeパケットのソースノードIDとソースネットワーク・ナンバー
Oppenheimer [Page 69] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[69ページ]RFC1504Appletalk
should be those of the port for which the exterior router received loop-indicative information. An exterior router can send a Loop Probe packet through any socket.
外のルータが輪の暗示した情報を受け取ったポートのものであるべきです。 外のルータはどんなソケットを通してもLoop Probeパケットを送ることができます。
A Loop Probe packet's destination network number is the network number to which that port's network number would be remapped if the loop-indicative information were actually a shadow copy of that port's routing information. Refer to the port's actual network number as nu(ns<=nu<=ne). If the network range in the loop-indicative information were rs through re, the packet's destination network number would be rs+nu-ns.
Loop Probeパケットの目的地ネットワーク・ナンバーはそのポートのネットワーク・ナンバーが輪の暗示した情報が実際にそのポートのルーティング情報の影のコピーであるなら再写像されるネットワーク・ナンバーです。 ν(νナノ秒<=<はNeと等しい)をポートの実際のネットワーク・ナンバーを参照してください。 輪の暗示した情報のネットワーク範囲がreを通したrsであるなら、パケットの目的地ネットワーク・ナンバーはrs+尼僧でしょうに。
A Loop Probe packet's destination node ID is that of the exterior router on the port for which the exterior router received loop- indicative information. The packet's destination socket is socket 1- the RTMP socket.
Loop Probeパケットの目的地ノードIDは外のルータが輪の暗示した情報を受け取ったポートの上の外のルータのものです。 パケットの目的地ソケットはソケット1です。RTMPソケット。
A Loop Probe packet's data field always begins with a long word that has the value 0. The remainder of the data field should contain information that the exterior router that sends the packet can use to identify that packet if it receives the packet through its local internet. An exterior router might receive a Loop Probe packet sent by another exterior router if a loop did not actually exist and the other exterior router sent a Loop Probe packet to a random node on the internet rather than to itself. The node receiving the Loop Probe packet might be an exterior router that also sent a Loop Probe packet. To prevent an exterior router that receives such a Loop Probe packet from falsely concluding that a loop exists, the exterior router sending the packet must insert sufficient data in that packet's data field to allow it to recognize the packet as the one it sent.
Loop Probeパケットのデータ・フィールドはいつも値0を持っているロング・ワードで始まります。 データ・フィールドの残りは地方のインターネットを通してパケットを受けるならパケットを送る外のルータが、そのパケットを特定するのを使用できるという情報を含むべきです。 輪が実際に存在しないで、もう片方の外のルータがそれ自体にというよりむしろインターネットでLoop Probeパケットを無作為のノードに送るなら、外のルータは別の外のルータによって送られたLoop Probeパケットを受けるでしょうに。 Loop Probeパケットを受けるノードはまた、Loop Probeパケットを送った外のルータであるかもしれません。 外のルータを防ぐために、輪が存在すると間違って結論を下すのからそれがそのようなLoop Probeパケットを受けるので、パケットを送る外のルータはそのパケットのデータ・フィールドのパケットが送ったものであると認めるのを許容できるくらいのデータを挿入しなければなりません。
An exterior router initiating a loop-investigation process should forward a Loop Probe packet through the tunnel to the next internet router for the packet's destination network-just as it would any other AppleTalk data packet. This next internet router should always be the exterior router that sent the loop-indicative information.
いかなる他のAppleTalkデータ・パケットも送るように輪調査の過程に着手する外のルータはまさしくパケットの目的地ネットワークのためにトンネルを通して次のインターネットルータにLoop Probeパケットを送るべきです。 いつもこの次のインターネットルータは輪の暗示した情報を送った外のルータであるべきです。
A remapping exterior router forwarding a Loop Probe packet into its local internet must process that packet differently from other AppleTalk data packets in one way. If the exterior router's remapping database does not include the source network number in the packet's DDP header, the exterior router should forward the packet without remapping the source network number. At startup, remapping information is generally unavailable. However, the absence of remapping information should not affect the loop-detection process.
Loop Probeパケットを地方のインターネットに送る再写像の外のルータはそのパケットを他のAppleTalkデータ・パケットと異なってある意味では処理しなければなりません。 外のルータの再写像データベースがパケットのDDPヘッダーにソースネットワーク・ナンバーを含んでいないなら、ソースネットワーク・ナンバーを再写像しないで、外のルータはパケットを進めるべきです。 一般に、始動では、情報を再写像するのは入手できません。 しかしながら、再写像情報の欠如は輪検出の過程に影響するべきではありません。
If a loop exists, the exterior router that originally sent the Loop
aであるなら、輪は存在していて、外部は元々Loopを送ったルータです。
Oppenheimer [Page 70] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[70ページ]RFC1504Appletalk
Probe packet receives that packet through its local internet. The data in the packet remains unchanged. The exterior router can use that data to confirm the existence of a loop on the internet.
徹底的調査パケットは地方のインターネットを通してそのパケットを受けます。 パケットのデータは変わりがありません。 外のルータは、インターネットで輪の存在を確認するのにそのデータを使用できます。
If a Loop Probe packet returns to the exterior router through the tunnel out which it was sent, a loop exists between two other exterior routers on the tunnel, but does not involve the exterior router that sent the packet. The sending router need take no action.
Loop Probeパケットがそれが送られたトンネルを通って外のルータに戻るなら、輪は、トンネルの上の他の2つの外のルータの間に存在していますが、パケットを送った外のルータにかかわりません。 送付ルータは行動を全く取る必要はありません。
An exterior router should send a Loop Probe packet at least four times. The retransmission timeout should be no less than two seconds. Once the exterior router has retransmitted a Loop Probe packet four times and that packet has not returned to the exterior router through its local internet, the exterior router determines that no loop exists.
外のルータは少なくとも4回Loop Probeパケットを送るべきです。 再送タイムアウトは2秒未満ノーであるべきです。 いったん外のルータが4回Loop Probeパケットを再送して、そのパケットが地方のインターネットを通して外のルータに戻っていないと、外のルータは、輪が全く存在しないことを決定します。
If the exterior router receives a Loop Probe packet containing the correct data field through its local internet, this confirms the existence of a loop. The exterior router should deactivate the tunneling port, log an error, and set the state of all routing-table entries for exterior routers connected to that tunnel to BAD.
外のルータが地方のインターネットを通して正しいデータ・フィールドを含むLoop Probeパケットを受けるなら、これは輪の存在を確認します。 外のルータは、トンネリングポートを非活性化して、誤りを登録して、そのトンネルに接続された外のルータのためのすべての経路指定テーブルエントリーの状態をBADに設定するべきです。
NOTE: The exterior router need not deactivate a tunneling port on which it detects a loop. However, the exterior router must disconnect with the exterior router that sent the loop-indicative information. However, disconnecting from only that exterior router might inadvertently result in a partially connected tunnel or in a lack of connectivity through the tunnel that would be difficult to detect.
以下に注意してください。 外のルータはそれが輪を検出するトンネリングポートを非活性化する必要はありません。 しかしながら、外のルータは輪の暗示した情報を送った外のルータで連絡を断たなければなりません。 しかしながら、その外のルータだけから連絡を断つのはうっかり部分的に接続されたトンネルかトンネルを通る接続性の検出するのが難しい不足に結果として生じるかもしれません。
LIMITATIONS OF LOOP DETECTION: This loop-detection process becomes ineffective if, at some point in the loop, another exterior router
輪の検出の制限: この輪検出の過程は輪の何らかのポイントの別の外のルータであるなら効力がなくなります。
hides networks connected directly to the ports of the exterior
router that sent the Loop Probe packet
直接Loop Probeパケットを送った外のルータのポートに接続されたネットワークを隠します。
clusters the network ranges of networks connected directly to the
exterior router's ports
直接外のルータのポートに接続されたネットワークのネットワーク範囲を群生させます。
is not remapping network numbers-resulting in partial network-
number remapping
部分的なネットワーク数の再写像に数で結果として生じるネットワークを再写像していません。
In such cases, the exterior router that initiated the loop-detection process may never receive loop-indicative information, even though a loop exists.
そのような場合、輪検出の過程に着手した外のルータは輪の暗示した情報を決して受け取らないかもしれません、輪が存在していますが。
Using Alternative Paths
迂回経路を使用します。
AURP provides two mechanisms that allow a network administrator to
AURPはそれがネットワーク管理者を許容する2つのメカニズムを提供します。
Oppenheimer [Page 71] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[71ページ]RFC1504Appletalk
configure a port on an exterior router to forward packets over an alternative path to a network only when the primary path to that network is unavailable:
外のルータのポートを構成して、そのネットワークへのプライマリ経路が入手できないときにだけ、ネットワークへの迂回経路の上にパケットを送ってください:
hop-count weighting
ホップカウントの重さ
backup paths
バックアップ道
By configuring hop-count weighting on a port or configuring a port as a backup path, an administrator can reduce the amount of traffic on a slow point-to-point link or tunnel. These mechanisms are also available on links using RTMP.
ポートの上のホップカウントの重さを構成するか、またはバックアップ道としてポートを構成することによって、管理者は遅いポイントツーポイント接続かトンネルでトラフィックの量を減少させることができます。 また、これらのメカニズムも、リンクでRTMPを使用することで利用可能です。
Hop-Count Weighting
ホップカウントの重さ
A network administrator can configure hop-count weighting on a port to increase the routing distance through a port by counting a link to another exterior router as more than one hop. Increasing the routing distance through a port may cause traffic to traverse an alternative path. The routers on an internet forward packets over an alternative path to a network if
ネットワーク管理者は、ポートを通して十二分にワンバウンドとして別の外のルータへのリンクを数えることによってルーティング距離を増強するためにポートの上のホップカウントの重さを構成できます。 ポートを通してルーティング距離を増強するのに、トラフィックは迂回経路を横断するかもしれません。 インターネットのルータはネットワークへの迂回経路の上にパケットを送ります。
an alternative path is available
迂回経路は利用可能です。
the perceived distance to that network is shorter over the
alternative path
迂回経路の上では、そのネットワークへの知覚された距離は、より短いです。
However, a network administrator should not set the hop-count weight for a link so high that distances between networks across that link exceed the limit of 15 hops. Otherwise, if the link on which hop- count weighting was active were the only available path, the exterior router would be unable to provide full connectivity to all networks on the internet.
しかしながら、ネットワーク管理者はそのリンクの向こう側のネットワークの間の距離が15のホップの限界を超えているほど高いリンクにホップカウントの重さを設定するべきではありません。 さもなければ、ホップカウントの重さがアクティブであったリンクが唯一の利用可能な経路であるなら、外のルータはインターネットで完全な接続性をすべてのネットワークに提供できないでしょうに。
To implement hop-count weighting, an exterior router should make the following changes to RTMP and the DDP routing process:
ホップカウントの重さを実装するために、外のルータはRTMPへの以下の変更とDDPルーティングプロセスを行うべきです:
When an exterior router uses RTMP or AURP to broadcast the
networks that are accessible through a link on which hop-count
weighting is active, the distance attributed to each network should
equal its actual distance plus the hop-count weight specified.
外のルータがリンクを通ってホップカウントの重さがアクティブであるアクセスしやすいネットワークを放送するのにRTMPかAURPを使用すると、各ネットワークの結果と考えられた距離は実際の距離と等しくあるべきでした、そして、ホップカウントの重さは指定しました。
Before an exterior router forwards a DDP data packet to a network
across that link, it should add the specified hop-count weight to the
value in the hop-count field of the packet's DDP header.
外のルータがそのリンクの向こう側にDDPデータ・パケットをネットワークに送る前に、それはパケットのDDPヘッダーのホップカウント分野の値に指定されたホップカウントの重さを加えるべきです。
Oppenheimer [Page 72] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[72ページ]RFC1504Appletalk
Backup Paths
バックアップ道
A network administrator can configure a port on an exterior router as a backup path. The routers on an internet forward AppleTalk data packets across a backup path only when an exterior router on which a port is configured as a backup path determines that no other path to a specific network or networks is available.
ネットワーク管理者はバックアップ道として外のルータのポートを構成できます。 ポートがバックアップ道として構成される外のルータが、特定のネットワークかネットワークへの他のどんな経路も利用可能でないことを決定する場合にだけ、インターネットのルータはバックアップ道の向こう側にAppleTalkデータ・パケットを送ります。
Regardless of the distance that routing packets must traverse across a primary path to a network, routers on the internet use the primary path as long as it remains available. When the exterior router on which a port is configured as a backup path determines that the primary path to a network is no longer available and that network is accessible across the backup path, the exterior router broadcasts routing information about networks accessible across the backup path to its local internet.
ルーティングパケットがプライマリ経路の向こう側にネットワークに横断しなければならない距離にかかわらず、利用可能なままで残っている限り、インターネットに関するルータはプライマリ経路を使用します。 ポートがバックアップ道として構成される外のルータが、ネットワークへのプライマリ経路がもう利用可能でないことを決定して、そのネットワークがバックアップ道の向こう側にアクセスしやすいときに、外のルータはバックアップ道の向こう側に地方のインターネットにアクセスしやすいネットワークのルーティング情報を放送します。
NOTE: An exterior router at each end of the backup path maintains a complete routing table for the entire internet, and sends AURP or RTMP routing packets across the backup path, regardless of whether the backup path is in use.
以下に注意してください。 バックアップ道の各端の外のルータは、全体のインターネットのために完全な経路指定テーブルを維持して、バックアップ道の向こう側にルーティングパケットをAURPかRTMPに送ります、バックアップ道が使用中であるかどうかにかかわらず。
If an exterior router is currently providing access to a network through a backup path and the primary path to that network again becomes available, the exterior router starts broadcasting routing information that indicates the primary path to the network, rather than the backup path. The routers on the exterior router's local internet can again use the primary path to that network.
外のルータが現在、バックアップ道を通してネットワークへのアクセスを提供していて、そのネットワークへのプライマリ経路が再び利用可能になるなら、外のルータはバックアップ道よりむしろネットワークにプライマリ経路を示すルーティング情報を放送し始めます。 外のルータの地方のインターネットのルータは再びそのネットワークにプライマリ経路を使用できます。
PROBLEMS REACTIVATING THE PRIMARY PATH: When an exterior router is providing access to a network through a backup path and the primary path to that network again becomes available, it is possible that the exterior router may not become aware that the primary path is available. This can occur when other routers in the exterior router's local internet use the backup path, rather than a newly available primary path, because the backup path traverses a shorter distance. The other routers have no way of knowing that an active path is a backup path. They do not notify the exterior router connected to the shorter backup path about the primary path's availability.
プライマリ経路を現役に戻すことにおける問題: 外のルータがバックアップ道を通してネットワークへのアクセスを提供していて、そのネットワークへのプライマリ経路が再び利用可能になるとき、外のルータがプライマリ経路が利用可能であることを意識するようにならないのは、可能です。 外のルータの地方のインターネットにおける他のルータが新たに利用可能なプライマリ経路よりむしろバックアップ道を使用すると、これは起こることができます、バックアップ道が、より短い距離を横断するので。 他のルータには、アクティブな経路がバックアップ道であることを知る方法が全くありません。 彼らはプライマリ経路の有用性に関して、より短いバックアップ道に関連づけられた外のルータに通知しません。
Once the primary path becomes unavailable and routers on the internet use the backup path, reconfiguring the exterior router so it will again use the primary path may be necessary.
一度、プライマリ経路は入手できなくなります、そして、インターネットに関するルータはバックアップ道を使用します、外のルータが再びプライマリ経路を使用するのに必要であるかもしれないことを再構成して。
Network Management
ネットワークマネージメント
A Simple Network Management Protocol (SNMP) Management Information
簡単なネットワーク管理プロトコル(SNMP)経営情報
Oppenheimer [Page 73] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[73ページ]RFC1504Appletalk
Base (MIB) allows the remote management of tunneling, routing- information propagation, and the representation of wide area routing information. Refer to the "IETF Draft: Macintosh System MIB" on E.T.O. for detailed information about the structure and content of AURP's many remotely manageable parameters.
基地(MIB)はトンネリングのリモート管理、ルーティング情報伝播、および広い領域ルーティング情報の表現を許容します。 「IETFは以下を作成すること」を参照してください。 AURPの多くのほんの少し処理しやすいパラメタの構造と内容の詳細な情報のためのE.T.O.の「マッキントッシュSystem MIB。」
Network-Number Remapping and Network Management
ネットワーク・ナンバーRemappingとネットワークマネージメント
The packets of network-management protocols-regardless of whether SNMP forms their basis-often contain information about specific AppleTalk network numbers. An exterior router cannot remap network numbers in data. Therefore, when querying devices across a tunnel, network-management protocols always return network numbers that have not been remapped. However, a remote network-management station using SNMP could use the AURP MIB to query a remapping exterior router to obtain remapped network numbers from the exterior router's remapping database.
にかかわらず、パケット、ネットワーク管理プロトコル、-、SNMPがしばしばそれらの基礎を形成するか否かに関係なく、特定のAppleTalkネットワーク番号の情報を含んでください。 外のルータはデータのremapネットワーク・ナンバーをそうすることができません。 したがって、トンネルの向こう側にデバイスについて質問するとき、ネットワーク管理プロトコルはいつも再写像されていないネットワーク・ナンバーを返します。 しかしながら、SNMPを使用する遠く離れたネットワークマネージメントステーションは、外のルータの再写像データベースから再写像しているネットワーク・ナンバーを得るために再写像の外のルータについて質問するのにAURP MIBを使用できました。
Network Hiding and Network Management
ネットワーク隠れることとネットワークマネージメント
Even though an exterior router is hiding a network from a particular port, that network's routing information should be available to a network-management station across that port. Network hiding should not affect network management. Thus, an exterior router should still return routing information for hidden networks in responses to network-management queries. A network-management station using SNMP could use the AURP MIB to query an exterior router to obtain information about hidden networks.
外のルータは指定港からネットワークを隠していますが、そのネットワークのルーティング情報はそのポートの向こう側にネットワークマネージメントステーションに利用可能であるべきです。 ネットワーク隠れることはネットワークマネージメントに影響するべきではありません。 したがって、外のルータはネットワークマネージメント質問への応答でまだ隠されたネットワークのためのルーティング情報を返しているべきです。 SNMPを使用するネットワークマネージメントステーションは、隠されたネットワークの情報を得るために外のルータについて質問するのにAURP MIBを使用できました。
Unaffected Network-Management Packets
影響を受けないネットワークマネージメントパケット
Network-management packets that network-number remapping and network hiding should not affect include:
ネットワーク・ナンバー再写像とネットワーク隠れることが影響するべきでないネットワークマネージメントパケットは:
SNMP requests received through an AURP port
AURPポートを通して受け取られたSNMP要求
SNMP responses sent through an AURP port
AURPポートを通して送られたSNMP応答
RTMP responses sent through an AURP port
AURPポートを通して送られたRTMP応答
Route Data responses sent through an AURP port
AURPポートを通して送られたルートData応答
ZIP queries received through an AURP port
AURPポートを通して受けられたZIP質問
ZIP requests received through an AURP port
AURPポートを通して受け取られたZIP要求
ZIP replies sent through an AURP port
AURPポートを通して送られたZIP回答
Oppenheimer [Page 74] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[74ページ]RFC1504Appletalk
APPENDIX: IMPLEMENTATION DETAILS
付録: 実装の詳細
This appendix provides information that may assist you in implementing AURP. It does not specify protocol requirements.
この付録はAURPを実装するのにあなたを助けるかもしれない情報を提供します。 それはプロトコル要件を指定しません。
Developers implementing AURP routers may want to purchase the Apple Internet Router, a product of Apple Computer. The Apple Internet Router provides many additional examples of how you might implement the various features of AURP.
AURPにルータを実装する開発者はアップルインターネットRouter、アップル・コンピューターの製品を購入したがっているかもしれません。 アップルインターネットRouterはあなたがどうAURPの様々な特徴を実装するかもしれないかに関する多くの追加例を提供します。
State Diagrams
州のダイヤグラム
Figure A-1 shows the state diagram for the AURP data receiver.
図A-1はAURPデータ受信装置のために州のダイヤグラムを見せています。
<<Figure A-1 AURP data receiver state diagram>>
<<図A-1 AURPデータ受信機州は>>を図解します。
Figure A-2 shows the state diagram for the AURP data sender.
図A-2はAURPデータ送付者のために州のダイヤグラムを見せています。
<<Figure A-2 AURP data sender state diagram>>
<<図A-2 AURPデータ送付者州は>>を図解します。
AURP Table Overflow
AURPテーブルオーバーフロー
It is possible for an AURP data receiver to have insufficient storage capacity to maintain all of the routing information sent to it by a peer data sender. Because the data sender does not retransmit routing information, the data receiver should set a flag indicating that a table-overflow condition exists. If additional storage later becomes available, the data receiver should try to obtain the missing information. If zone information is lost, the data receiver can obtain complete zone information by sending the appropriate ZI-Req packets. If network information is lost, the data receiver should send an RI-Req to obtain the complete routing table.
AURPデータ受信装置には同輩データ送付者によってそれに送られたルーティング情報のすべてを維持する不十分な記憶容量があるのは、可能です。 データ送付者がルーティング情報を再送しないので、データ受信装置は、旗が、テーブルオーバーフロー条件が存在するのを示すように設定するはずです。 後で追加ストレージが利用可能になるなら、データ受信装置はなくなった情報を得ようとするはずです。 ゾーン情報が無くなるなら、データ受信装置は、適切なZI-Reqパケットを送ることによって、完全なゾーン情報を得ることができます。 ネットワーク情報が無くなるなら、データ受信装置は、完全な経路指定テーブルを入手するためにロードアイランド-Reqを送るはずです。
A Scheme for Updates Following Initial Information Exchange
初期の情報交換に続くアップデートの体系
As described in the section "Sending Updates Following the Initial Exchange of Routing Information" in Chapter 3, an exterior router must present complete and accurate routing information to all exterior routers, even if a new connection is established with that exterior router when the exterior router has update events pending- that is, update events not yet sent in RI-Upd packets. This section details one scheme for presenting routing information to both new and old connections correctly, even if multiple update events occur for a given network in an update period during which the exterior router establishes new connections. More complex schemes could provide more up-to-date information, at the cost of greater implementational complexity.
第3章の「経路情報の初期の交換に続く送付アップデート」というセクションで説明されるように、外のルータに未定のアップデートイベントがあると新しい接続がその外のルータで確立されても、外のルータは完全で正確なルーティング情報をすべての外のルータに提示しなければなりません、すなわち、アップデートイベントはまだロードアイランド-Updパケットを送りませんでした。 このセクションは正しく新しいものと同様に年取った接続にルーティング情報を提示することの1つの体系を詳しく述べます、複数のアップデートイベントが外のルータが新しい接続を確立するアップデート時代に与えられたネットワークのために起こっても。 より複雑な体系は、より大きいimplementationalの複雑さの費用で、より最新の情報を提供するかもしれません。
Oppenheimer [Page 75] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[75ページ]RFC1504Appletalk
Assume that an exterior router has a number of AURP connections established with other routers and that a series of update events for a given network occur in the exterior router's local internet. Once these events have occurred, but before the update interval expires- that is, before the exterior router sends RI-Upd packets over its connections-the exterior router establishes a new AURP connection with another exterior router and receives an RI-Req packet from that exterior router. This section describes the information about the network that the RI-Rsp packet should contain. It also describes the update event that the exterior router should send in the next RI-Upd packet, assuming that it receives no additional update events for the network.
外のルータで他のルータで多くのAURP接続を確立して、与えられたネットワークのための一連のアップデートイベントが外のルータの地方のインターネットで起こると仮定してください。 一度、これらのイベントが起こったことがありますが、以前、アップデート間隔が期限が切れて、すなわち、以前外のルータがロードアイランド-Updパケットを移動する、それ、接続、-、外のルータは、別の外のルータで新しいAURP接続を確立して、その外のルータからロードアイランド-Reqパケットを受けます。 このセクションはロードアイランド-Rspパケットが含むはずであるネットワークの情報について説明します。 また、それは外のルータが次のロードアイランド-Updパケットで送るべきであるアップデートイベントについて説明します、ネットワークのためにどんな追加アップデートイベントも受けないと仮定して。
Two scenarios are possible. In the first scenario, a network for which the exterior router is not exporting information at the beginning of an update interval either comes up in the exterior router's local internet, or a new path to the network that is shorter than the path through the tunnel comes up in the exterior router's local internet. In either case, the RI-Rsp packet should not include the new network.
2つのシナリオが可能です。 最初のシナリオでは、外のルータがアップデート間隔の始めに情報をエクスポートしないネットワークは外のルータの地方のインターネット、または新しい経路でトンネルを通る経路が外のルータの地方のインターネットで来るより短いネットワークに上って来ます。 どちらの場合ではも、ロードアイランド-Rspパケットは新しいネットワークを含んでいるはずがありません。
By not including the new network in the RI-Rsp, the implementation can simply continue to follow the state diagram provided in the section "Sending Routing Information Update Packets" in Chapter 3. If only an NDC event or no additional update event occurs for the network, the next RI-Upd packet that the exterior router sends on both old and new connections should contain an NA event for the network. If an NRC or ND event occurs for the network, the exterior router should not include an event tuple for the network in the RI- Upd. This sequence matches the state diagram precisely. If the RI-Rsp did contain information about the network, new connections would require a different state diagram.
ロードアイランド-Rspの新しいネットワークを含んでいないことによって、実装は単にずっと第3章で「経路情報アップデートパケットを送る」というセクションに提供された州のダイヤグラムに従うことができます。 NDCイベントだけを生じますが、何か追加アップデートイベントはネットワークのために起こらないなら、外のルータが古いものと同様に新しい接続のときに送る次のロードアイランド-UpdパケットはネットワークのためのNAイベントを含むはずです。 NRCかノースダコタイベントがネットワークのために現れるなら、外のルータはロードアイランドUpdのネットワークのためのイベントtupleを含むべきではありません。 この系列は正確に州のダイヤグラムに合っています。 ロードアイランド-Rspがネットワークの情報を含んでいるなら、新しい接続は異なった州のダイヤグラムを必要とするでしょうに。
In the second scenario, the exterior router initially exports information for a network, then an update event occurs for that network. In all cases, the RI-Rsp packet should contain up-to-date information about the network from the exterior router's central routing table, and the next RI-Upd packet should contain the specific event that the state table indicates for that network. For example, if an ND or NRC event occurs for the network, the network should not be included in the RI-Rsp, while if an NDC event occurs, it should be included in the RI-Rsp.
2番目のシナリオでは、外のルータは初めは、ネットワークのための情報をエクスポートして、次に、アップデートイベントはそのネットワークのために起こります。 すべての場合では、ロードアイランド-Rspパケットは外のルータの中央の経路指定テーブルからのネットワークに関して最新の情報を含むはずです、そして、次のロードアイランド-Updパケットはステートテーブルがそのネットワークのために示す特定のイベントを含むはずです。 例えば、ノースダコタかNRCイベントがネットワークのために現れるなら、ロードアイランド-Rspにネットワークを含むべきではありません、NDCイベントが起こるなら、それはロードアイランド-Rspに含まれるべきですが。
This scheme may result in some exterior routers receiving unexpected update events, which they must process as specified in the section "Processing Inconsistent Update Events" in Chapter 3. For example, another exterior router with which the exterior router establishes a new connection might receive an ND or NRC event for a network of
この体系は第3章の「処理の矛盾したアップデートイベント」というセクションで指定されているとしてそれらが処理しなければならない予期していなかったアップデートイベントを受けるいくつかの外のルータをもたらすかもしれません。 例えば、外のルータが力がネットワークのためのノースダコタかNRCイベントを受ける新しい接続を確立する別の外のルータ
Oppenheimer [Page 76] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[76ページ]RFC1504Appletalk
which it was unaware. The receiving exterior router would ignore the event.
どれ、それは気づきませんたか。 受信の外のルータはイベントを無視するでしょう。
In an alternative way of evaluating and possibly implementing this scheme, the information for a given network that is sent in the initial RI-Rsp packet depends on the particular update event that is pending for that network when the exterior router sends the RI-Rsp. Specifically, an exterior router should include a network for which it has an update event pending in the RI-Rsp packet only if the pending update event is an NDC. Otherwise, the exterior router should not include the network in the RI-Rsp. Following this RI-Rsp, the exterior router sends RI-Upd packets as usual, which include other pending events, as necessary.
この体系を評価して、ことによると実装する代替の方法で、初期のロードアイランド-Rspパケットで送られる与えられたネットワークのための情報は外のルータがロードアイランド-Rspを送るときそのネットワークに、未定の特定のアップデートイベントによります。 明確に、外のルータはそれが未定のアップデートイベントがNDCである場合にだけロードアイランド-Rspパケットで未定のアップデートイベントを持っているネットワークを含むべきです。 さもなければ、外のルータはロードアイランド-Rspのネットワークを含むべきではありません。 このロードアイランド-Rspに続いて、外のルータは必要に応じて通常通りのロードアイランド-Updパケットを送ります。(パケットは他の未定のイベントを含んでいます)。
Implementation Effort for Different Components of AURP
AURPの異なった部品のための実装取り組み
AURP contains various enhancements to AppleTalk routing. The only components of AURP that are required are those specified in Chapter 3. The required components of AURP provide the functionality needed to replace RTMP and ZIP, completely and compatibly, on tunnels and point-to-point links, without losing any functionality and with greatly reduced routing traffic. Optional features of AURP provide functionality beyond that of RTMP and ZIP. This functionality is especially useful in a wide area network environment.
AURPはAppleTalkルーティングに様々な増進を含んでいます。 必要であるAURPの唯一の部品が第3章で指定されたものです。 AURPの必要な部品はRTMPとZIPを完全と矛盾なさとトンネルとポイントツーポイント接続の上と、そして、どんな機能性も失うことなしで大いに減少しているルーティングトラフィックに取り替えるのに必要である機能性を提供します。 AURPに関するオプション機能はRTMPとZIPのものを超えて機能性を提供します。 この機能性は広域ネットワーク環境で特に役に立ちます。
The chart shown in Figure A-3 provides rough estimates of the percentage of development time needed to implement, debug, and test the various components of a complete AURP implementation. It can provide developers with some idea of the implementational complexity of these components and help developers make tradeoffs between features and development time.
図A-3に示されたチャートは完全なAURP実装の様々なコンポーネントを実装して、デバッグして、テストするのに必要である開発時間の割合の概算を提供します。 それは、これらのコンポーネントのimplementationalの複雑さの何らかの考えを開発者に提供して、開発者が特徴と開発時間の間で見返りを作るのを助けることができます。
<<Figure A-3 Implementation effort for AURP>>
AURP>>のための<<図A-3 Implementation取り組み
Creating Free-Trade Zones
自由貿易圏を作成します。
A useful feature of AURP is that it allows a network administrator to create free-trade zones. A free-trade zone is a part of an internet that is accessible by two other parts of the internet, neither of which can access the other. An administrator might create a free- trade zone to provide some form of interchange between two organizations that otherwise want to keep their internets isolated from each other, or between two organizations that otherwise do not have physical connectivity with one another.
AURPの役に立つ特徴はネットワーク管理者がそれで自由貿易圏を作成できるということです。 自由貿易圏はそれのどちらももう片方にアクセスできないインターネットの他の2つの部品でアクセスしやすいインターネットの一部です。 管理者は、そうでなければお互いと共に互いか、そうでなければ物理的な接続性を持っていない2つの組織の間にそれらのインターネットを隔離し続けたがっている2つの組織の間に何らかの形式の置き換えを提供するために無料の通商地帯を作成するかもしれません。
AURP allows the creation of free-trade zones in two ways. In one method, described in the section "Fully Connected and Partially Connected Tunnels" in Chapter 2, an administrator intentionally
AURPは2つの方法で自由貿易圏の作成を許容します。 故意に第2章、管理者で「Tunnelsに完全に接して、部分的、接する」というセクションで説明された1つのメソッドで
Oppenheimer [Page 77] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[77ページ]RFC1504Appletalk
creates a partially connected tunnel. The administrator configures the exterior router to connect with two exterior routers between which a free-trade zone is to be established, but does not configure those exterior routers to connect with one another.
部分的に接続されたトンネルを作成します。 管理者は、自由貿易圏が確立されることになっている2つの外のルータに接続するために外のルータを構成しますが、お互いに接するためにそれらの外のルータは構成しません。
The second method of using AURP to create a free-trade zone involves the use of network hiding. An administrator can configure a single router to create a free-trade zone. No AURP tunnel need exist. As shown in Figure A-4, three ports are configured on a router. One port connects to the free-trade zone, while the other two ports connect to the parts of the internets that are otherwise isolated from one another.
自由貿易圏を作成するAURPを使用する2番目のメソッドはネットワーク隠れることの使用を伴います。 管理者は、自由貿易圏を作成するためにただ一つのルータを構成できます。 AURPトンネルは全く存在する必要はありません。 図A-4に示されるように、3つのポートがルータで構成されます。 1つのポートが自由貿易圏に接続します、他の2つのポートが別の方法でお互いから隔離されるインターネットの部品に接続しますが。
<<Figure A-4 Creating free-trade zones>>
<<図A-4 Creating自由貿易圏>>。
On the port connected to the free-trade zone, the administrator does not configure the router to hide any networks. The exterior router exports all networks from both organizations to the free-trade zone. On each port connected to an organization's internet, the administrator configures the router to export only the networks from the free-trade zone. The exterior router hides all the networks from the other organization's internet. In this way, each organization has access to the networks in the free-trade zone, and vice versa, but not to the networks in the other organization's internet.
自由貿易圏につなげられたポートの上では、管理者は、どんなネットワークも隠すためにルータを構成しません。 外のルータは両方の組織から自由貿易圏まですべてのネットワークをエクスポートします。 組織のインターネットにつなげられた各ポートの上では、管理者は、自由貿易圏からネットワークだけをエクスポートするためにルータを構成します。 外のルータはもう片方の組織のインターネットからすべてのネットワークを隠します。 このように、各組織は自由貿易圏でネットワークに近づく手段を持っています、逆もまた同様にもう片方の組織のインターネットにおけるネットワークではなく、。
Implementation Details for Clustering
クラスタリングのための実装の詳細
The data structures that an exterior router uses to maintain information about clustering are key to the implementation of clustering. An exterior router should
外のルータがクラスタリングの情報を保守するのに使用するデータ構造はクラスタリングの実装に主要です。 外のルータはそうするべきです。
maintain mappings between the actual domain identifier and network
range; the remapped network range; and the associated cluster
実際のドメイン識別子とネットワーク範囲の間のマッピングを維持してください。 再写像しているネットワーク範囲。 そして、関連クラスタ
maintain zone lists for each actual network and for the cluster as
a whole
それぞれの実際のネットワークと全体でクラスタのためのゾーンリストを維持してください。
use data structures that allow parts of the information to be
marked for deletion, while maintaining that information for possible
later reuse-for example, if a network goes down, then comes back up
次に、ネットワークが落ちるなら例えば、可能な後の再利用のための情報が来て戻ると主張している間に情報の部分が削除のために示されるのを許容するデータ構造を使用してください。
use data structures that are bidirectional-supporting both the
conversion of a single FwdReq into multiple FwdReq packets and the
manipulation of individual networks within the cluster
複数のFwdReqパケットへの独身のFwdReqの変換と個人の操作の両方がクラスタの中にネットワークでつなぐ双方向のサポートすることであるデータ構造を使用してください。
An exterior router can cluster any network numbers that is has remapped into an available range of contiguous network numbers. From both an implementation and a management point of view, it is
外のルータはどんなネットワーク・ナンバーもクラスタリングさせることができます。利用可能な範囲の隣接のネットワーク・ナンバーに再写像しました。 実装と管理観点の両方から、それはそうです。
Oppenheimer [Page 78] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[78ページ]RFC1504Appletalk
generally best for an exterior router to cluster all network numbers that it receives from a particular exterior router at a given time. For example, it may be desirable to cluster all of the network numbers included in the initial information exchange with a particular exterior router, then later, to cluster all of the network numbers received in NA events in a given RI- Upd packet.
一般に、外のルータがそれが一時に特定の外のルータから受けるすべてのネットワーク・ナンバーをクラスタリングさせるのは、最も良いです。 例えば、次に、与えられたロードアイランドUpdパケットのNAイベントで受け取られたネットワーク・ナンバーのすべてをクラスタリングさせるように初期の情報交換に特定の外のルータでネットワーク・ナンバーのすべてを含んでいて、クラスタリングするのにおいて望ましくて、より遅いかもしれません。
Maintaining compatibility with AppleTalk Phase 2 complicates the implementation of clustering. An exterior router can include a maximum of 255 zones in a cluster. This limit may prevent the exterior router from clustering all of the network numbers that it receives at one time. When an exterior router receives a list of networks from another exterior router, it does not know how many different zone names the networks use. The exterior router does not have this information until it receives the associated ZI-Rsp packets. Therefore, an exterior router should not build a cluster until it has received a complete zone list for the network numbers being clustered. Once the exterior router has complete zone information for the network numbers, it can cluster the maximum number of network numbers allowed by the 255 zone limit.
AppleTalk Phase2との互換性を維持すると、クラスタリングの実装は複雑にされます。 外のルータはひとかたまりになって最大255のゾーンを含むことができます。 この限界によって、外のルータをそれがひところ受けるネットワーク・ナンバーのすべてがクラスタリングさせることができないかもしれません。 外のルータが別の外のルータからネットワークのリストを受け取るとき、それは、ネットワークがいくつの異なったゾーン名を使用するかを知りません。 外のルータには、関連ZI-Rspパケットを受けるまで、この情報がありません。 したがって、クラスタリングしているネットワーク・ナンバーのための完全なゾーンリストを受け取るまで、外のルータはクラスタを造るべきではありません。 外のルータにネットワーク・ナンバーのための完全なゾーン情報がいったんあると、それは255ゾーンの限界で許容されたネットワーク・ナンバーの最大数をクラスタリングさせることができます。
AURP does not specify the method by which an exterior router, when forming a cluster, should determine the hop count for that cluster- that is, the apparent distance in hops to the single extended network that represents the cluster. Possible implementation options include
AURPはクラスタを形成するとき外のルータがそのすなわち、ホップの見かけの距離のクラスタのためのホップカウントをクラスタを表すただ一つの拡大ネットワークに決定するべきであるメソッドを指定しません。 オプションが含む可能な実装
always setting the hop count to a constant value
いつもホップカウントを恒常価値に設定します。
setting the hop count to the minimum, average, or maximum of the
hop counts for the networks within the cluster
クラスタの中のネットワークのためにホップカウントの最小限、平均、または最大にホップカウントを設定します。
In a large internet, setting the hop count for a cluster too high may make the networks in that cluster unreachable from some networks in the local internet of the exterior router that is clustering the network numbers.
大きいインターネットでは、クラスタのためのホップカウントをあまり高く設定すると、ネットワークはいくつかのネットワークからネットワーク・ナンバーをクラスタリングさせている外のルータの地方のインターネットで手の届かないそのクラスタで利かせるかもしれません。
Modified RTMP Algorithms for a Backup Path
バックアップ道への変更されたRTMPアルゴリズム
In the following RTMP maintenance algorithms defined in Inside AppleTalk, the backup path is an RTMP link. These algorithms can be adapted to AURP according to the architectural model described in the section "AURP Architectural Model" in Chapter 3. Proposed modifications to these algorithms appear in boldface Courier font.
Inside AppleTalkで定義された以下のRTMPメインテナンスアルゴリズムで、バックアップ道はRTMPリンクです。 建築モデルに従って、これらのアルゴリズムをAURPに第3章の「AURPの建築モデル」というセクションで説明されていた状態で適合させることができます。 これらのアルゴリズムへの提案された変更は肉太活字のCourierフォントに現れます。
On Receiving an RTMP Data Packet Through a Port
ポートを通してRTMPデータ・パケットを受けることに関して
IF P is connected to an AppleTalk network AND P's network
number range = 0
PがAppleTalkネットワークとPのネットワーク・ナンバー範囲=0に関連づけられるなら
Oppenheimer [Page 79] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[79ページ]RFC1504Appletalk
THEN BEGIN
P's network number range := packet's sender network
number range;
IF there is an entry for this network number range
THEN delete it;
Create a new entry for this network number range with
Entry's network number range := packet's sender
network number range;
Entry's distance := 0;
Entry's next IR := 0;
Entry's status := Good;
Entry's port := P;
END;
FOR each routing tuple in the RTMP Data packet DO
IF there is a table entry corresponding to the tuple's
network number range
THEN Update-the-Entry
ELSE IF there is a table entry overlapping with the
tuple's network number range
THEN ignore the tuple
ELSE IF P is not a backup path
THEN Create-New-Entry
ELSE Create-New-Tentative Entry;
THEN BEGIN Pのネットワーク・ナンバー範囲:=パケットの送付者ネットワーク・ナンバーは及びます。 このネットワーク・ナンバーのためのエントリーがあれば、範囲THENはそれを削除します。 Entryのネットワーク・ナンバー範囲:=パケットの送付者ネットワーク・ナンバー範囲でこのネットワーク・ナンバー範囲のための新しいエントリーを作成してください。 エントリーの距離:=0。 エントリーの次のIR:=0。 エントリーの状態:=利益。 エントリーのポート:=P。 終わってください。 RTMP DataパケットのそれぞれのルーティングtupleがするFORがtupleのネットワーク・ナンバー範囲THENに重なるあるtupleのネットワーク・ナンバー範囲THEN UpdateエントリーELSE IF aテーブル項目に対応するテーブル項目があって、Pがバックアップの経路のTHEN Createの新しいエントリーでないならtuple ELSEを無視する、ELSE Create、新しく一時的である、Entry。
Update-the-Entry
エントリーをアップデートしてください。
IF (Entry's port is not a backup port AND P is a
backup port)
THEN Return; {Ignore tuple}
IF (Entry's state = Bad) AND (tuple distance <15)
THEN Replace-Entry
ELSE
IF Entry's distance >= (tuple distance +1) AND (tuple
distance <15)
OR (Entry's port is a backup port and P is not a
backup port)
THEN Replace-Entry
ELSE IF Entry's next IR = RTMP Data packet's sender node
address AND Entry's port = P
THEN IF tuple distance <> 31 THEN BEGIN
Entry's distance := tuple distance + 1;
IF Entry's distance < 16
THEN Entry's state := Good
ELSE Delete the entry
END
Else Entry's state := Bad;
(エントリーのポートはバックアップポートではありません、そして、Pはバックアップポートです)THEN Returnであるなら。 tupleを無視してください、(エントリーの州がひどく等しい、)、AND(tuple距離<15)THEN Replace-エントリーELSE IF Entryの距離>=(tuple距離+1)AND(tuple距離<15)OR(エントリーのポートはバックアップポートです、そして、Pはバックアップポートでない)のRTMP Data THEN Replace-エントリーELSE IF Entryの次のIR=パケットの送付者のノードアドレスとEntryのポートはP THEN IF tuple距離<>31THEN BEGIN Entryの距離:=tuple距離+1と等しいです。 距離の<16THEN Entryの州の:=の良いELSE DeleteのEntryがEND Else Entryのエントリーものであるなら、悪い状態で:=を述べてください。
Oppenheimer [Page 80] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[80ページ]RFC1504Appletalk
An exterior router uses the Create-New-Tentative-Entry algorithm when it discovers a previously unknown network across a backup path. An exterior router should not add an entry to the routing table being broadcast to its local internet until it determines definitely that no alternative path to a network is available. While waiting for another path to a network to become available, the exterior router temporarily stores the routing-table entry in a tentative routing table, as defined by the following algorithm:
バックアップ道の向こう側に以前に未知のネットワークを発見するとき、外のルータはCreateの新しい一時的なエントリーアルゴリズムを使用します。 ネットワークへのどんな迂回経路も利用可能でないことを確実に決定するまで、外のルータは地方のインターネットへの経路指定テーブル存在放送にエントリーを加えるべきではありません。 ネットワークへの別の経路が利用可能になるのを待っている間、外のルータは一時的な経路指定テーブルに一時経路指定テーブルエントリーを保存します、以下のアルゴリズムで定義されるように:
Create-New-Tentative-Entry
新しい一時的なエントリーを作成してください。
IF tentative entry for tuple's network number range does not
already exist
THEN BEGIN
Tentative entry's network number range =
tuple's network number range;
Tentative entry's distance := tuple's distance;
Tentative entry's next IR = packet's node address;
Tentative entry's port := P;
Start a TBD-minute timer for this entry;
END;
WHEN timer for this entry expires
IF there is a table entry corresponding to or
overlapping with the tentative entry's network
number range
THEN ignore the entry
ELSE Create-New-Entry; {using data from the tentative
entry}
Delete tentative entry;
tupleのネットワーク・ナンバー範囲への一時的なエントリーが既に存在していないなら、THEN BEGIN Tentativeエントリーのネットワーク・ナンバー範囲はtupleのネットワーク・ナンバー範囲と等しいです。 一時的なエントリーの距離:=tupleの距離。 一時的なエントリーの次のIRはパケットのノードアドレスと等しいです。 一時的なエントリーのポート:=P。 このエントリーのためのTBD-分刻みのタイマーを始動してください。 終わってください。 エントリーのELSE Createの新しいエントリーを対応しているか、またはTHENが無視する一時的なエントリーのネットワーク・ナンバー範囲に重ね合わせるテーブル項目はあれば、このエントリーへのWHENタイマは期限が切れます。 一時的なエントリーからデータを使用して、一時的なエントリーを削除してください。
Oppenheimer [Page 81] RFC 1504 Appletalk Update-Based Routing Protocol August 1993
ルーティング・プロトコル1993年8月のアップデートベースのオッペンハイマー[81ページ]RFC1504Appletalk
Security Considerations
セキュリティ問題
This memo discusses a weak form of security called network hiding or device hiding. More general concerns about security are not addressed.
このメモはネットワーク隠れることかデバイス隠れることと呼ばれるセキュリティの弱形について議論します。 セキュリティに関する、より一般的な心配は扱われません。
Author's Address
作者のアドレス
Alan B. Oppenheimer Apple Computer, M/S 35-K 20525 Mariani Avenue Cupertino, California 95014
アランB.オッペンハイマーアップル・コンピューター、マリアニ・Avenueカルパチーノ、M/S35Kの20525カリフォルニア 95014
Phone: 408-974-4744 EMail: Oppenheime1@applelink.apple.com
以下に電話をしてください。 408-974-4744 メールしてください: Oppenheime1@applelink.apple.com
Note: The author would like to acknowledge the contribution of Pabini Gabriel-Petit here at Apple, who translated the engineering specification into human-readable form.
以下に注意してください。 作者はここ、人間読み込み可能なフォームに工業規格を翻訳したアップルのガブリエルPetitのPabiniの貢献を承諾したがっています。
Oppenheimer [Page 82]
オッペンハイマー[82ページ]
一覧
スポンサーリンク
