[要約] RFC 2902は、1998年のIABルーティングワークショップの概要を提供しています。このRFCの目的は、ワークショップの議論と結果を要約し、インターネットルーティングの改善に向けた方向性を提供することです。
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
1998年のIABルーティングワークショップの概要
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.
Copyright（c）The Internet Society（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.
このドキュメントは、1998年3月25〜27日にインターネットアーキテクチャ委員会（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月25日から3月27日、インターネットアーキテクチャボード（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) 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)
1. ユニキャストルーティングとアドレス指定のスケーリング（セクション2.1）2。ユニキャストのアドレス指定問題（セクション2.2）3。ネットワークアドレス変換ボックスを使用してインターネット4を拡張する効果（セクション2.3）4。マルチキャストルーティング（セクション2.4）5。ルーティングの不安定性（セクション2.5）6。サービスルーティングの品質（セクション2.6）7。セキュリティのルーティング（セクション2.7）8。BGPポリシー（セクション2.8）9。ネットワークルーティングからホストへの情報の流れが改善されたサービス（セクション2.9）
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。aycast 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.
ワークショップが提起されたすべての技術的な問題に対して決定的な答えを持っていたと仮定することは非現実的です。期待できるのは、関連する問題のほとんどを提起し、会議で人々の最良の推測である意見を述べたことであり、出席者が意見をバックアップするためのデータを武装していなかったことを念頭に置いて、意見を述べたことです。議論の多くは、出席している専門家の直観の調査に属し、インターネットを機能させるための長年の経験の後に直観が得られました。科学的実験と分析により、直観と経験を検証するには、さらに作業が必要です。残念ながら、制御された実験を行う可能性のあるグローバルなインターネットの予備のコレクションを見つけることはそれほど簡単ではありません。
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)
- Arkitected NAT（既存のネットワークアドレス変換スキームの改善により、より良いスケーリングを提供する） - IPv6（IPバージョン6インフラストラクチャの展開） - マップ/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デバイスはかなり広く展開されていることに注意してください。2。インターネット内のNATデバイスの使用に関するさまざまな問題を特定しました。3。NATデバイスとアプリケーション間の相互作用について説明しました。4。NATデバイスに関する次のオプションをリストしました。
- 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)
- NATを排除する - NATを修正して、他のインターネットとよりよくやり取りする - アプリケーションを修正して、NATボックスとより良く対話する - 特定のことをしないでください - IPセキュリティ（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
1. 適切なワーキンググループに懸念、問題、提案を転送する2. NATワーキンググループの外での建築作業に注意3. IABに、NATが関与する問題について心配し続けることを提案します
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]、およびExpress [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. コアまたはRP（rendezvous point）に登録する、2。グループのIDにコアが含まれ、グループのIDがコアを指定することを指定し、結合してデータを結合してデータを指定します4 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）という用語が現在使用されているように不正確であると指摘しました。議論は、用語を次のように定義することから始まりました。
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、QOの需要があるかどうかを議論しました。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.妥協したルーターの1つは災害を引き起こす可能性があります。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. ルーター構成言語は非常に複雑でエラーが発生しやすい6.対称ルーティングを期待することはできません。そのため、ISPS/NSPS/エンタープライズネットはそれに対処する必要があります。
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].
ルーティングポリシー構文言語（RPSL）[1]に関する懸念をルーティングポリシー構文（RPS）ワーキンググループ[11]の椅子に渡します。
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ブラウザーがローカルキャッシュを自動的に発見できるように、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.
IPPMワーキンググループ[7]は、測定問題スペース内の問題を扱っています。
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. それぞれから許可されているプレフィックスをリストする権威あるデータベースがあるといいでしょう。権威あるデータベースは以前に成功せずに試みられましたが、グループは再試行することが有用であると感じました。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. Anycastの利点と短所を説明する必要があります。2.ローカルスコープのある有名なAnycastアドレスは、アプリケーションに役立ちます。
A BOF should be held to plan work on anycast.
Anycastで作業を計画するためにBOFを開催する必要があります。
If a working group forms, a paper on the advantages and disadvantages of anycast should be included as part of the charter.
ワーキンググループが形成される場合、憲章の一部として、Anycastの利点と短所に関する論文を含める必要があります。
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-SOSPF [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ルーティングリサーチグループの椅子とルーティングエリアディレクターは、この主題について話し合い、Loadに敏感な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は、NAT 2に関連する問題について懸念する必要があります。2。信頼できるデータベース（ドメイン内のアドレス）をインターネット内で奨励する必要があります。
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：適切なワーキンググループに懸念、問題、提案を転送します2. IETFは制約ベースのルーティングの問題に取り組むことをお勧めします。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.
4. ルーティングポリシー仕様言語（RPSL）に関する懸念は、ルーティングポリシーシステム（RPS）ワーキンググループチェアにアクセスする必要があります。5.グループは、パスの特性を測定することにBOFが保持されることを推奨しています。BOFは、データメカニズムの分布に対する測定とメカニズムのデータ交換形式を考慮する必要があります。IPPMワーキンググループは、測定問題スペース内の問題に対処していることに注意してください。6. IETFの範囲外にある複数の並列トランクをサポートするために行う必要があるレイヤー2つの作業があります。レイヤー3ルーティングは、OSPFのより豊富なメトリックをサポートする必要があります。7. SNMPバージョン3ワーキンググループは、認証、範囲、レートの制限に関する問題について通知する必要があります。8. Anycastで作業を計画するためにBOFを開催する必要があります。Anycastのドキュメントは、提案されているワーキンググループチャーターの一部である必要があります。
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
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
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.、Bates、T.、Gerich、E.、Karrenberg、D.、Meyer、D.、Terpsstra、M。and 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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M.、Jacobson、V.、Liu、C.、Sharma、P。and L. wei、 "Protocol Independent Multicast-Sparseモード（PIM-SM）：プロトコル仕様」、RFC 2362、1998年6月。
[5] Holbrook, H., Cheriton, D, "EXPRESS Multicast", SIGCOMM 99, September 1999.
[5] Holbrook、H.、Cheriton、D、 "Express Multicast"、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] チャーリー・カウフマン、ラディア・ペルマン、マイク・スペシナー。ネットワークセキュリティ：公共の世界でのプライベートコミュニケーション、462-465ページ。Prentice-Hall、Inc.、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] Moy、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] Nichols、K.、Blake、S.、Baker、F。and D. Black、「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.サンディックと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.、Partridge、C。and S. Deering、「距離ベクトルマルチキャストルーティングプロトコル」、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
Stephen E. Deering Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706 USA
Phone: +1 408 527-8213
EMail: deering@cisco.com
Susan Hares Merit, Inc. 1071 Beal Avenue, Ann Arbor, MI 48109 USA
Susan Hares Merit、Inc。1071 Beal Avenue、Ann Arbor、MI 48109 USA
Phone: +1 313 936-2095
EMail: skh@nexthop.com
Radia Perlman Sun Microsystems Laboratories 2 Elizabeth Drive Chelmsford, MA 01824 USA
Radia Perlman Sun Systems Laboratories 2 Elizabeth Drive Chelmsford、MA 01824 USA
Phone: +1 978 442-3252
EMail: Radia.Perlman@sun.com
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
チャールズE.パーキンスノキアリサーチセンター313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
Phone: +1 650 625-2986
EMail: Charles.Perkins@nokia.com
Fax: +1 650-625-2502
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。