Network Working Group S. Deering
Request for Comments: 2902 Cisco Systems
Category: Informational S. Hares
Merit Networks
C. Perkins
Nokia Research Center
R. Perlman
Sun Microsystems Laboratories
August 2000
Overview of the 1998 IAB Routing Workshop
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document is an overview of a Routing workshop held by the Internet Architecture Board (IAB) during March 25-27, 1998. The major points of discussion are listed, along with some conclusions and action items for many of the points of discussion.
この文書は、議論のポイントの多くのためのいくつかの結論とアクションアイテムと一緒に、議論の主要なポイントが表示されている月25-27、1998年の間、インターネットアーキテクチャ委員会（IAB）が保持しているルーティングワークショップの概要です。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conclusions and Action Items . . . . . . . . . . . . . . . . 3
2.1. Scaling of Unicast Routing and Addressing . . . . . . . 3
2.1.1. Unicast Routing - Conclusions . . . . . . . . . . . 3
2.1.2. Unicast Routing - Action Items . . . . . . . . . . 4
2.2. Levels of Addressing of Addressing and Routing . . . . 4
2.3. Network Address Translation (NAT) devices . . . . . . . 5
2.3.1. NAT devices - Conclusions . . . . . . . . . . . . . 5
2.3.2. NAT devices - Action Items . . . . . . . . . . . . 5
2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . 5
2.4.1. Multicast - Conclusions . . . . . . . . . . . . . . 5
2.4.2. Multicast - Action Items . . . . . . . . . . . . . 6
2.5. Routing Stability . . . . . . . . . . . . . . . . . . . 6
2.5.1. Routing Stability - Conclusions . . . . . . . . . . 6
2.5.2. Routing Stability - Action Items . . . . . . . . . 7
2.6. ToS/CoS/QoS . . . . . . . . . . . . . . . . . . . . . . 7
2.6.1. ToS/CoS/QoS - Action Items . . . . . . . . . . . . 8
2.7. Routing Protocol Security . . . . . . . . . . . . . . . 8
2.7.1. Routing Security - Conclusions . . . . . . . . . . 8
2.7.2. Routing Security - Action Items . . . . . . . . . . 8
2.8. Routing Policy . . . . . . . . . . . . . . . . . . . . 8
2.8.1. Routing Policy - Conclusions . . . . . . . . . . . 8
2.8.2. Routing Policy - Action Item . . . . . . . . . . . 9
2.9. Network to Host Flow of Information . . . . . . . . . . 9
2.9.1. Host Information - Conclusions . . . . . . . . . . 9
2.9.2. Host Information - Action Items . . . . . . . . . . 9
2.10. Shorter Topics . . . . . . . . . . . . . . . . . . . . 9
2.10.1. Multi-strand Trunking . . . . . . . . . . . . . . 9
2.10.2. Routing Diagnostic and Development Tools . . . . 10
2.10.3. Anycast . . . . . . . . . . . . . . . . . . . . . 10
2.10.4. Load Sensitive IGP routing for Best Effort Traffic 11
2.10.5. Geographical Addresses and Renumbering . . . . . 11
3. Summary of Action items . . . . . . . . . . . . . . . . . . . 11
3.1. Action Items for the IAB . . . . . . . . . . . . . . . 11
3.2. Action Items for IETF Working Group Chairs . . . . . . 11
3.3. Action Items for the IRTF Routing Research Group . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
A. Participants . . . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 16
March 25 to March 27, 1998 the Internet Architecture Board (IAB) held a workshop on Routing. The workshop focused on current problems within the Internet and the long term solutions that should be addressed. This document summarizes the discussions the group had on routing, and lists the conclusions reached by the workshop. Section 2 lists the conclusions reached by the participants of the workshop and the suggestions for additional work or redirection of current work. Sections 2.1-2.10 attempt to extract the major points of what was, in actuality, many multifaceted discussions, sometimes occurring all at the same time. Appendix A contains a list of the participants who attended the workshop. The full body of the report can be found at http://www.iab.org.
1998年3月27日に3月25日には、インターネットアーキテクチャ委員会（IAB）は、ルーティングに関するワークショップを開催しました。ワークショップでは、現在のインターネット内の問題と取り組むべき長期的な解決策に焦点を当てました。この文書では、グループは、ルーティングに持っていた議論を要約し、そしてワークショップが到達した結論を示しています。第2節では、ワークショップの参加者と現在の仕事の追加作業やリダイレクションのための提案が到達した結論を示しています。セクションだったもの、実際には、多くの多面的な議論が、時々すべて同時に発生の主要なポイントを抽出するために2.1から2.10試みを。付録Aには、ワークショップに参加した参加者のリストが含まれています。レポートのフルボディはhttp://www.iab.orgで見つけることができます。
The topics covered at length during the IAB workshop were:
IABワークショップの間の長さで説明する項目は以下の通りでした。
1. Scaling of Unicast Routing and Addressing (section 2.1) 2. Unicast Addressing Issues (Section 2.2) 3. The Effect of extending IP version 4 in the Internet by using Network Address Transformation boxes (Section 2.3) 4. Multicast Routing (Section 2.4)
1ユニキャストルーティングのスケーリング及びアドレッシング（セクション2.1）2.ネットワークアドレス変換ボックスに（セクション2.3）4.マルチキャストルーティング（セクション2.4を使用して、問題（2.2節）3.インターネットでIPバージョン4を延長する効果をアドレス指定ユニ）
5. Routing Instability (Section 2.5) 6. Quality of Service Routing (Section 2.6) 7. Routing Security (Section 2.7) 8. BGP Policy (Section 2.8) 9. Flows of information from network routing to hosts for improved services (Section 2.9)
5.ルーティング不安定性（セクション2.5）サービスルーティング（セクション2.6）7.ルーティングセキュリティ（セクション2.7）8 BGPポリシー（セクション2.8）改善されたサービスのホストにネットワークルーティングの情報の流れ9（セクション2.9の6クオリティ）
In addition the following topics were briefly covered:
また、以下のトピックは、簡単に覆われていました。
a. Multi-strand trunking b. Better tools for monitoring and diagnosis of network problems c. Routing protocol bandwidth minimization d. Automatic renumbering and automatic organization e. Anycast f. Load-sensitive routing g. Geographical addressing
A。マルチストランドトランキングB。ネットワークの問題cの監視および診断のためのより良いツール。ルーティングプロトコルの帯域幅の最小化D。自動リナンバリングと自動編成E。エニーキャストF。負荷感受性ルーティングG。アドレス指定の地理
These shorter topics are contained in section 2.10.
これらの短いトピックは、セクション2.10に含まれています。
It would be unrealistic to assume that the workshop had definitive answers to all the technical problems that were raised. The best that can be hoped is that we raised most of the relevant issues and gave opinions that were the best guess of the people at the meeting, keeping in mind that the attendees did not come armed with data to back up opinions. Much of the discussion amounted to an exploration of the intuition of the experts in attendance, intuition gained after years of experience in making the Internet work. More work is needed to validate the intuition and experience by way of scientific experimentation and analysis. Unfortunately, it's not so easy to find a spare collection of global Internets upon which one might perform controlled experiments.
ワークショップが提起されたすべての技術的な問題に決定的な答えを持っていたと仮定するのは非現実的だろう。望んすることができる最善のは、我々は、関連する問題のほとんどを上げ、参加者が意見をバックアップするデータと武装来なかったことを念頭に置いて、会議で人々の最良の推測だったの意見を与えたということです。議論の多くは、出席の専門家の直感の探査に達し、直感は、インターネットの仕事を作るの長年の経験の後に得ました。より多くの作業が科学的実験と解析の方法により直感や経験を検証するために必要とされます。残念ながら、それは1つが制御された実験を行う可能性がある時にグローバルなインターネットのスペアコレクションを見つけることは簡単ではありません。
The participants came to a number of conclusions after the discussions referred to in sections 2.1-2.10. These conclusions, presented in this document, provide summary statements and action items for the IETF community.
参加者は、セクション2.1から2.10に言及議論した後、結論の数になりました。この文書のこれらの結論は、IETFコミュニティのための要約文とアクションアイテムを提供しています。
The participants of the workshop came to the following conclusions
ワークショップの参加者は、次の結論に達しました
1. Most of the current unicast routing stability problems can be fixed with improved implementation.
1.現在のユニキャストルーティングの安定性の問題のほとんどは、改良された実装で固定することができます。
2. Some long term systemic issues that may eventually overwhelm the unicast routing are:
2.最終的にはユニキャストルーティングを圧倒していくつかの長期的な全身の問題は、次のとおりです。
- Flaps - which will only get worse unless work is undertaken
- Multi-homing
3. We'd like more research into what's breaking; not just more data, but more analysis of the data
3.私たちは、破壊何に多くの研究をしたいと思います。より多くのデータが、データのより多くの分析だけではなく、
The group reviewed the following potential solutions:
グループには、以下の潜在的な解決策を検討しました：
- Architected NAT (improving the existing Network Address Translation schemes to provide better scaling) - IPv6 (deploying an IP version 6 infrastructure) - MAP/Encap (map to aggregatable addresses and encapsulate the original packet) - Do nothing - Aggressive renumbering (try to continue to encourage renumbering to improve utilization of the IP version 4 address space) - Metro addressing (use a geographical or metropolitan based addressing scheme)
- アーキテクチャNAT（より良いスケーリングを提供するために、既存のネットワークアドレス変換スキームを改善するには） - IPv6の（IPバージョン6のインフラストラクチャを展開） - MAP / ENCAPは（集約アドレスにマッピングし、元のパケットをカプセル化） - 何もない - 積極的なリナンバリングは（しようとしません）IPバージョン4つのアドレス空間の利用率を向上させるためにリナンバリングを奨励し続ける - メトロのアドレッシング（ベース地理や大都市アドレス方式を使用します）
We recommend that the IRTF Routing Research group should encourage more analysis of routing data, not just the collection of more data.
私たちは、IRTFのルーティング研究グループは、ルーティングデータのより多くの分析、より多くのデータだけではなく、コレクションを奨励すべきであることをお勧めします。
Levels of hierarchy do not matter to the customers. Address hierarchy must be distinguished from routing hierarchy. The group examined whether the current Internet has enough levels of hierarchy in Internet addresses or routing infrastructure. The group did not find that levels of hierarchy should be added to the Internet, at least for now. Flat routing at the AS level seems to be workable; if this changes in the future, hierarchy would need to be revisited, and studied with due consideration to convergence time for routing algorithms and trust management. There is no universal agreement that adding levels of hierarchy at this point in time provides a well-defined benefit. Furthermore, two levels is difficult for many people, and any more than that is difficult both to build and to use.
階層のレベルは、顧客に重要ではありません。アドレス階層は、階層をルーティングとは区別されなければなりません。グループは、現在のインターネットは、インターネットアドレスまたはルーティングインフラストラクチャにおける階層の十分なレベルを有しているかどうかを調べました。グループは階層のレベルが、少なくとも今のところ、インターネットに追加する必要があることを見つけることができませんでした。 ASレベルでのフラットルーティングが実行可能であると思われます。これは将来的に変更された場合、階層がアルゴリズムと信頼管理をルーティングするために再訪し、収束時間を考慮して検討する必要があるだろう。この時点で階層のレベルを追加することが明確に定義された利点を提供する普遍的な合意はありません。さらに、2つのレベルは、多くの人々のために困難であり、それよりも、それ以上は両方が構築し、使用することは困難です。
Upon reviewing the NATs, the group
NATのを検討する際、グループ
1. Noted that NAT devices are fairly widely deployed 2. Identified various problems with the use of NAT devices within the internet 3. Discussed the interaction between NAT devices and applications 4. Listed the following options regarding NAT devices:
1. NATデバイスはかなり広く、インターネット3内のNATデバイスの使用2.特定された様々な問題がNATデバイスやアプリケーションNATデバイスに関する4.上場、以下のオプションの間の相互作用を話題に配備されている次のように述べています。
- Eliminate NATs
- Fix NATs to interact better with the rest of the Internet
- Fix applications to interact better with NAT boxes
- Don't do certain things -- like IP Security (IPSec)
1. Forward our concerns, problems and suggestions to the appropriate working groups 2. Note architectural work outside the NAT working group 3. Suggest to the IAB that it continue to be concerned about the issues involving NATs
それはNATのに関する問題について心配であり続けることをNATワーキンググループ3.外2.注建築の仕事はIABに提案する適切なワーキンググループへの転送1.私たちの懸念、問題や提案
Since the multicast model was created, many multicast applications have been tried over the Internet multicast routing fabric. The group began to discuss the multicast model in terms of enabling multicast applications to run efficiently, and scale favorably with future growth. Multicast applications place varying requirements on multicast routing.
マルチキャストモデルが作成されて以来、多くのマルチキャストアプリケーションは、インターネットマルチキャストルーティングの生地の上に試されてきました。グループは、効率的に実行し、将来の成長に好意的にスケールするマルチキャストアプリケーションを有効にするという点でマルチキャストモデルを議論し始めました。マルチキャストアプリケーションは、マルチキャストルーティングの様々な要件を置きます。
Multicast applications may have a variable:
マルチキャストアプリケーションでは、変数を持っていることがあります。
- number of sources, - number of receivers, - amount of data, - amount of data in a burst, and length of quiet periods - number of groups utilized per application or per set of cooperating applications, and - amount of time during which the group exists - topological distance between members of the group. - volatility of membership
- ソースの数、 - 受信機の数、 - データの量、 - バースト内のデータの量、及び沈黙期間の長さ - アプリケーションごと、または協働アプリケーションのセットごとに利用グループの数、および - 時間量の間グループが存在する - グループのメンバー間のトポロジー距離。 - 会員のボラティリティー
Multicast routing must provide the flexibility to support the varying requirements of different multicast applications. The current multicast model establishes multicast routing paths upon reception of a data packet. The discussion on the viability of the multicast model examined the viability of the model in terms of the uses of multicast routing by applications and the scalability to full Internet usage. For example, providing for many groups of small conferences (a small number of widely-dispersed people) with global topological scope scales badly given the current multicast model.
マルチキャストルーティングは異なるマルチキャストアプリケーションのさまざまな要件をサポートするための柔軟性を提供しなければなりません。現在のマルチキャストモデルは、データパケットを受信すると、マルチキャストルーティングパスを確立します。マルチキャストモデルの生存率に対する議論は、アプリケーションによるマルチキャストルーティングの使用および完全なインターネット利用のスケーラビリティの点でモデルの生存率を調べました。例えば、大域的な位相範囲を有する小さな会議の多くのグループ（広く分散した人々の数が少ない）を提供することはひどく現在のマルチキャストモデルを所与のスケール。
The group felt the existing multicast protocols and multicast should be evaluated in terms of the requirements listed above. The group suggested that the evaluation should include the multicast protocols DVMRP [12], MOSPF [8], PIM [4], CBT [2], and Express [5], as well as the following mechanisms used by multicast applications:
グループは、既存のマルチキャストプロトコルとマルチキャストが上記の要件の観点から評価されるべきであると感じました。グループは、評価は、マルチキャストプロトコルDVMRP [12]、MOSPF [8]、PIM [4]、CBT [2]、及びエクスプレス[5]、ならびにマルチキャストアプリケーションによって使用される次のメカニズムを含むべきであることを示唆しました。
1. Registering with the core or the RP (Rendezvous Point), 2. Having the ID of the group include the core, and having joins specify the core 3. Having the ID of the group include the core, and having joins and data specify both 4. Sending data via unicast to all members, and 5. Sending data via unicast transport to the RP.
1.コアまたはグループのIDを有するRP（ランデブーポイント）、2.含むコアへの登録、および有するグループのIDがコアを含み有するコア3を指定参加、および有する加入データを指定します4.すべてのメンバーにユニキャストを介してデータを送信する、と5はRPにユニキャストトランスポートを介してデータを送信するの両方。
The group acknowledged that the current multicast model does not scale well for all scenarios that applications use.
グループは、現在のマルチキャストモデルは、アプリケーションが使用するすべてのシナリオにうまくスケールしないことを認めました。
The group noted that reliable multicast is surprisingly orthogonal to the issues about the scaling of the multicast model to all possible applications.
グループは、信頼性の高いマルチキャストが可能なすべてのアプリケーションへのマルチキャストモデルのスケーリングに関する問題に驚くほど直交であることを指摘しました。
Encourage evaluation and written reports on these multicast protocols, and mechanisms for different types of protocols.
評価を奨励し、プロトコルの種類ごとにこれらのマルチキャストプロトコル、およびメカニズムに関するレポートを書かれました。
Notify the IRTF Routing Research Group of the need to charter activity in this area.
このエリアのチャーター活動に必要なのIRTFのルーティング研究グループに通知します。
Damping the effects of route updates enhances stability, but possibly at the cost of reachability for some prefixes. A prefix can be damped and reachable via another path, so that for such prefixes the effects of damping are less serious than for other prefixes. The performance of various algorithms for enhancing stability should be measured by recording whether the affected route prefixes are reachable or not reachable. Using current damping approaches, approximately 1% of the prefixes are affected at any one point in time. We should try to find out how many prefixes are unreachable because of damping.
ルート更新の影響をダンピングして安定性を向上させますが、おそらくいくつかのプレフィックスの到達可能性を犠牲に。そのようなプレフィクスのための減衰の影響が他のプレフィックスよりも少なく深刻であるように接頭辞は、別の経路を介して減衰し、到達することができます。安定性を高めるための様々なアルゴリズムの性能は、影響を受ける経路プレフィックスが到達可能到達可能であるか否かを記録することによって測定されるべきです。現在の減衰アプローチを使用して、接頭辞の約1％は、時間内の任意の一点で影響を受けます。当社は、理由の減衰の到達不能であるか、多くのプレフィックスを見つけるために試してみてください。
The conclusion is that this effort merits continued investigation.
結論は、この努力のメリットが捜査を続けていることです。
The IRTF Routing Research Group should measure how stable things are, and if stability is an issue, to study methods of making them more stable.
IRTFのルーティング研究グループは、物事がどのように安定して測定する必要があり、かつ安定性が問題であるならば、それらをより安定して製造する方法を研究します。
The group noted that the terms Type of Service (ToS), Class of Service (CoS), and Quality of Service (QoS) are imprecise as currently used. The discussion started by defining the terminology as follows:
グループは、現在、使用されるサービス（TOS）、サービスクラス（CoS）、およびサービス品質（QoS：Quality of Service）の観点タイプが不正確であることを指摘しました。議論は次のように用語を定義することによって開始しました：
ToS: hop by hop routing based on destination plus ToS bits [9] CoS: classes of service based on service contracts. These classes of service are enabled by a variety of mechanisms which include queueing, and multiple physical or link level paths. QoS: managing routes that meet certain quality of service constraints, and involving the following steps:
ToS：サービス契約に基づいてサービスのクラス：先プラスToSビット[9]のCoSに基づいてホップルーティングによってホップ。サービスのこれらのクラスは、キューイング、及び複数の物理またはリンクレベルの経路を含む種々の機構によって有効にされています。 QoSは：サービスの制約の一定の品質を満たすルートを管理し、次のステップを含みます：
* routing the resource requests
* setting up a path that satisfies the constraints
* routing the data
There is no smooth dividing line between between ToS and QoS. ToS is relative. QoS is absolute. The group discussed whether there is a demand for ToS, CoS and QoS. Differentiated-services [3] as discussed in the IETF is ToS++.
ToSおよびQoSの間に間にはスムーズな境界線がありません。 ToSのは相対的なものです。 QoSは絶対的です。グループはのToS、CoSおよびQoSの需要があるかどうかを議論しました。 IETFで議論するように分化し、サービス[3] ++のToSあります。
The group also discussed a more general concept of "Constraint Based Routing" which was defined as traffic engineering on large aggregated flows. Constraint based routing allows the providers to better utilize the bandwidth in their network to handle traffic requests from users. Besides enabling policy management techniques, constraint based routing allows providers to route traffic based on the characteristics of the traffic flows.
グループも大きく集約フローのトラフィックエンジニアリングのように定義された「制約ベースルーティング」のより一般的な概念を論じました。制約ベースのルーティングは、プロバイダは、より良いユーザーからのトラフィック要求を処理するために、ネットワーク内の帯域幅を利用することができます。ポリシー管理技術を可能にするほかに、制約ベースのルーティングは、トラフィックフローの特性に基づいてトラフィックをルーティングするプロバイダを可能にします。
We recommend that IETF should look into the issue of Constraint Based Routing.
私たちは、IETFが制約ベースルーティングの問題を調査することをお勧めします。
After a lengthy discussion of the various problems of network security, the group notes that:
ネットワークセキュリティの様々な問題の長い議論の後、グループはそのノート：
1. Routers need intrinsic system security as good as or better than any host computer. 2. Improving router security will not solve all problems. 3. Console access to the router can do everything. 4. One compromised router can create disaster. 5. ISPs and vendors should consider taking some control traffic out of band, due to lack of wire speed authentication. 6. We discussed other issues that will be passed on to the appropriate people involved with network security. 7. Identified areas of work to improve things (e.g., wire speed authentication).
1.ルータは良いとしてまたは任意のホストコンピュータよりも優れた固有のシステムのセキュリティを必要とします。 2.ルータのセキュリティを改善することはすべての問題を解決することはできません。ルータへ3.コンソールへのアクセスは、すべてを行うことができます。 4.一つの妥協ルータは、災害を作成することができます。 5. ISPやベンダーは、ワイヤスピードの認証が不足しているため、バンドのうち、いくつかの制御トラフィックを取って検討すべきです。 6.私たちは、ネットワークセキュリティに関わる適切な人に渡される他の問題について議論しました。もの（例えば、ワイヤスピード認証）を改善するための作業7.識別領域。
The IETF should encourage work on "wire speed" authentication, pair-wise authentication of routers in routing protocols, and Byzantine robustness [6] in routing protocols.
IETFは、ルーティングプロトコルにおける「ワイヤスピード」認証、ルーティングプロトコルのルータのペアワイズ認証、ビザンチン堅牢[6]の作業を奨励すべきです。
During our discussion on routing policy the group reviewed what could be done with BGP. The group noted that:
ルーティングポリシーに私たちの議論の中でグループをBGPで何ができるか検討しました。グループは、次のように述べています。
1. Some routing policies requested by ISPs or NSPs are not solvable with BGP. Some of these "unsolvable" routing policies can be put into effect using tunnels and static configuration. 2. BGP is only a mechanism for announcing reachability 3. BGP routing controls traffic direction without regard to traffic volume. 4. BGP policy management is too delicate, too easy to mess up, and fragile.
1. ISPやNSPのによって要求されたいくつかのルーティングポリシーは、BGPと解けるではありません。これらの「解けない」ルーティングポリシーの一部は、トンネルと静的な構成を使用して発効することができます。 2. BGPは、トラフィック量に関係なく、到達可能3. BGPルーティングを制御するトラフィックの方向を発表するための唯一のメカニズムです。 4. BGPポリシー管理があまりにも台無しに簡単に、そして壊れやすい、あまりにも繊細です。
5. Router Configuration Language is very complex and error-prone 6. We can't count on symmetric routing, so ISPs/NSPs/Enterprise nets should deal with it.
5.ルータの設定言語のISP / NSPの/エンタープライズネットはそれに対処すべきであるように、我々は、対称ルーティングに数えることができない非常に複雑で、エラーが発生しやすい6です。
The group concluded the Internet needed a better routing policy specification language.
グループは、インターネットがより良いルーティングポリシー仕様言語を必要と結論付けました。
Pass the concerns about the Routing Policy Syntax Language (RPSL) [1] to chairs of the Routing Policy Syntax (RPS) working group [11].
ルーティングポリシーの構文（RPS）ワーキンググループの議長に[1] [11]ルーティングポリシーシンタックス言語（RPSL）についての懸念を渡します。
Publishing information about traffic statistics along backbone routes could improve the way Internet services replicate data for retrieval from various sites. This replication could be especially important for the retrieval of information off the web. Currently, web pages refer people to caches local to their sites; for instance, a European site might be used for United Kingdom customers and a North American site for North American customers. Proponents of web caches want to auto-configure the locations of web caches so a user's web browser can automatically discover the local cache. Other applications share this need for finding the best cache for a particular service.
基幹ルートに沿ってトラフィックの統計についての情報を公開するインターネットサービスは、様々なサイトからの検索のためにデータを複製する方法を改善することができました。このレプリケーションは、ウェブオフ情報の検索のために特に重要である可能性があります。現在、Webページには、自分のサイトへのローカルキャッシュに人々を参照してください。例えば、ヨーロッパのサイトには、英国の顧客のために使用されるかもしれないし、北米のお客様のために北米サイト。 Webキャッシュの支持者はそうユーザのWebブラウザが自動的にローカルキャッシュを発見することができますWebキャッシュの位置を自動設定します。他のアプリケーションは、特定のサービスのための最良のキャッシュを見つけるためのこの必要性を共有しています。
The group recommends a BOF be held on Measuring Path Characteristics. Measurement of path characteristics should include:
グループは、BOFはパス特性の測定に開催することをお勧めします。パス特性の測定が含まれるべきです。
- format for exchange of measurement data - mechanisms for distribution of measurement data
- 測定データを交換するためのフォーマット - 測定データの配信のための機構
IPPM working group [7] is dealing with issues within the measurement problem space.
[7] IPPMワーキンググループは、測定問題空間内での問題を扱っています。
PPP did multi-link in a way that required too much computation and could not be used for faster links. Internet technology should treat multiple parallel trunks as 1 link at the IP layer, but with multi-dimensional metrics.
PPPは、あまりにも多くの計算を必要とし、より高速なリンクに使用することができなかった方法で、マルチリンクをしました。インターネット技術はなく、多次元のメトリックと、IP層での1つのリンクとして複数の並列トランクを扱う必要があります。
Multi-strand Trunking - Action Items
マルチストランドトランキング - アクション項目
There is design and development work at layer two which should be done to support the multiple parallel trunks. This layer two work is outside the scope of the IETF. Layer three routing should support richer metrics in OSPF.
複数の並列トランクをサポートするために行われるべき層2の設計および開発作業があります。この層2作品は、IETFの範囲外です。レイヤ3つのルーティングはOSPFで豊かなメトリックをサポートする必要があります。
1. It would be nice to have an Authoritative Database listing those prefixes permitted from each AS. The authoritative data base was attempted before without success, but the group felt it might be useful to try again. 2. SNMP version 3 should be deployed in order to make use of its improved authentication, scope and rate limiting 3. Remotely-controlled traffic monitors should be used to measure traffic 4. Better tools are needed for preventative problem detection
1.各ASから許可された接頭辞をリスト権威データベースを持っていいだろう。正式なデータ・ベースは成功せずに前にしようとしたが、グループはそれを再試行する役に立つかもしれないと感じました。 2. SNMPバージョン3は、その改善の認証を利用するために配備されなければならない、3.リモート制御トラフィックモニタを制限範囲と率が4より良いツールが予防問題の検出のために必要とされるトラフィックを測定するために使用する必要があります
1. Encouraged an authoritative database within the Internet 2. Notify SNMP version 3 working groups regarding needs for authentication, scope, and rate limiting. 3. Encourage funding of better tools for remotely controlled traffic sources and pro-active problem detection.
1.インターネット2内の権威データベースは、SNMPバージョン3制限認証、範囲、および率のためのニーズに関するワーキンググループを通知するよう奨励しました。 3.リモートコントロールトラフィックソースとプロアクティブな問題を検出するための優れたツールの資金調達を奨励します。
1. We need to describe the advantages and disadvantages of anycast. 2. Local-scoped well-known anycast addresses will be useful to applications.
1.私たちは、エニーキャストの長所と短所を記述する必要があります。 2.ローカルスコープのよく知られたエニーキャストアドレスは、アプリケーションに有用であろう。
A BOF should be held to plan work on anycast.
BOFは、エニーキャストの作業を計画するために開催されなければなりません。
If a working group forms, a paper on the advantages and disadvantages of anycast should be included as part of the charter.
ワーキンググループのフォーム場合は、エニーキャストの長所と短所についての論文は、憲章の一部として含まれるべきです。
While load sensitive routing is interesting in some ways, it cannot be considered until certain problems are worked out. Currently, constraint based routing is assigning administrative metrics to allow routing to adapt to different traffic patterns. Load sensitive routing may increase oscillation and instability of routes. This instability of routes, sometimes called churn, may affect the ability of the routing infrastructure to scale.
負荷に敏感なルーティングはいくつかの点で興味深いですが、特定の問題が出て働いているまで、それを考慮することはできません。現在、制約ベースのルーティングは、ルーティングは異なるトラフィックパターンに適応できるようにするために、管理指標を割り当てています。負荷敏感ルーティング経路の振動や不安定性を増大させることができます。時々チャーンと呼ばれるルートのこの不安定性は、スケーリングするルーティングインフラストラクチャの能力に影響を及ぼし得ます。
Load sensitive routing would allow IGPs to better utilize links. Past and current efforts in load sensitive routing include: QoS OSPF [10], Q-OSPF [10], and load sensitive routers developed by BBN.
IGPは、より良いリンクを利用できるようになる敏感なルーティングをロードします。 QoSのOSPF [10]、Q-OSPF [10]、およびBBNによって開発された敏感なルータをロード：負荷敏感ルーティングにおける過去及び現在の努力が挙げられます。
The IRTF Routing Research group chair and Routing Area Director should discuss this subject and determine what techniques from Load Sensitive IGP routing are ready for IETF, and what requires additional research.
IRTFルーティング研究グループの議長およびルーティングエリアディレクターは、このテーマを議論し、ロード敏感IGPルーティングの技術はIETFの準備ができているものを、追加研究が必要であるかを決定する必要があります。
This topic was discussed, but without any conclusions or action items.
このトピックではなく、何らかの結論やアクションアイテムなしで、議論されました。
1. The IAB should be concerned about the issues involving NATs 2. Authoritative Database (for addresses within domains) should be encouraged within the Internet 3. Encourage funding of better tools for remotely controlled traffic sources and pro-active problem detection.
1. IABは、（ドメイン内のアドレス用）2.権限データベースをNATのに関わる問題を心配する必要があります。3.リモートで制御トラフィックの送信元とプロアクティブな問題を検出するための優れたツールの資金調達を奨励するインターネットの中に奨励されるべきです。
1. NAT: Forward our concerns, problems and suggestions to the appropriate working groups 2. We recommend that IETF should work the issue of Constraint Based Routing. 3. The IETF should encourage work on "wire speed" authentication, pair-wise authentication of routers in routing protocols, and Byzantine robustness in routing protocols.
1. NAT：私たちは、IETFが制約ベースルーティングの問題を動作する必要があることをお勧めします。2.適切なワーキンググループに私たちの懸念、問題や提案を転送します。 3. IETFは、「ワイヤスピード」認証、ルーティングプロトコルでルーターのペアで認証、およびルーティングプロトコルでビザンチン堅牢性に関する作業を奨励すべきです。
4. Concerns about the Routing Policy Specification Language (RPSL) should go to the Routing Policy Systems (RPS) working group chair. 5. The group recommends a BOF be held on Measuring Path Characteristics. The BOF should consider the data exchange format of measurement and mechanisms to distribution of data mechanism. It is noted that the IPPM working group is dealing with issues within the measurement problem space. 6. There is layer two work which should be done to support the multiple parallel trunks which is outside the scope of the IETF. Layer three routing should support richer metrics in OSPF. 7. SNMP version 3 working groups should be notified about the issues about authentication, scope, and rate limiting. 8. A BOF should be held to plan work on anycast. A document on anycast should be part of the proposed working group charter.
ルーティングポリシー仕様言語（RPSL）約4懸念はルーティングポリシーシステム（RPS）ワーキンググループの議長に行く必要があります。 5.グループは、BOFはパス特性の測定に開催することをお勧めします。 BOFは、データ機構の分布を測定し、機構のデータ交換フォーマットを考慮すべきです。 IPPMワーキンググループは、測定問題空間内での問題を扱っていることに留意されたいです。 6. IETFの範囲外である複数の並列トランクをサポートするために行わなければならない2つのワークの層が存在します。レイヤ3つのルーティングはOSPFで豊かなメトリックをサポートする必要があります。 7. SNMPバージョン3のワーキンググループは、認証、スコープ、およびレート制限に関する問題について通知しなければなりません。 8. A BOFは、エニーキャストの作業を計画するために開催されなければなりません。エニーキャストの文書は、提案されたワーキンググループ憲章の一部である必要があります。
1. We recommend that the IRTF Routing Research working group try to encourage more analysis of routing data, not just the collection of more data.
1.私たちはIRTFのルーティング研究ワーキンググループがルーティングデータのより多くの分析、より多くのデータだけではなく、コレクションを奨励しようとすることをお勧めします。
2. Encourage evaluation and written reports on the evaluation of multicast protocols and mechanisms for different types of protocols
2.プロトコルの種類ごとにマルチキャストプロトコルとメカニズムの評価に関する評価と書かれた報告書を奨励
3. The IRTF Routing Research group chair and the Routing Area Director should discuss Load Sensitive IGP routing and determine whether it is ready for the IETF.
3. IRTFルーティング研究グループの議長およびルーティングエリアディレクターロード敏感IGPルーティングを議論し、それがIETFの準備ができているかどうかを判断する必要があります。
Security considerations were an important part of the discussions at the workshop, but the workshop decided not to publish a summary of these discussions. Other documents that address the issues of routing infrastructure security have recently been published.
セキュリティの考慮事項は、ワークショップでの議論の重要な一部であったが、ワークショップでは、これらの議論の概要を公開しないことに決めました。ルーティングインフラストラクチャのセキュリティの問題に対処する他の文書は、最近発表されています。
A. Participants
A.参加
(Email addresses as of the meeting date.)
（会議日現在の電子メールアドレス。）
Harald Alvestrand Harald.Alvestrand@maxware.no Fred Baker fred@cisco.com Jeff Burgan burgan@corp.home.net Brian Carpenter brian@hursley.ibm.com Noel Chiappa jnc@ginger.lcs.mit.edu Rob Coltun rcoltun@fore.com Steve Deering deering@cisco.com Deborah Estrin estrin@usc.edu
ハラルドAlvestrand Harald.Alvestrand@maxware.noフレッド・ベイカーfred@cisco.comジェフBurgan burgan@corp.home.netブライアン・カーペンターbrian@hursley.ibm.comクリスマスChiappa jnc@ginger.lcs.mit.eduロブColtun rcoltunする@フォア.COMスティーブデアリングdeering@cisco.comデボラ・エストリンestrin@usc.edu
Dino Farinacci dino@cisco.com Paul Francis francis@slab.ntt.co.jp Elise Gerich epg@home.net Joel Halpern jhalpern@newbridge.com Sue Hares skh@merit.edu Cyndi Jung cmj@3Com.com Dave Katz dkatz@jnx.com Tony Li tli@juniper.net Peter Lothberg roll@stupi.se Louis Mamakos louie@uu.net Dave Meyer dmm@cisco.com Keith Moore moore@cs.utk.edu Bob Moskowitz rgm@htt-consult.com Thomas Narten narten@raleigh.ibm.com Vern Paxson vern@ee.lbl.gov Charles E. Perkins cperkins@eng.sun.com Radia Perlman Radia.Perlman@East.Sun.COM Yakov Rekhter yakov@cisco.com Allyn Romanow allyn@MCI.NET Martha Steenstrup msteenst@bbn.com George Swallow swallow@cisco.com
ディノファリナッチdino@cisco.comポール・フランシスfrancis@slab.ntt.co.jpエリーゼGerich epg@home.netジョエル・ハルパーンjhalpern@newbridge.comスーノウサギskh@merit.eduシンディ・ユングcmj@3Com.comデイブ・カッツdkatz @ jnx.comトニー・リーは、ピーター・ロスバーグはroll@stupi.se tli@juniper.netルイMamakos louie@uu.netデイブ・マイヤーdmm@cisco.comキース・ムーアmoore@cs.utk.eduボブ・モスコウィッツrgm@htt-consult.comトーマスNarten氏narten@raleigh.ibm.comバーン・パクソンvern@ee.lbl.govチャールズE.パーキンスcperkins@eng.sun.comラディア・パールマンRadia.Perlman@East.Sun.COMヤコフ・レックターyakov@cisco.comアリンRomanowアリン@ MCI.NETマーサSteenstrup msteenst@bbn.comジョージスワローswallow@cisco.com
References
リファレンス
[1] Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer, D., Terpstra, M. and C. Villamizar, "Routing Policy Specification Language (RPSL)", RFC 2280, January 1998.
[1] Alaettinoglu、C.、ベイツ、T.、Gerich、E.、Karrenberg、D.、マイヤー、D.、テルプストラ、M.とC. Villamizar、 "ルーティングポリシー仕様言語（RPSL）"、RFC 2280、 1998年1月。
[2] Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.
[2] Ballardie、A.、 "コアベースツリー（CBT）マルチキャストルーティングアーキテクチャ"、RFC 2201、1997年9月。
[3] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[3]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[4] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[4] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、C.、シャルマ、P.、およびL.魏、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様"、RFC 2362、1998年6月。
[5] Holbrook, H., Cheriton, D, "EXPRESS Multicast", SIGCOMM 99, September 1999.
[5]ホルブルック、H.、Cheriton、D、 "EXPRESSマルチキャスト"、SIGCOMM 99、1999年9月。
[6] Charlie Kaufman, Radia Perlman, and Mike Speciner. Network Security: Private Communication in a Public World, pages 462-- 465. Prentice-Hall, Inc., 1995.
[6]チャーリー・カウフマン、ラディア・パールマン、及びマイクSpeciner。ネットワークセキュリティ：公共世界のプライベートコミュニケーション、ページ462-- 465プレンティスホール社、1995。
[7] W. Leland and M. Zekauskas (chairs). IP Performance Metrics (IPPM), October 1997. http://www.ietf.org/html.charters/ippm-charter.html.
[7] W.リーランドとM. Zekauskas（椅子）。 IPパフォーマンス・メトリック（IPPM）、1997年10月http://www.ietf.org/html.charters/ippm-charter.html。
[8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[8]モイ、J.、 "OSPFへのマルチキャスト拡張機能"、RFC 1584、1994年3月。
[9] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[9]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.ブラック、 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"、RFC 2474、1998年12月。
[10] H. Sandick and E. Crawley (chairs). QoS Routing (qosr), April 1997. http://www.ietf.org/html.charters/qosr-charter.html.
[10] H. Sandick及びE.クローリー（椅子）。 QoSルーティング（qosr）、1997年4月http://www.ietf.org/html.charters/qosr-charter.html。
[11] C. Villamizar and C. Alaettinoglu (chairs). Routing Policy Syntax (RPS), July 1995. http://www.ietf.org/html.charters/rps-charter.html.
[11] C. Villamizar及びC. Alaettinoglu（椅子）。ルーティングポリシーの構文（RPS）、1995年7月http://www.ietf.org/html.charters/rps-charter.html。
[12] Waitzman, D., Partridge, C. and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[12] Waitzman、D.、ヤマウズラ、C。およびS.デアリング、 "距離ベクトルマルチキャストルーティングプロトコル"、RFC 1075、1988年11月。
Authors' Addresses
著者のアドレス
Questions about this memo can be directed to:
このメモに関する質問に向けることができます。
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
スティーブンE.デアリングシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706 USA
Phone: +1 408 527-8213 EMail: deering@cisco.com
電話：+1 408 527-8213 Eメール：deering@cisco.com
Susan Hares Merit, Inc. 1071 Beal Avenue, Ann Arbor, MI 48109 USA
スーザンノウサギメリット、Inc.の1071ビールアベニュー、アナーバー、MI 48109 USA
Phone: +1 313 936-2095 EMail: skh@nexthop.com
電話：+1 313 936-2095 Eメール：skh@nexthop.com
Radia Perlman Sun Microsystems Laboratories 2 Elizabeth Drive Chelmsford, MA 01824 USA
ラディア・パールマンSun Microsystemsの研究所2エリザベスドライブチェルムズフォード、MA 01824 USA
Phone: +1 978 442-3252 EMail: Radia.Perlman@sun.com
電話：+1 978 442-3252 Eメール：Radia.Perlman@sun.com
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
チャールズE.パーキンスノキア・リサーチセンター313フェアチャイルドドライブマウンテンビュー、CA 94043 USA
Phone: +1 650 625-2986 EMail: Charles.Perkins@nokia.com Fax: +1 650-625-2502
電話：+1 650 625-2986 Eメール：Charles.Perkins@nokia.comファックス：+1 650-625-2502
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。