RFC1754 日本語訳
1754 IP over ATM Working Group's Recommendations for the ATM Forum'sMultiprotocol BOF Version 1. M. Laubach. January 1995. (Format: TXT=13483 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Laubach Request for Comments: 1754 Com21, Inc. Category: Informational January 1995
Laubachがコメントのために要求するワーキンググループM.をネットワークでつないでください: 1754年のCom21Inc.カテゴリ: 情報の1995年1月
IP over ATM Working Group's
Recommendations for the ATM Forum's Multiprotocol BOF
Version 1
気圧フォーラムのMultiprotocol転炉バージョン1のための気圧作業部会の推薦の上のIP
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
1. Abstract
1. 要約
This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups. This RFC is issued for the benefit of community members. The information contained in this document is accurate as of the date of publication, but is subject to change. Subsequent RFCs will reflect such changes.
このドキュメントはATM作業部会と他のワーキンググループの上でIETF IPによって決定されるようにIPの操作のためにATMネットワークの上でATM ForumのMultiprotocol BOFに提出された要件の初期のリストを表します。 このRFCは共同体のメンバーの利益のために発行されます。 本書では含まれた情報は、公表の日付現在、正確ですが、変化を被りやすいです。 その後のRFCsはそのような変化を反映するでしょう。
The content of this memo was submitted by the IETF Liaison to the ATM Forum as contribution number 94-0954 in the ATM Forum's documentation process on 14 September 1994.
ATM Forumのドキュメンテーションの貢献No.94-0954が1994年9月14日に処理されるとき、このメモの中身はIETF LiaisonによってATM Forumに提出されました。
2. Notice
2. 通知
This contribution has been prepared to assist the ATM Forum. This document is offered to the Forum as a basis for discussion between the ATM Forum Multiprotocol BOF and the IETF. The statements are subject to change in form and content after further study and discussion. Specifically, the IETF reserves reserves the right to add to, amend or modify the statements contained herein.
この貢献はATM Forumを補助するように準備されました。 ATM Forum Multiprotocol BOFとIETFとの議論の基礎としてこのドキュメントをForumに提供します。 声明はさらなる研究と議論の後にフォームと内容で変化を被りやすいです。 明確に、IETF蓄えが加える権利を保有するか、修正するか、またはここに含まれた声明を変更してください。
3. Introduction
3. 序論
The following is the charter statement from the Internet Engineering Task Force's (IETF) IP over ATM Working Group (IPATM WG). It is being reproduced here for the benefit of those in the ATM Forum who may not be familiar with it:
↓これはATM作業部会(IPATM WG)の上のインターネット・エンジニアリング・タスク・フォース(IETF)のIPからの特許声明です。 ここでATM Forumのそれらの利益のためにそれになじみ深くないかもしれないのは、再生することです:
"The IP over ATM Working Group will focus on the issues involved in running internetworking protocols over Asynchronous Transfer Mode (ATM) networks. The final goal for the Working Group is to produce
「ATM作業部会の上のIPはAsynchronous Transfer Mode(ATM)ネットワークの上で走行インターネットワーキングプロトコルにかかわる問題に焦点を合わせるでしょう。」 作業部会のための究極の目標は生産することです。
Laubach [Page 1] RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995
Laubach[1ページ]RFC1754IPATM WG気圧フォーラム推薦V1 January 1995
standards for the TCP/IP protocol suite and recommendations which could be used by other internetworking protocol standards (e.g., ISO CLNP and IEEE 802.2 Bridging).
他のインターネットワーキングで使用できたTCP/IPプロトコル群と推薦の規格は規格(例えば、ISO CLNPとIEEE802.2Bridging)について議定書の中で述べます。
The Working Group will initially develop experimental protocols for encapsulation, multicasting, addressing, address resolution, call set up, and network management to allow the operation of internetwork protocols over an ATM network. The Working Group may later submit these protocols for IETF standardization.
作業部会は、初めは、ATMネットワークの上でインターネットワークプロトコルの操作を許すためにカプセル化、マルチキャスティング、アドレシング、アドレス解決、セットアップされた呼び出し、およびネットワークマネージメントのための実験プロトコルを開発するでしょう。 作業部会は後でIETF標準化のためにこれらのプロトコルを提出するかもしれません。
The Working Group will not develop physical layer standards for ATM. These are well covered in other standards groups and do not need to be addressed in this Group.
作業部会はATMの物理的な層の規格を開発しないでしょう。 これらは他の規格グループでよく覆われていて、このGroupに記述される必要はありません。
The Working Group will develop models of ATM internetworking architectures. This will be used to guide the development of specific IP over ATM protocols.
作業部会はATMインターネットワーキング構造のモデルを開発するでしょう。 これは、特定のIPの発展をATMプロトコルの上に誘導するのに使用されるでしょう。
The Working Group will also develop and maintain a list of technical unknowns that relate to internetworking over ATM. These will be used to direct future work of the Working Group or be submitted to other standards or research groups as appropriate.
また、作業部会は、ATMの上でインターネットワーキングに関連する技術的な未知のリストを開発して、維持するでしょう。 これらを作業部会の今後の活動を指示するのに使用するか、または適宜他の規格か研究グループに提出するでしょう。
The Working Group will coordinate its work with other relevant standards bodies (e.g., ANSI T1S1.5) to insure that it does not duplicate their work and that its work meshes well with other activities in this area. The Working Group will select among ATM protocol options (e.g., selection of an adaptation layer) and make recommendations to the ATM standards bodies regarding the requirements for internetworking over ATM where the current ATM standards do not meet the needs of internetworking."
作業部会は、彼らの仕事をコピーしないで、仕事がこの領域で他の活動とよく合うのを保障するために他の関連標準化団体(例えば、ANSI T1S1.5)で仕事を調整するでしょう。 「作業部会は、ATMの中でプロトコルオプション(例えば、適合層の選択)を選択して、現在のATM規格がインターネットワーキングの需要を満たさないATMの上でインターネットワーキングのための要件に関してATMへの推薦状を標準化団体にするでしょう。」
Historically, a large number of IETF IPATM WG participants are employees of companies who are principal members of the ATM Forum. Requirements between the two organizations have been communicated informally by these participants. With the establishment of the ATM Forum's Multiprotocol BOF activities, it has become prudent now to document IETF requirements in a more formal fashion.
多くのIETF IPATM WG関係者が歴史的に、ATM Forumの主要メンバーである会社の従業員です。 2つの組織の間の要件はこれらの関係者によって非公式に伝えられました。 ATM ForumのMultiprotocol BOF活動の設立によると、それは現在、より正式なファッションによるドキュメントIETF要件に慎重になりました。
At the July 1994 meeting of the IETF in Toronto, Canada, a request was presented to the IP over ATM Working Group by the ATM Forum Liaison, Drew Perkins, for the working group to prepare a list of requirements as input to the ATM Forum's Multiprotocol BOF activities. This document is a response to that request.
トロント(カナダ)でのIETFの1994年7月のミーティングでは、要求はATM作業部会の上にATM Forum LiaisonによってIPに提示されました、ドリュー・パーキンス、ATM ForumのMultiprotocol BOF活動に入力されるように要件のリストを準備するワーキンググループのために。 このドキュメントはその要求への応答です。
Laubach [Page 2] RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995
Laubach[2ページ]RFC1754IPATM WG気圧フォーラム推薦V1 January 1995
4. List of Requirements for Consideration
4. 考慮のための要件のリスト
4.1 Standardization & Logistics
4.1 標準化とロジスティクス
- Formal communications between the IETF and the ATM Forum
should be made via IETF <> ATM Forum Liaison(s), specific
written communications (such as this document), and/or
presentations made at official IETF or ATM Forum meetings.
- IETFとATM Forumとの管理的コミュニケーションはIETF<>ATM Forum Liaison(s)、特定の書かれたコミュニケーション(このドキュメントなどの)、そして/または、公式のIETFかATM Forumミーティングで作られたプレゼンテーションで作られているべきです。
- IETF standards define how the TCP/IP protocol suite is defined,
deployed, and carried over specific network technologies,
including ATM networks [1][2][8].
- IETF規格はTCP/IPプロトコル群がどう特定のネットワーク技術の上まで定義されて、配備されて、運ばれるかを定義します、ATMネットワーク[1][2][8]を含んでいて。
- Any formal communications that affect the IETF standards
or processes must be made publicly available as the IETF is
a public international standards body. Ideally, such
communications should be written as Internet Drafts [1], the
IETF's equivalent to incoming contributions.
- IETFが公共の世界規格本体であるので、公的にIETF規格か過程に影響するどんな管理的コミュニケーションも利用可能にしなければなりません。 理想的に、インターネットDrafts[1]、IETFが入って来る貢献に同等であるので、そのようなコミュニケーションは書かれているべきです。
- We invite and encourage ATM Forum members to participate in
the IETF standards process. See [1], [2], and [8] for
information on how to participate.
- 私たちは、ATM ForumメンバーがIETF標準化過程に参加するよう誘って、奨励します。 どう参加するかの情報のための[1]、[2]、および[8]を見てください。
4.2 IPv4 Encapsulation
4.2 IPv4カプセル化
- RFC 1483 [3] and RFC 1577 [4] define how IP is encapsulated
and carried over ATM networks. The IPATM WG requests that any
ATM Forum Multiprotocol work support these standards as
specified, and that any future changes to them be made via the
IETF standards process.
- RFC1483[3]とRFC1577[4]はIPがどうATMネットワークの上まで要約されて、運ばれるかを定義します。 IPATM WGは、どんなATM Forum Multiprotocol仕事も指定されるとしてこれらの規格を支持して、それらへのどんな今後の変更もIETF標準化過程で行われるよう要求します。
4.3 Routing
4.3 ルート設定
- RFC 1577 defines the default Logical IP Subnet (LIS) model.
- RFC1577はデフォルトLogical IP Subnet(LIS)モデルを定義します。
- The IETF Routing over Large Clouds Working Group is developing
the Next Hop Resolution Protocol, which allows the incremental
optimization of routing (and subnets) by routing datagrams
over preferential ATM paths [9].
- Large Clouds作業部会の上のIETFルート設定はNext Hop Resolutionプロトコルを開発しています。(それは、優先のATM経路[9]の上にルーティングデータグラムでルーティング(そして、サブネット)の増加の最適化を許容します)。
- The IETF IP over ATM Working Group will be working on the
next generation IP over ATM standards after RFC 1577 moves
from draft to proposed status. Requirements to the ATM
Forum will be forthcoming.
- RFC1577が草稿から提案された状態まで動いた後にATM作業部会の上のIETF IPはATM規格に次世代IPに勤めているでしょう。 ATM Forumへの要件は用意するでしょう。
- ATM signaling should give an indication of connection
over LAN or WAN and include feedback of time vs byte
charging.
- ATMシグナリングは、LANかWANの上に接続のしるしを与えて、バイト充電に対して時間のフィードバックを含むべきです。
Laubach [Page 3] RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995
Laubach[3ページ]RFC1754IPATM WG気圧フォーラム推薦V1 January 1995
4.4 Security
4.4 セキュリティ
- ATM signaling should support a user information element
that is used to convey security and authentication information
between IP members and applications. The IETF IPATM WG would
like to define the IP specific content of this IE.
- ATMシグナリングはIPメンバーとアプリケーションの間にセキュリティと認証情報を伝えるのに使用されるユーザー情報要素を支えるべきです。 IETF IPATM WGはこのIEのIPの特定の内容を定義したがっています。
4.5 Broadcast and Multicast
4.5 放送とマルチキャスト
- The IPATM WG is currently discussing models of how best to map
IP multicast facilities onto ATM facilities. While this work is
preliminary, the IETF does support the ATM Forum's currently
planned multicasting enhancements, such as leaf-initiated joins
and support of multiple multicast congestion management
policies. A further list of requirements will be presented at a
later time.
- IPATM WGは現在、どのようにIPマルチキャスト施設をATM施設に最もよく写像するかに関するモデルについて議論しています。 この仕事が予備である間、IETFはATM Forumの現在計画されたマルチキャスティング増進を支持して、葉で開始されるとしてのそのようなものは接合します。そして、複数のマルチキャスト混雑経営政策のサポート。 要件のさらなるリストは後で提示されるでしょう。
4.6 Signaling and Addressing
4.6 シグナリングとアドレシング
- The IPATM WG is currently producing a specification for using
UNI 3.0 and 3.1 signaling to support RFCs 1483 and 1577. This
specification will be published as an informational reference
for UNI 3.0 signaling, and as a proposed standard for UNI 3.1
signaling following UNI 3.1's ratification and official
publication.
- IPATM WGは現在、RFCs1483と1577を支持すると合図するUNI3.0と3.1を使用するための仕様を作り出しています。 この仕様はUNI3.0シグナリングの情報の参照としてUNI3.1の批准と機関紙に従って、合図するUNI3.1の提案された標準として発表されるでしょう。
- IPv6 packets will include a Flow ID field intended to support
service classes in some way. Until the semantics of this field
are fully defined it is hard to say much, but presumably a soft
mapping between this and the VC to be used is desirable. A
further list of requirements will be presented at a later time.
- IPv6パケットは何らかの方法でサービスのクラスを支持することを意図するFlow ID分野を含むでしょう。 非常に、しかし、おそらく、この分野の意味論が完全に定義されるまで、使用されるべきこれとVCの間の柔らかいマッピングが望ましいと言いにくいです。 要件のさらなるリストは後で提示されるでしょう。
- IPv6 addresses will be 16 bytes and there will likely be a
defined embedding of them inside 20-byte NSAP format. There will
also likely be a mapping of US-GOSIP-like NSAPs into IPv6
addresses (deleting the unuseful bytes), but that is still
controversial in the IPv6 discussions. A further list of
requirements will be presented at a later time.
- IPv6アドレスは16バイトになるでしょう、そして、おそらく、20バイトのNSAP形式にはそれらの定義された埋め込みがあるでしょう。 また、おそらく、IPv6アドレスには米国GOSIPのようなNSAPsに関するマッピングがあるでしょうが(unusefulバイトを削除して)、それはIPv6議論でまだ論議を呼んでいます。 要件のさらなるリストは後で提示されるでしょう。
Laubach [Page 4] RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995
Laubach[4ページ]RFC1754IPATM WG気圧フォーラム推薦V1 January 1995
4.7 Quality of Service, Performance, and Traffic Management
4.7のサービスの質、パフォーマンス、および輸送管理
- ATM should support extremely bursty applications with
significant elasticity in their bandwidth demands.
- ATMは彼らの帯域幅要求における重要な弾性で非常にburstyなアプリケーションを支持するはずです。
- ATM should support elastic applications as defined in
RFC-1633 [7] very efficiently. That means enable high
bottleneck utilization while keeping delay reasonably bounded
(i.e., doubling delay wouldn't be terrible for elastic apps).
This should not be at the expense of delay sensitive classes
of service.
- ATMはRFC-1633[7]で非常に効率的に定義されるように弾性のアプリケーションを支持するはずです。 それは、合理的に遅れを保つのがバウンドしていた間(弾性のアプリケーションには、すなわち、遅れを倍にするのはひどくないでしょう)、高いボトルネック利用を可能にすることを意味します。 これは遅れの敏感なクラスのサービスを犠牲にしているべきではありません。
- ATM should provide a a class of service which strives to
cooperate with existing TCP congestion avoidance, thereby
explicitly providing support not only for directly ATM-attached
and -aware endstations, but also for endstations on LANs (or
using LAN Emulation) that are using current TCP implementations
and interconnected via ATM-attached bridges and routers.
- ATMは既存のTCP輻輳回避に協力するように努力するサービスのaのクラスを提供するはずです、その結果、明らかに、現在のTCP実現を使用して、ATMが付属している橋を通ってインタコネクトされるLAN(LAN Emulationを使用して)とルータで直接ATMが付属していて意識しているendstationsだけではなく、endstationsについてサポートを提供します。
- Predictive QoS should be supported in addition to guaranteed QoS
to support applications which are somewhat tolerant of delay
variation and low levels of loss.
- 予言のQoSは、遅れ変化のいくらか許容性があるアプリケーションと低レベルの損失を支持するために保証されたQoSに加えて支持されるべきです。
- IP uses both point-to-point and point-to-multipoint (future)
connections. To satisfy IP's needs an ABR-like service
would need to be applicable to both types of connections [6].
- IPはポイントツーポイントとポイントツーマルチポイント(未来)接続の両方を使用します。 IPの需要を満たすために、ABRのようなサービスは、両方のタイプの接続[6]に適切である必要があるでしょう。
- No specification of minimum or maximum bandwidths by the ATM
end-systems [6].
- ATMエンドシステム[6]による最小の、または、最大の帯域幅の仕様がありません。
- As simple as possible [6].
- できるだけ簡単な[6]
- Full line-rate transmission over otherwise-idle links [6].
- そうでなければ、使用されていないリンク[6]の上の完全なライン料率送信。
- When end-to-end delay through the network is less than 1 second,
the cell loss for AAL5 frames over an ABR-like service should be
on the order of 3 in 10**8 cells for 1500 byte frames, or 3 in
10**9 cells for 18 Kbyte frames [6].
- ネットワークを通した終わりから終わりへの遅れが1秒未満であるとき、ABRのようなサービスの上のAAL5フレームのための細胞消失が1500年のバイトのフレームへの10**8セルにおける3の注文、または18個のキロバイトフレーム[6]への10**9セルの中の3にあるべきです。
5. Security Considerations
5. セキュリティ問題
Security issues raised in this memo will be addressed by the IETF IP over ATM Working Group and presented in subsequent updates to this memo.
このメモで提起された安全保障問題は、ATM作業部会の上にIETF IPによって記述されて、その後のアップデートでこのメモに提示されるでしょう。
Laubach [Page 5] RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995
Laubach[5ページ]RFC1754IPATM WG気圧フォーラム推薦V1 January 1995
6. Acknowledgement
6. 承認
The basis of this memo is a summary of comments made on the email discussion list of the IP over ATM Working Group. The contribution was reviewed by Drew Perkins and Andy Malis as a sanity check before submission to the ATM Forum.
このメモの基礎はATM作業部会の上でIPのメール議論リストでされたコメントの概要です。 貢献はATM Forumへの服従の前に健全度チェックとしてドリュー・パーキンスとアンディMalisによって見直されました。
7. References
7. 参照
[1] IETF Secretariat and G. Malkin, "The Tao of the IETF - A Guide
for New Attendees of the Internet Engineering Task Force",
FYI 17, RFC 1718, CNRI, Xylogics, Inc., November 1994.
[1] IETF事務局とG.マルキン、「IETFのタオ--Aはインターネットの新しい出席者のために工学特別委員会を誘導します」、FYI17、RFC1718、CNRI、Xylogics Inc.、1994年11月。
[2] Internet Architecture Board, and Internet Engineering Steering
Group, "The Internet Standards Process -- Revision 2", RFC 1602,
IAB, IESG, March 1994.
[2]インターネット・アーキテクチャ委員会、およびインターネット工学運営グループ、「改正2インチ、RFC1602、IAB、IESG、1994年インターネット標準化過程--3月。」
[3] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC 1483, Telecom Finland, July 1993.
[3] Heinanen、J.、「気圧適合の上のMultiprotocolカプセル化は5インチと、RFC1483、テレコムフィンランド1993年7月に層にします」。
[4] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
Hewlett-Packard Laboratories, January 1994.
[4]Laubachと、M.と、「気圧での古典的なIPとARP」、RFC1577、ヒューレット・パッカード研究所、1月1994
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, Stanford University, August 1989.
[5] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、スタンフォード大学、1989年8月。
[6] McCloghrie, K., "Lan-Emulation's Needs for Traffic Management",
ATM-Forum/94-0533, ATM Forum, June 1994.
[6]McCloghrie、K.、「ラン-エミュレーションの輸送管理の必要性」、気圧フォーラム、/94-0533、気圧フォーラム、6月1994
[7] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633,
USC/Information Sciences Institute, MIT, Xerox PARC, June 1994.
[7] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネット構造における統合サービス:」 「概観」、RFC1633、科学が設けるUSC/情報、MIT、ゼロックスPARC、1994年6月。
[8] Postel, J., Editor, "Internet Official Protocol Standards",
STD 1, RFC 1720, USC/Information Sciences Institute, July 1994.
[8] ポステル、J.、エディタ、「インターネット公式プロトコル標準」、STD1、USC/情報科学が1994年7月に設けるRFC1720。
[9] Malis, A., "Routing Over Large Clouds Liaison to the ATM Forum
Multiprotocol BOF", ATM-Forum/94-0766, ATM Forum,
September 1994.
[9]Malis、A.、「気圧フォーラムMultiprotocol転炉への大きい雲の連絡の上のルート設定」、気圧フォーラム、/94-0766、気圧フォーラム、9月1994
Laubach [Page 6] RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995
Laubach[6ページ]RFC1754IPATM WG気圧フォーラム推薦V1 January 1995
8. IETF <> ATM Forum Liaison
8. IETF<>気圧フォーラムの連絡
Drew Perkins FORE Systems, Inc. 174 Thornhill Road Warrendale, PA 15086 Phone: (412) 772-6527 Fax: (412) 772-6500 Email: ddp@fore.com
Inc.174ソーンヒルRoad Warrendale、ドリューパーキンス前面Systems PA 15086は以下に電話をします。 (412) 772-6527 Fax: (412) 772-6500 メールしてください: ddp@fore.com
9. Author's Address
9. 作者のアドレス
Mark Laubach Com21, Inc. 2113 Landings Drive Mountain View, CA 94043
Driveマウンテンビュー、マークLaubach Com21Inc.2113Landingsカリフォルニア 94043
Phone: (415) 254-5882 Fax: (415) 254-5883 EMail: laubach@com21.com
以下に電話をしてください。 (415) 254-5882 Fax: (415) 254-5883 メールしてください: laubach@com21.com
Laubach [Page 7]
Laubach[7ページ]
一覧
スポンサーリンク
