RFC2902 日本語訳
2902 Overview of the 1998 IAB Routing Workshop. S. Deering, S. Hares,C. Perkins, R. Perlman. August 2000. (Format: TXT=32773 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループS.デアリングの要求をネットワークでつないでください: 2902年のシスコシステムズカテゴリ: 情報のS.野兎はC.パーキンスノキアリサーチセンターR.パールマンサン・マイクロシステムズ研究所2000年8月にネットワークに値します。
Overview of the 1998 IAB Routing Workshop
1998IABルート設定ワークショップの概観
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
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
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 結論と宿題. . . . . . . . . . . . . . . . 3 2.1。 ユニキャストルート設定とアドレシング. . . . . . . 3 2.1.1のスケーリング。 ユニキャストルート設定--結論. . . . . . . . . . . 3 2.1.2。 ユニキャストルート設定--宿題. . . . . . . . . . 4 2.2。 アドレシングとルート設定. . . . 4 2.3のアドレシングのレベル。 Address Translation(NAT)装置. . . . . . . 5 2.3.1をネットワークでつないでください。 NAT装置--結論. . . . . . . . . . . . . 5 2.3.2。 NAT装置--動作Items. . . . . . . . . . . . 5 2.4。 マルチキャスト. . . . . . . . . . . . . . . . . . . . . . . 5 2.4.1。 マルチキャスト--結論. . . . . . . . . . . . . . 5 2.4.2。 マルチキャスト--宿題. . . . . . . . . . . . . 6 2.5。 安定性. . . . . . . . . . . . . . . . . . . 6 2.5.1を発送します。 ルート設定の安定性--結論. . . . . . . . . . 6 2.5.2。 ルート設定の安定性--宿題. . . . . . . . . 7 2.6。 ToS/CoS/QoS. . . . . . . . . . . . . . . . . . . . . . 7
Deering, et al. Informational [Page 1] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[1ページ]のRFC2902概観
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
2.6.1. ToS/CoS/QoS--宿題. . . . . . . . . . . . 8 2.7。 プロトコルセキュリティ. . . . . . . . . . . . . . . 8 2.7.1を発送します。 ルート設定セキュリティ--結論. . . . . . . . . . 8 2.7.2。 ルート設定セキュリティ--宿題. . . . . . . . . . 8 2.8。 方針. . . . . . . . . . . . . . . . . . . . 8 2.8.1を発送します。 ルート設定方針--結論. . . . . . . . . . . 8 2.8.2。 ルート設定方針--宿題. . . . . . . . . . . 9 2.9。 情報. . . . . . . . . . 9 2.9.1の流れをホストにネットワークでつないでください。 情報をホスティングしてください--結論. . . . . . . . . . 9 2.9.2。 情報をホスティングしてください--宿題. . . . . . . . . . 9 2.10。 より短い話題. . . . . . . . . . . . . . . . . . . . 9 2.10.1。 マルチストランド中継方式. . . . . . . . . . . . . . 9 2.10.2。 病気の特徴と開発ツール. . . . 10 2.10.3を発送します。 Anycast. . . . . . . . . . . . . . . . . . . . . 10 2.10.4。 Best Effort Traffic11 2.10.5のためにSensitive IGPルーティングをロードしてください。 地理的なアドレスと番号を付け替え. . . . . 11 3ること。 Actionの品目. . . . . . . . . . . . . . . . . . . 11 3.1の概要。 IAB. . . . . . . . . . . . . . . 11 3.2のための宿題。 IETFワーキンググループいす. . . . . . 11 3.3のための宿題。 IRTFルート設定調査のための宿題は.124を分類します。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 12A.関係者. . . . . . . . . . . . . . . . . . . . . . . . 12参照. . . . . . . . . . . . . . . . . . . . . . . . . . . 13作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 15の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
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.
3月25日から1998年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)
1. ユニキャストルート設定と2を記述する(セクション2.1)スケーリング。 ユニキャストアドレシングは3を発行します(セクション2.2)。 Network Address Transformation箱(セクション2.3)の4を使用するのによるインターネットの広がっているIPバージョン4のEffect。 マルチキャストルート設定(セクション2.4)
Deering, et al. Informational [Page 2] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[2ページ]のRFC2902概観
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)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。 Anycast 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つが管理実験を実行するかもしれないグローバルなInternetsの収集であることがわかるのはそれほど簡単ではありません。
2. Conclusions and Action Items
2. 結論と宿題
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共同体に提供します。
2.1. Scaling of Unicast Routing and Addressing
2.1. ユニキャストルート設定とアドレシングのスケーリング
2.1.1. Unicast Routing - Conclusions
2.1.1. ユニキャストルート設定--結論
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. 改良された実現で現在のユニキャストルーティング安定問題の大部分を修正できます。
Deering, et al. Informational [Page 3] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[3ページ]のRFC2902概観
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)
- Architected NAT(提供するために比例するほうがよくしながら、既存のNetwork Address Translation計画を改良する)--IPv6(IPバージョン6インフラストラクチャを配備します)(MAP/Encap(アドレスを「集合-可能」して、オリジナルのパケットをカプセルに入れる地図))は何(攻撃的な番号を付け替える(IPバージョン4アドレス空間の利用を改良するために番号を付け替えるよう奨励し続けていようとする))にも地下鉄アドレシングをしません。(地理的であるか首都のベースのアドレシング計画を使用します)
2.1.2. Unicast Routing - Action Items
2.1.2. ユニキャストルート設定--宿題
We recommend that the IRTF Routing Research group should encourage more analysis of routing data, not just the collection of more data.
私たちは、IRTFルート設定Researchグループが、より多くのデータの収集だけではなく、ルーティングデータの、より多くの分析を奨励するべきであることを勧めます。
2.2. Levels of Addressing of Addressing and Routing
2.2. アドレシングとルート設定のアドレシングのレベル
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つのレベルがそれはともに建てるのが難しいよりそれ以上、多くの人々と、使用に難しいです。
Deering, et al. Informational [Page 4] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[4ページ]のRFC2902概観
2.3. Network Address Translation (NAT) devices
2.3. ネットワークAddress Translation(NAT)装置
2.3.1. NAT devices - Conclusions
2.3.1. NAT装置--結論
Upon reviewing the NATs, the group
NATs、グループを批評することに関して
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に公正に配備されます。 インターネット3の中でNAT装置の使用と様々な問題を同一視しました。 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)
- NATsを排除してください--NATsを修理して、インターネットの残りと、よりよく対話してください--アプリケーションを修理して、NAT箱と、よりよく対話してください--IP Securityのようなあることをしないでください。(IPSec)
2.3.2. NAT devices - Action Items
2.3.2. NAT装置--動作Items
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の外で建築仕事に注意してください。 NATsにかかわる問題に関して心配し続けているのをIABに示してください。
2.4. Multicast
2.4. マルチキャスト
2.4.1. Multicast - Conclusions
2.4.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
- ソースの数--炸裂における、受信機--データ量--データ量の数、および静かな期間の長さ--グループの数はアプリケーションか協力するセット単位でアプリケーション、およびグループのメンバーの間の--グループが存在する時間--位相的な距離を利用しました。 - 会員資格の不安定さ
Deering, et al. Informational [Page 5] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[5ページ]のRFC2902概観
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(ランデブーPoint)、2とともに記名します。 グループのIDにコア、および有を含ませるのを接合します。コア3を指定してください。 グループのIDを持っていて、コアを含んで、有は接合します、そして、データは両方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.
グループは、信頼できるマルチキャストが驚くほどすべての可能なアプリケーションへのマルチキャストモデルのスケーリングに関する問題と直交していることに注意しました。
2.4.2. Multicast - Action Items
2.4.2. マルチキャスト--宿題
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ルート設定Research Groupに通知してください。
2.5. Routing Stability
2.5. ルート設定の安定性
2.5.1. Routing Stability - Conclusions
2.5.1. ルート設定の安定性--結論
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
しかし、ルートアップデートの効果をじめじめとするのはいくつかの接頭語のためにことによると可到達性の費用で安定を増します。 接頭語は、別の経路を通してじめじめとして届く場合があります、そのような接頭語には、湿気の効果が他の接頭語ほど重大でないように。 安定を増すための様々なアルゴリズムの性能はそうであるべきです。
Deering, et al. Informational [Page 6] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[6ページ]のRFC2902概観
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%は時間内に、どんなポイントでも影響を受けます。 私たちは、いくつの接頭語が湿気のために手が届かないかを見つけようとするべきです。
2.5.2. Routing Stability - Action Items
2.5.2. ルート設定の安定性--宿題
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ルート設定Research Groupはいろいろなことがどれくらい安定しているか、そして、安定性がそれらをより安定するようにする方法を研究するためには問題であるかどうかを測定するはずです。
2.6. ToS/CoS/QoS
2.6. ToS/CoS/QoS
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:
グループは、用語のServiceのType(ToS)、ServiceのClass(CoS)、およびServiceのQuality(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: [9] 目的地プラスToSビット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.
また、グループは大きい集められた流れで交通工学と定義された「規制はルート設定を基礎づけた」より一般的な概念について議論しました。 規制に基づいているルーティングで、プロバイダーは、ユーザからの交通要求を扱うのにそれらのネットワークの帯域幅をよりよく利用できます。 方針管理技術を可能にすること以外に、ベースのルーティングで交通の特性に基づく交通をプロバイダーを発送する規制は流れます。
Deering, et al. Informational [Page 7] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[7ページ]のRFC2902概観
2.6.1. ToS/CoS/QoS - Action Items
2.6.1. ToS/CoS/QoS--宿題
We recommend that IETF should look into the issue of Constraint Based Routing.
私たちは、IETFがConstraint Basedルート設定の問題を調べるはずであることを勧めます。
2.7. Routing Protocol Security
2.7. ルーティング・プロトコルセキュリティ
2.7.1. Routing Security - Conclusions
2.7.1. ルート設定セキュリティ--結論
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. もの(例えば、ワイヤ速度認証)を改良するために仕事の領域を特定しました。
2.7.2. Routing Security - Action Items
2.7.2. ルート設定セキュリティ--宿題
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]を奨励するはずです。
2.8. Routing Policy
2.8. ルート設定方針
2.8.1. Routing Policy - Conclusions
2.8.1. ルート設定方針--結論
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かNSPsによって要求されたいくつかのルーティング方針はBGPと共に解決できません。 トンネルと静的な構成を使用することでこれらの"「非-解決でき」"ルーティング方針のいくつかを効果に入れることができます。 2. BGPは、可到達性3を発表するためのメカニズムにすぎません。 BGPルーティングは関係なしで交通指示を交通量まで制御します。 4. BGP政策管理は、デリケート過ぎて、台無しにすることができないくらい簡単で、こわれやすいです。
Deering, et al. Informational [Page 8] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[8ページ]のRFC2902概観
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. ルータConfiguration Languageは非常に複雑で誤り傾向がある6です。 私たちが左右対称のルーティングを頼りにすることができないので、ISP/NSPs/エンタープライズネットはそれに対処するべきです。
The group concluded the Internet needed a better routing policy specification language.
グループは、インターネットが、より良いルーティング方針仕様言語を必要としたと結論づけました。
2.8.2. Routing Policy - Action Item
2.8.2. 方針--宿題を発送します。
Pass the concerns about the Routing Policy Syntax Language (RPSL) [1] to chairs of the Routing Policy Syntax (RPS) working group [11].
ルート設定Policy Syntax(RPS)ワーキンググループ[11]のいすにルート設定Policy Syntax Language(RPSL)[1]に関する心配を渡してください。
2.9. Network to Host Flow of Information
2.9. 情報の流れをホストにネットワークでつないでください。
2.9.1. Host Information - Conclusions
2.9.1. ホスト情報--結論
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.
背骨ルートに沿って交通統計の情報を発表すると、インターネットのサービスが様々なサイトから検索のためのデータを模写する方法は改良されるかもしれません。 情報の検索に、この模写はウェブで特に重要であるかもしれません。 現在、ウェブページはそれらのサイトにローカルなキャッシュに人々を差し向けます。 例えば、ヨーロッパのサイトは北米の顧客のためのイギリスの顧客と北米のサイトに使用されるかもしれません。 ユーザのウェブブラウザが自動的にローカルなキャッシュを発見できるように、ウェブキャッシュの提案者はウェブキャッシュの位置を自動構成したがっています。 他のアプリケーションは特定のサービスに関して最も良いキャッシュを見つけるこの必要性を共有します。
2.9.2. Host Information - Action Items
2.9.2. ホスト情報--宿題
The group recommends a BOF be held on Measuring Path Characteristics. Measurement of path characteristics should include:
グループは、BOFがMeasuring Path Characteristicsで持たれることを勧めます。 経路特性の測定は以下を含むべきです。
- 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]は測定問題スペースの中で問題に対処しています。
2.10. Shorter Topics
2.10. より短い話題
2.10.1. Multi-strand Trunking
2.10.1. マルチストランド中継方式
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個のリンクとして扱いますが、マルチ次元の測定基準で扱うべきです。
Deering, et al. Informational [Page 9] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[9ページ]のRFC2902概観
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.
デザインと開発事業が複数の平行なトランクスを支えるためにするべきである層twoにあります。 IETFの範囲の外にこの層twoの仕事はあります。 層threeのルーティングはOSPFでの、より豊かな測定基準をサポートするべきです。
2.10.2. Routing Diagnostic and Development Tools
2.10.2. ルート設定病気の特徴と開発ツール
2.10.2.1. Routing Diagnostics - Conclusions
2.10.2.1. ルート設定病気の特徴--結論
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. Authoritative Databaseに各ASから受入れられたそれらの接頭語を記載させてうれしいでしょう。 信頼すべきデータベースは以前、成功なしで試みられましたが、グループは、再試行するのが役に立つかもしれないと感じました。 2. SNMPバージョン3は、3を制限する改良された認証、範囲、およびレートを利用するために配備されるべきです。 離れて制御された交通モニターは、交通4を測定するのに使用されるべきです。 より良いツールが予防薬問題検出に必要です。
2.10.2.2. Routing Diagnostics - Action Items
2.10.2.2. ルート設定病気の特徴--宿題
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. 離れて制御された交通源により良いツールの基金を奨励してください、そして、問題検出を予測してください。
2.10.3. Anycast
2.10.3. Anycast
2.10.3.1. Anycast - Conclusions
2.10.3.1. Anycast--結論
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アドレスはアプリケーションの役に立ちます。
2.10.3.2. Anycast - Action Items
2.10.3.2. Anycast--宿題
A BOF should be held to plan work on anycast.
BOFは、anycastへの作業を計画するために持たれるべきです。
If a working group forms, a paper on the advantages and disadvantages of anycast should be included as part of the charter.
ワーキンググループが形成されるなら、anycastの利点と難点に関する論文は特許の一部として含まれるべきです。
Deering, et al. Informational [Page 10] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[10ページ]のRFC2902概観
2.10.4. Load Sensitive IGP routing for Best Effort Traffic
2.10.4. Best Effort TrafficのためにSensitive IGPルーティングをロードしてください。
2.10.4.1. Load Sensitive IGP - Conclusions
2.10.4.1. 負荷の敏感なIGP--結論
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.
IGPsが敏感なルーティングで、よりよく利用できる負荷はリンクされます。 負荷の敏感なルーティングにおける過去の、そして、現在の努力は: QoS OSPF[10]、Q-OSPF[10]、および負荷の敏感なルータはBBNで展開しました。
2.10.4.2. Load Sensitive IGP - Action items
2.10.4.2. 負荷Sensitive IGP--宿題
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ルート設定Researchグループいすとルート設定Areaディレクターは、この問題について議論して、Load Sensitive IGPルーティングからのどんなテクニックがIETFの準備ができるか、そして、何が追加研究を必要とするかを決心するべきです。
2.10.5. Geographical Addresses and Renumbering
2.10.5. 地理的なアドレスと番号を付け替えること
This topic was discussed, but without any conclusions or action items.
この話題は少しも議論しますが、結論や宿題なしでありました。
3. Summary of Action items
3. Actionの品目の概要
3.1. Action Items for the IAB
3.1. IABのための宿題
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はNATs2にかかわる問題に関して心配するべきです。 正式のDatabase(ドメインの中のアドレスのための)はインターネット3の中で奨励されるべきです。 離れて制御された交通源により良いツールの基金を奨励してください、そして、問題検出を予測してください。
3.2. Action Items for IETF Working Group Chairs
3.2. IETFワーキンググループいすのための宿題
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がConstraint Basedルート設定の問題を扱うはずであることを勧めます。 3. IETFは「ワイヤ速度」認証、ルーティング・プロトコルにおける、ルータの対状認証、およびルーティング・プロトコルにおける込み入った丈夫さに対する仕事を奨励するはずです。
Deering, et al. Informational [Page 11] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[11ページ]のRFC2902概観
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. ルート設定Policy Specification Language(RPSL)に関する心配はルート設定Policy Systems(RPS)ワーキンググループいすのものになるべきです。 5. グループは、BOFがMeasuring Path Characteristicsで持たれることを勧めます。 BOFは、データ交換が測定とメカニズムの形式であるとデータの分配メカニズムと考えるはずです。 IPPMワーキンググループが測定問題スペースの中で問題に対処していることに注意されます。 6. IETFの範囲の外にある複数の平行なトランクスを支えるためにするべきである層twoの仕事があります。 層threeのルーティングはOSPFでの、より豊かな測定基準をサポートするべきです。 7. SNMPバージョン3ワーキンググループは認証、範囲、およびレート制限に関する問題に関して通知されるべきです。 8. BOFは、anycastへの作業を計画するために持たれるべきです。 anycastの上のドキュメントは提案されたワーキンググループ特許の一部であるべきです。
3.3. Action Items for the IRTF Routing Research Group
3.3. IRTFルート設定研究グループのための宿題
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ルート設定Researchワーキンググループが、より多くのデータの収集だけではなく、ルーティングデータの、より多くの分析を奨励しようとすることを勧めます。
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ルート設定Researchグループいすとルート設定Areaディレクターは、Load Sensitive IGPルーティングについて議論して、それがIETFの準備ができているかどうかと決心するべきです。
4. Security Considerations
4. セキュリティ問題
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.)
(ミーティング日付現在Eメールアドレス。)
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@corp.home.net ブライアン・Carpenter brian@hursley.ibm.com Noel Chiappa jnc@ginger.lcs.mit.edu ロブ・Coltun rcoltun@fore.com スティーブ・デアリング deering@cisco.com デボラEstrin estrin@usc.edu
Deering, et al. Informational [Page 12] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[12ページ]のRFC2902概観
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 トニー李 tli@juniper.net ピーターLothberg roll@stupi.se ルイス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パールマン Radia.Perlman@East.Sun.COM ヤコフRekhter yakov@cisco.com アリンRomanow allyn@MCI.NET マーサステーンストルプ msteenst@bbn.com ジョージ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.)は和らげます、T.、Gerich、E.、Karrenberg、D.、マイヤー、テルプストラ、M.、およびC.Villamizar、D.、「方針仕様言語(RPSL)を発送し」て、RFC2280、1998年1月。
[2] Ballardie, A., "Core Based Trees (CBT) Multicast Routing
Architecture", RFC 2201, September 1997.
[2]Ballardie、A.、「コアのベースの木(CBT)のマルチキャストルート設定構造」、RFC2201、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.ウィス、「微分されたサービスのための構造」、RFC2475、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)を議定書の中で述べてください」 「プロトコル仕様」、RFC2362、1998年6月。
[5] Holbrook, H., Cheriton, D, "EXPRESS Multicast", SIGCOMM 99,
September 1999.
[5] ホルブルック、H.、Cheriton、D、「急行マルチキャスト」、SIGCOMM99、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] チャーリー・カウフマン、Radiaパールマン、およびマイクSpeciner。 セキュリティをネットワークでつないでください: Public World、462-- 465ページの個人的なCommunication。 新米のホールのInc.、1995。
Deering, et al. Informational [Page 13] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[13ページ]のRFC2902概観
[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パフォーマンスMetrics(IPPM)、10月1997日の http://www.ietf.org/html.charters/ippm- charter.html。
[8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[8]Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、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分野)の定義」RFC2474(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(いす)。 Policy Syntax(RPS)、7月1995日の 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.デアリング、「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」、RFC1075、1988年11月。
Deering, et al. Informational [Page 14] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[14ページ]のRFC2902概観
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
西タスマン・DriveスティーブンE.デアリングシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)
Phone: +1 408 527-8213 EMail: deering@cisco.com
以下に電話をしてください。 +1 408 527-8213 メールしてください: deering@cisco.com
Susan Hares Merit, Inc. 1071 Beal Avenue, Ann Arbor, MI 48109 USA
スーザンHaresは, Inc.1071ビールAvenue、アナーバー、MI48109米国に値します。
Phone: +1 313 936-2095 EMail: skh@nexthop.com
以下に電話をしてください。 +1 313 936-2095 メールしてください: skh@nexthop.com
Radia Perlman Sun Microsystems Laboratories 2 Elizabeth Drive Chelmsford, MA 01824 USA
Radiaパールマンサン・マイクロシステムズ研究所2エリザベス・Drive MA01824チェルムズフォード(米国)
Phone: +1 978 442-3252 EMail: Radia.Perlman@sun.com
以下に電話をしてください。 +1 978 442-3252 メールしてください: Radia.Perlman@sun.com
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
チャールズE.パーキンスノキアリサーチセンター313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650 625-2986 EMail: Charles.Perkins@nokia.com Fax: +1 650-625-2502
以下に電話をしてください。 +1 650 625-2986 メールしてください: Charles.Perkins@nokia.com Fax: +1 650-625-2502
Deering, et al. Informational [Page 15] RFC 2902 Overview of the 1998 IAB Routing Workshop August 2000
デアリング、他 ワークショップ2000年8月に掘る1998IABの情報[15ページ]のRFC2902概観
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Deering, et al. Informational [Page 16]
デアリング、他 情報[16ページ]
一覧
スポンサーリンク
