RFC4202 日本語訳
4202 Routing Extensions in Support of Generalized Multi-Protocol LabelSwitching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2005. (Format: TXT=57333 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Kompella, Ed.
Request for Comments: 4202 Y. Rekhter, Ed.
Category: Standards Track Juniper Networks
October 2005
ワーキンググループK.Kompella、エドをネットワークでつないでください。コメントのために以下を要求してください。 エド4202Y.Rekhter、カテゴリ: 規格は2005年10月に杜松ネットワークを追跡します。
Routing Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)
一般化されたマルチプロトコルラベルスイッチングを支持したルート設定拡大(GMPLS)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE).
Generalized Multi-プロトコルLabel Switching(GMPLS)のためのリンク州の情報を運ぶことを支持してこのドキュメントはルーティング拡大を指定します。 このドキュメントは拡張子がMPLS Traffic Engineering(TE)を支持するのを必要としたルーティングを高めます。
Kompella & Rekhter Standards Track [Page 1] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[1ページ]。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements for Layer-Specific TE Attributes . . . . . 4
1.2. Excluding Data Traffic from Control Channels. . . . . . 6
2. GMPLS Routing Enhancements. . . . . . . . . . . . . . . . . . 7
2.1. Support for Unnumbered Links. . . . . . . . . . . . . . 7
2.2. Link Protection Type. . . . . . . . . . . . . . . . . . 7
2.3. Shared Risk Link Group Information. . . . . . . . . . . 9
2.4. Interface Switching Capability Descriptor . . . . . . . 9
2.4.1. Layer-2 Switch Capable. . . . . . . . . . . . . 11
2.4.2. Packet-Switch Capable . . . . . . . . . . . . . 11
2.4.3. Time-Division Multiplex Capable . . . . . . . . 12
2.4.4. Lambda-Switch Capable . . . . . . . . . . . . . 13
2.4.5. Fiber-Switch Capable. . . . . . . . . . . . . . 13
2.4.6. Multiple Switching Capabilities per Interface . 13
2.4.7. Interface Switching Capabilities and Labels . . 14
2.4.8. Other Issues. . . . . . . . . . . . . . . . . . 14
2.5. Bandwidth Encoding. . . . . . . . . . . . . . . . . . . 15
3. Examples of Interface Switching Capability Descriptor . . . . 15
3.1. STM-16 POS Interface on a LSR . . . . . . . . . . . . . 15
3.2. GigE Packet Interface on a LSR. . . . . . . . . . . . . 15
3.3. STM-64 SDH Interface on a Digital Cross Connect with
Standard SDH. . . . . . . . . . . . . . . . . . . . . . 15
3.4. STM-64 SDH Interface on a Digital Cross Connect with
Two Types of SDH Multiplexing Hierarchy Supported . . . 16
3.5. Interface on an Opaque OXC (SDH Framed) with Support
for One Lambda per Port/Interface . . . . . . . . . . . 16
3.6. Interface on a Transparent OXC (PXC) with External
DWDM that understands SDH framing . . . . . . . . . . . 17
3.7. Interface on a Transparent OXC (PXC) with External
DWDM That Is Transparent to Bit-Rate and Framing. . . . 17
3.8. Interface on a PXC with No External DWDM. . . . . . . . 18
3.9. Interface on a OXC with Internal DWDM That Understands
SDH Framing . . . . . . . . . . . . . . . . . . . . . . 18
3.10. Interface on a OXC with Internal DWDM That Is
Transparent to Bit-Rate and Framing . . . . . . . . . . 19
4. Example of Interfaces That Support Multiple Switching
Capabilities. . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Interface on a PXC+TDM Device with External DWDM. . . . 20
4.2. Interface on an Opaque OXC+TDM Device with External
DWDM. . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Interface on a PXC+LSR Device with External DWDM. . . . 21
4.4. Interface on a TDM+LSR Device . . . . . . . . . . . . . 21
5. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 層の特有のTe属性. . . . . 4 1.2のための要件。 制御チャンネルにデータ通信量を入れないようにします。 . . . . . 6 2. GMPLSルート設定増進。 . . . . . . . . . . . . . . . . . 7 2.1. 無数のリンクに支持します。 . . . . . . . . . . . . . 7 2.2. 保護タイプをリンクしてください。 . . . . . . . . . . . . . . . . . 7 2.3. 共有されたリスクリンクグループ情報。 . . . . . . . . . . 9 2.4. スイッチング能力記述子. . . . . . . 9 2.4.1を連結してください。 できる層-2スイッチ。 . . . . . . . . . . . . 11 2.4.2. パケット交換機できる. . . . . . . . . . . . . 11 2.4.3。 時分割多重できる. . . . . . . . 12 2.4.4。 できる.132.4に.5をλで切り換えてください。 ファイバースイッチできます。 . . . . . . . . . . . . . 13 2.4.6. 複数のインタフェース. 13 2.4.7あたりのスイッチング能力。 .8にスイッチング能力とラベル. . 14 2.4を連結してください。 他の問題。 . . . . . . . . . . . . . . . . . 14 2.5. 帯域幅コード化。 . . . . . . . . . . . . . . . . . . 15 3. インタフェーススイッチング能力記述子. . . . 15 3.1に関する例。 STM-16 POSはLSR. . . . . . . . . . . . . 15 3.2に連結します。 LSRの上のGigEパケットインタフェース。 . . . . . . . . . . . . 15 3.3. デジタル十字のSTM-64 SDHインタフェースは標準のSDHに接続します。 . . . . . . . . . . . . . . . . . . . . . 15 3.4. デジタル十字のSTM-64 SDHインタフェースは.163.5にサポートされる2つのタイプのSDHマルチプレクシング階層構造に接続します。 ポート/インタフェース.163.6あたりの1つのλのサポートで不透明なOXC(縁どられたSDH)に連結してください。 SDHが.173.7を縁どるのを理解しているExternal DWDMと共にTransparent OXC(PXC)に連結してください。 ビット伝送速度と縁どりに透明な外部のDWDMと共に透明なOXC(PXC)に連結してください。 . . . 17 3.8. 外部のDWDMなしでPXCに連結してください。 . . . . . . . 18 3.9. SDH縁ど. . . . . . . . . . . . . . . . . . . . . . 18 3.10りを理解している内部のDWDMと共にOXCに連結してください。 ビット伝送速度と縁ど. . . . . . . . . . 19 4りに透明な内部のDWDMと共にOXCに連結してください。 複数のスイッチング能力を支持するインタフェースに関する例。 . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. 外部のDWDMと共にPXC+TDM装置に接続してください。 . . . 20 4.2. 外部のDWDMと共に不透明なOXC+TDM装置に接続してください。 . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3. 外部のDWDMと共にPXC+LSR装置に接続してください。 . . . 21 4.4. TDM+LSR装置. . . . . . . . . . . . . 21 5に接続してください。 承認。 . . . . . . . . . . . . . . . . . . . . . . 22 6. セキュリティ問題. . . . . . . . . . . . . . . . . . . 22
Kompella & Rekhter Standards Track [Page 2] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[2ページ]。
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References. . . . . . . . . . . . . . . . . . 23
7.2. Informative References. . . . . . . . . . . . . . . . . 24
8. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 24
7. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.1. 引用規格。 . . . . . . . . . . . . . . . . . 23 7.2. 有益な参照。 . . . . . . . . . . . . . . . . 24 8. 貢献者。 . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
1. 序論
This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions [ISIS-TE], [OSPF-TE] required to support MPLS Traffic Engineering (TE).
Generalized Multi-プロトコルLabel Switching(GMPLS)のためのリンク州の情報を運ぶことを支持してこのドキュメントはルーティング拡大を指定します。 このドキュメントはルーティング拡大[イシス-TE]を高めて、[OSPF-TE]がMPLS Traffic Engineering(TE)を支持するのが必要です。
Traditionally, a TE link is advertised as an adjunct to a "regular" link, i.e., a routing adjacency is brought up on the link, and when the link is up, both the properties of the link are used for Shortest Path First (SPF) computations (basically, the SPF metric) and the TE properties of the link are then advertised.
伝統的に、付属物として「通常」のリンクにTEリンクの広告を出して、リンクの上にすなわち、ルーティング隣接番組を持って来て、リンクが上がっているときShortest Path First(SPF)計算にリンクの両方の特性を使用する、(基本的にSPF、メートル法、)、そして、リンクのTEの特性の広告を出します。
GMPLS challenges this notion in three ways. First, links that are not capable of sending and receiving on a packet-by-packet basis may yet have TE properties; however, a routing adjacency cannot be brought up on such links. Second, a Label Switched Path can be advertised as a point-to-point TE link (see [LSP-HIER]); thus, an advertised TE link may be between a pair of nodes that don't have a routing adjacency with each other. Finally, a number of links may be advertised as a single TE link (perhaps for improved scalability), so again, there is no longer a one-to-one association of a regular routing adjacency and a TE link.
GMPLSは3つの方法でこの概念に挑戦します。 まず最初に、パケットごとのベースで送受信ができないリンクには、やがて、TEの特性があるかもしれません。 しかしながら、そのようなリンクの上にルーティング隣接番組を持って来ることができません。 2番目に、二地点間TEリンクとしてLabel Switched Pathの広告を出すことができます([LSP-HIER]を見てください)。 したがって、互いがあるルーティング隣接番組を持っていない1組のノードの間には、広告を出しているTEリンクがあるかもしれません。 最終的に、単一のTEリンク(恐らく改良されたスケーラビリティのための)として多くのリンクの広告を出すかもしれないので、一方、通常のルーティング隣接番組とTEリンクの1〜1つの協会がもうありません。
Thus we have a more general notion of a TE link. A TE link is a "logical" link that has TE properties. The link is logical in a sense that it represents a way to group/map the information about certain physical resources (and their properties) into the information that is used by Constrained SPF for the purpose of path computation, and by GMPLS signaling. This grouping/mapping must be done consistently at both ends of the link. LMP [LMP] could be used to check/verify this consistency.
したがって、私たちはTEの、より一般的な概念をリンクさせます。 TEリンクはTEの特性がある「論理的な」リンクです。 リンクはある意味で論理的です。それはある物理資源(そして、彼らの特性)の情報を目的に経路計算、およびGMPLSシグナリングによってConstrained SPFによって使用される情報に分類するか、または写像する方法を表します。 リンクの両端で一貫してこの組分け/マッピングをしなければなりません。 この一貫性についてチェックするか、または確かめるのに、LMP[LMP]を使用できました。
Depending on the nature of resources that form a particular TE link, for the purpose of GMPLS signaling, in some cases the combination of <TE link identifier, label> is sufficient to unambiguously identify the appropriate resource used by an LSP. In other cases, the combination of <TE link identifier, label> is not sufficient; such cases are handled by using the link bundling construct [LINK-BUNDLE] that allows to identify the resource by <TE link identifier, Component link identifier, label>.
GMPLSがいくつかの場合で<TEリンク識別子の組み合わせに合図する目的のために特定のTEリンクを形成するリソースの本質によって、ラベル>は、明白にLSPによって使用された適切なリソースを特定するために十分です。 他のケース、<TEリンク識別子の組み合わせでは、ラベル>は十分ではありません。 そのような場合は<TEリンク識別子でリソースを特定するその構造物[LINK-BUNDLE]を束ねながらリンクを使用することによって、扱われます、Componentリンク識別子、ラベル>。
Kompella & Rekhter Standards Track [Page 3] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[3ページ]。
Some of the properties of a TE link may be configured on the advertising Label Switching Router (LSR), others which may be obtained from other LSRs by means of some protocol, and yet others which may be deduced from the component(s) of the TE link.
TEリンクのいくつかの特性が広告Label Switching Router(LSR)にもかかわらず、何らかのプロトコルによって他のLSRsから得られるかもしれない他のものにもかかわらず、TEリンクの部品から推論されるかもしれない他のものの上で構成されるかもしれません。
A TE link between a pair of LSRs doesn't imply the existence of a routing adjacency (e.g., an IGP adjacency) between these LSRs. As we mentioned above, in certain cases a TE link between a pair of LSRs could be advertised even if there is no routing adjacency at all between the LSRs (e.g., when the TE link is a Forwarding Adjacency (see [LSP-HIER])).
1組のLSRsの間のTEリンクはこれらのLSRsの間のルーティング隣接番組(例えば、IGP隣接番組)の存在を含意しません。 ある場合には、私たちが上に言及したように、LSRsの間には、ルーティング隣接番組が全くもなければ(例えば、いつTEリンクはForwarding Adjacency([LSP-HIER]を見る)ですか)、1組のLSRsの間のTEリンクの広告を出すかもしれません。
A TE link must have some means by which the advertising LSR can know of its liveness (this means may be routing hellos, but is not limited to routing hellos). When an LSR knows that a TE link is up, and can determine the TE link's TE properties, the LSR may then advertise that link to its (regular) neighbors.
TEリンクには、広告LSRが活性を知ることができるいくつかの手段がなければなりません(この手段は、ルーティングhellosであるかもしれませんが、ルーティングhellosに制限されません)。 LSRがTEリンクが上がっているのを知って、TEリンクのTEの特性を決定できるなら、LSRは(通常)の隣人へのそのリンクの広告を出すかもしれません。
In this document, we call the interfaces over which regular routing adjacencies are established "control channels".
本書では、私たちは通常のルーティング隣接番組が確立される「コントロールはチャネルを開設する」インタフェースを呼びます。
[ISIS-TE] and [OSPF-TE] define the canonical TE properties, and say how to associate TE properties to regular (packet-switched) links. This document extends the set of TE properties, and also says how to associate TE properties with non-packet-switched links such as links between Optical Cross-Connects (OXCs). [LSP-HIER] says how to associate TE properties with links formed by Label Switched Paths.
[イシス-TE]と[OSPF-TE]は、正準なTEの特性を定義して、通常(パケットで切り換えられた)のリンクにTEの特性を関連づける方法を言います。 このドキュメントは、TEの特性のセットを広げていて、また、非パケットが切り替わったのがあるTEの特性がリンクなどのようにリンクする仲間に、(OXCs)がどうOptical Cross接しているかを書きます。 [LSP-HIER]はLabel Switched Pathsによって形成されるリンクにTEの特性を関連づける方法を言います。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
1.1. Requirements for Layer-Specific TE Attributes
1.1. 層の特有のTe属性のための要件
In generalizing TE links to include traditional transport facilities, there are additional factors that influence what information is needed about the TE link. These arise from existing transport layer architecture (e.g., ITU-T Recommendations G.805 and G.806) and associated layer services. Some of these factors are:
伝統的な運送設備を含むようにTEリンクを一般化するのにおいて、情報がTEリンクに関して必要であるものであるのに影響を及ぼす追加要素があります。 これらは既存のトランスポート層構造(例えば、ITUの-T Recommendations G.805とG.806)と関連層のサービスから起こります。 これらの要素のいくつかは以下の通りです。
1. The need for LSPs at a specific adaptation, not just a particular
bandwidth. Clients of optical networks obtain connection services
for specific adaptations, for example, a VC-3 circuit. This not
only implies a particular bandwidth, but how the payload is
structured. Thus the VC-3 client would not be satisfied with any
LSP that offered other than 48.384 Mbit/s and with the expected
1. 特定の帯域幅だけではなく、特定の適合におけるLSPsの必要性。 光学ネットワークのクライアントは特定の適合、例えば、VC-3サーキットに接続サービスを得ます。 これはペイロードが特定の帯域幅だけではなく、どう構造化もされるかも含意します。 したがって、VC-3クライアントは48.384以外に、メガビット/sを提供したどんなLSPと予想にも満足しないでしょう。
Kompella & Rekhter Standards Track [Page 4] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[4ページ]。
structure. The corollary is that path computation should be able
to find a route that would give a connection at a specific
adaptation.
構造。 推論は経路計算が特定の適合のときに接続に与えるルートを見つけることができるべきであるということです。
2. Distinguishing variable adaptation. A resource between two OXCs
(specifically a G.805 trail) can sometimes support different
adaptations at the same time. An example of this is described in
section 2.4.8. In this situation, the fact that two adaptations
are supported on the same trail is important because the two
layers are dependent, and it is important to be able to reflect
this layer relationship in routing, especially in view of the
relative lack of flexibility of transport layers compared to
packet layers.
2. 可変適合を区別します。 2OXCs(明確にG.805道)の間のリソースは同時に、時々異なった適合を支持できます。 この例はセクション2.4.8で説明されます。 この状況で、2つの層が依存しているので、2つの適合が同じ道で支持されるという事実は重要であり、この層の関係をルーティングに反映できるのは重要です、特にパケット層にたとえられたトランスポート層の相対的な柔軟性の欠如から見て。
3. Inheritable attributes. When a whole multiplexing hierarchy is
supported by a TE link, a lower layer attribute may be applicable
to the upper layers. Protection attributes are a good example of
this. If an OC-192 link is 1+1 protected (a duplicate OC-192
exists for protection), then an STS-3c within that OC-192 (a
higher layer) would inherit the same protection property.
3. 相続可能な属性。 全体のマルチプレクシング階層構造がTEリンクによってサポートされるとき、下層属性は上側の層に適切であるかもしれません。 保護属性はこの好例です。 OC-192リンクが+1が保護した1(写しOC-192は保護のために存在している)であるなら、そのOC-192(より高い層)の中のSTS-3cは同じ保護の特性を引き継ぐでしょう。
4. Extensibility of layers. In addition to the existing defined
transport layers, new layers and adaptation relationships could
come into existence in the future.
4. 層の伸展性。 既存の定義されたトランスポート層に加えて、新しい層と適合関係は将来、生まれるかもしれません。
5. Heterogeneous networks whose OXCs do not all support the same set
of layers. In a GMPLS network, not all transport layer network
elements are expected to support the same layers. For example,
there may be switches capable of only VC-11, VC-12, and VC-3, and
there may be others that can only support VC-3 and VC-4. Even
though a network element cannot support a specific layer, it
should be able to know if a network element elsewhere in the
network can support an adaptation that would enable that
unsupported layer to be used. For example, a VC-11 switch could
use a VC-3 capable switch if it knew that a VC-11 path could be
constructed over a VC-3 link connection.
5. OXCsがすべてをするというわけではない異機種ネットワークは同じセットの層を支えます。 GMPLSネットワークでは、すべてのトランスポート層ネットワーク要素が同じ層を支えることが期待されるというわけではありません。 例えば、VC-11だけができるスイッチ、VC-12、およびVC-3があるかもしれません、そして、VC-3とVC-4を支持できるだけである他のものがいるかもしれません。 ネットワーク要素は特定の層を支えることができませんが、それは、ネットワークにおけるほかの場所のネットワーク要素がそのサポートされない層が使用されるのを可能にする適合を支持できるかどうかを知ることができるべきです。 例えば、VC-3リンク結合の上でVC-11経路を構成できたのを知っているなら、VC-11スイッチはVC-3のできるスイッチを使用するかもしれないでしょうに。
From the factors presented above, development of layer specific GMPLS routing documents should use the following principles for TE-link attributes.
上に提示された要素から、特定のGMPLSルーティングが記録する層の開発はTE-リンク属性に以下の原則を使用するべきです。
1. Separation of attributes. The attributes in a given layer are
separated from attributes in another layer.
1. 属性の分離。 与えられた層の属性は別の層の属性と切り離されます。
2. Support of inter-layer attributes (e.g., adaptation
relationships). Between a client and server layer, a general
mechanism for describing the layer relationship exists. For
2. 相互層の属性(例えば、適合関係)のサポート。 クライアントとサーバ層の間では、層の関係について説明するための一般的機構は存在しています。 for
Kompella & Rekhter Standards Track [Page 5] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[5ページ]。
example, "4 client links of type X can be supported by this server
layer link". Another example is being able to identify when two
layers share a common server layer.
例、「タイプXの4個のクライアントリンクによる支持されて、このサーバ層がリンクされるということであることができます」。 別の例は、2つの層がいつ一般的なサーバ層を共有するかを特定できます。
3. Support for inheritable attributes. Attributes which can be
inherited should be identified.
3. 相続可能な属性のために、支持します。 引き継ぐことができる属性は特定されるべきです。
4. Layer extensibility. Attributes should be represented in routing
such that future layers can be accommodated. This is much like
the notion of the generalized label.
4. 伸展性を層にしてください。 属性は、将来の層を設備することができるようにルーティングで表されるべきです。 これは一般化されたラベルの概念に似ています。
5. Explicit attribute scope. For example, it should be clear whether
a given attribute applies to a set of links at the same layer.
5. 明白な属性範囲。 例えば、与えられた属性が同じ層の1セットのリンクに適用されるかどうかが、明確であるはずです。
The present document captures general attributes that apply to a single layer network, but doesn't capture inter-layer relationships of attributes. This work is left to a future document.
現在のドキュメントは、単一層ネットワークに適用される一般属性を得ますが、属性の相互層の関係は得ません。 この仕事は将来のドキュメントに残されます。
1.2. Excluding Data Traffic from Control Channels
1.2. 制御チャンネルにデータ通信量を入れないようにします。
The control channels between nodes in a GMPLS network, such as OXCs, SDH cross-connects and/or routers, are generally meant for control and administrative traffic. These control channels are advertised into routing as normal links as mentioned in the previous section; this allows the routing of (for example) RSVP messages and telnet sessions. However, if routers on the edge of the optical domain attempt to forward data traffic over these channels, the channel capacity will quickly be exhausted.
一般に、OXCsなどのGMPLSネットワークにおけるノードの間の制御チャンネル(SDH十字接続、そして/または、ルータ)は、コントロールと管理交通に意味されます。 標準が前項で言及されるようにリンクされるとき、これらの制御チャンネルのルーティングに広告を出します。 これはRSVPメッセージと(例えば、)telnetセッションのルーティングを許します。 しかしながら、光学ドメインの縁のルータが、これらのチャンネルの上にデータ通信量を送るのを試みると、チャネル容量はすばやく消耗するでしょう。
In order to keep these control channels from being advertised into the user data plane a variety of techniques can be used.
これらの制御チャンネルが利用者データ飛行機に広告を出すのを妨げるために、さまざまなテクニックを使用できます。
If one assumes that data traffic is sent to BGP destinations, and control traffic to IGP destinations, then one can exclude data traffic from the control plane by restricting BGP nexthop resolution. (It is assumed that OXCs are not BGP speakers.) Suppose that a router R is attempting to install a route to a BGP destination D. R looks up the BGP nexthop for D in its IGP's routing table. Say R finds that the path to the nexthop is over interface I. R then checks if it has an entry in its Link State database associated with the interface I. If it does, and the link is not packet-switch capable (see [LSP-HIER]), R installs a discard route for destination D. Otherwise, R installs (as usual) a route for destination D with nexthop I. Note that R need only do this check if it has packet- switch incapable links; if all of its links are packet-switch capable, then clearly this check is redundant.
人が、データ通信量がBGPの目的地、およびIGPの目的地へのコントロール交通に送られると仮定するなら、1つは、BGP nexthop解決を制限することによって、制御飛行機にデータ通信量を入れないようにすることができます。 (OXCsがBGPスピーカーでないと思われます。) ルータRが、D.RがIGPの経路指定テーブルでDのためのBGP nexthopとして見るBGPの目的地にルートをインストールするのを試みていると仮定してください。 次にRがチェックするインタフェースI.の上にnexthopへの経路がそれにはそれがするインタフェースI.Ifに関連しているLink州データベースにおけるエントリーがあって、リンクができるパケット交換機([LSP-HIER]を見る)でないならある言いたい事R掘り出し物、破棄が目的地D.Otherwiseに発送するRインストール、パケットがそれで不可能なリンクを切り換えるなら、RはRがこのチェックをするだけでよいnexthop I.Noteと共に目的地Dにルートをインストールします(いつものように)。 リンクのすべてができるパケット交換機であるなら、明確に、このチェックは余分です。
Kompella & Rekhter Standards Track [Page 6] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[6ページ]。
In other instances it may be desirable to keep the whole address space of a GMPLS routing plane disjoint from the endpoint addresses in another portion of the GMPLS network. For example, the addresses of a carrier network where the carrier uses GMPLS but does not wish to expose the internals of the addressing or topology. In such a network the control channels are never advertised into the end data network. In this instance, independent mechanisms are used to advertise the data addresses over the carrier network.
GMPLSルーティング飛行機の全体のアドレス空間であることを保つのが望ましいかもしれない他の例では、GMPLSネットワークの別の一部の終点アドレスから、ばらばらになってください。 例えば、キャリヤーがGMPLSを使用しますが、アドレシングかトポロジーのインターナルを露出したがっていないキャリヤーネットワークのアドレス。 そのようなネットワークでは、決してエンドデータ網に制御チャンネルの広告を出しません。 この場合、独立しているメカニズムは、キャリヤーネットワークの上にデータ・アドレスの広告を出すのに使用されます。
Other techniques for excluding data traffic from control channels may also be needed.
また、制御チャンネルにデータ通信量を入れないようにするための他のテクニックが必要であるかもしれません。
2. GMPLS Routing Enhancements
2. GMPLSルート設定増進
In this section we define the enhancements to the TE properties of GMPLS TE links. Encoding of this information in IS-IS is specified in [GMPLS-ISIS]. Encoding of this information in OSPF is specified in [GMPLS-OSPF].
このセクションで、私たちはGMPLS TEリンクのTEの特性と増進を定義します。 中のこの情報のコード化、-、[GMPLS-イシス]では、指定されます。 OSPFでのこの情報のコード化は[GMPLS-OSPF]で指定されます。
2.1. Support for Unnumbered Links
2.1. 無数のリンクのサポート
An unnumbered link has to be a point-to-point link. An LSR at each end of an unnumbered link assigns an identifier to that link. This identifier is a non-zero 32-bit number that is unique within the scope of the LSR that assigns it.
無数のリンクはポイントツーポイント接続でなければなりません。 無数のリンクの各端のLSRはそのリンクに識別子を割り当てます。 この識別子はそれを割り当てるLSRの範囲の中でユニークな非ゼロ32ビットの番号です。
Consider an (unnumbered) link between LSRs A and B. LSR A chooses an idenfitier for that link. So does LSR B. From A's perspective we refer to the identifier that A assigned to the link as the "link local identifier" (or just "local identifier"), and to the identifier that B assigned to the link as the "link remote identifier" (or just "remote identifier"). Likewise, from B's perspective the identifier that B assigned to the link is the local identifier, and the identifier that A assigned to the link is the remote identifier.
LSRs AとB. LSR Aとの(無数)のリンクがそのリンクへのidenfitierを選ぶと考えてください。 したがって、Aが「リンクのローカルの識別子」としてリンクに割り当てた識別子(または、まさしく「ローカルの識別子」)と、そして、識別子に「リンクのリモート識別子」(または、まさしく「リモート識別子」)としてリンクに割り当てられたそのBを私たちが参照するLSR B.From Aの見解にします。 同様に、Bがリンクに割り当てた識別子はビーズ見解からの、ローカルの識別子です、そして、Aがリンクに割り当てた識別子はリモート識別子です。
Support for unnumbered links in routing includes carrying information about the identifiers of that link. Specifically, when an LSR advertises an unnumbered TE link, the advertisement carries both the local and the remote identifiers of the link. If the LSR doesn't know the remote identifier of that link, the LSR should use a value of 0 as the remote identifier.
ルーティングによる無数のリンクのサポートは、そのリンクの識別子の情報を運ぶのを含んでいます。 LSRが無数のTEリンクの広告を出すとき、明確に、広告は地方とリンクのリモート識別子の両方を載せます。 LSRがそのリンクのリモート識別子を知らないなら、LSRはリモート識別子として0の値を使用するはずです。
2.2. Link Protection Type
2.2. リンク保護タイプ
The Link Protection Type represents the protection capability that exists for a link. It is desirable to carry this information so that it may be used by the path computation algorithm to set up LSPs with appropriate protection characteristics. This information is
Link Protection Typeはリンクに存在する保護能力を表します。 この情報を運ぶのは、適切な保護の特性があるLSPsをセットアップするのに経路計算アルゴリズムでそれを使用できるくらい望ましいです。 この情報はそうです。
Kompella & Rekhter Standards Track [Page 7] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[7ページ]。
organized in a hierarchy where typically the minimum acceptable protection is specified at path instantiation and a path selection technique is used to find a path that satisfies at least the minimum acceptable protection. Protection schemes are presented in order from lowest to highest protection.
通常、最小の許容できる保護が経路具体化で指定されて、経路選択のテクニックが少なくとも最小の許容できる保護を満たす経路を見つけるのに使用される階層構造では、組織化されています。 保護計画は最も低い保護から最も高い保護まで整然とした状態で提示されます。
This document defines the following protection capabilities:
このドキュメントは以下の保護能力を定義します:
Extra Traffic
If the link is of type Extra Traffic, it means that the link is
protecting another link or links. The LSPs on a link of this type
will be lost if any of the links it is protecting fail.
余分なTraffic If、タイプExtra Trafficにはリンクがあって、それは、リンクが別のリンクかリンクを保護していることを意味します。 それが保護しているリンクのどれかが失敗すると、このタイプのリンクの上のLSPsはなくされるでしょう。
Unprotected
If the link is of type Unprotected, it means that there is no
other link protecting this link. The LSPs on a link of this type
will be lost if the link fails.
保護のないIf、タイプUnprotectedにはリンクがあって、それは、このリンクを保護する他のリンクが全くないことを意味します。 リンクが失敗すると、このタイプのリンクの上のLSPsはなくされるでしょう。
Shared
If the link is of type Shared, it means that there are one or more
disjoint links of type Extra Traffic that are protecting this
link. These Extra Traffic links are shared between one or more
links of type Shared.
Ifが共有した、タイプSharedにはリンクがあるか、1つがあることを意味するか、または以上はこのリンクを保護しているタイプExtra Trafficのリンクをばらばらにならせます。 これらのExtra TrafficリンクはタイプSharedの1個以上のリンクの間で共有されます。
Dedicated 1:1
If the link is of type Dedicated 1:1, it means that there is one
dedicated disjoint link of type Extra Traffic that is protecting
this link.
Dedicated1:1をタイプしてください、そして、それは、捧げられたのがあることを意味します。専用1:1If、リンクがある、このリンクを保護しているタイプExtra Trafficのリンクをばらばらにならせてください。
Dedicated 1+1
If the link is of type Dedicated 1+1, it means that a dedicated
disjoint link is protecting this link. However, the protecting
link is not advertised in the link state database and is therefore
not available for the routing of LSPs.
それは、捧げられたaがリンクをばらばらにならせることを意味します。専用1+1If、タイプDedicatedにはリンクがある、1、+1、このリンクを保護しています。 しかしながら、保護リンクは、リンク州のデータベースに広告を出さないで、またしたがって、LSPsのルーティングに利用可能ではありません。
Enhanced
If the link is of type Enhanced, it means that a protection scheme
that is more reliable than Dedicated 1+1, e.g., 4 fiber
BLSR/MS-SPRING, is being used to protect this link.
Ifを高める、タイプEnhancedにはリンクがあって、そのDedicatedより信頼できるa保護計画を意味する、1、+1、例えば、4ファイバーSPRING BLSR/さん、このリンクを保護するのにおいて中古の存在はそうです。
The Link Protection Type is optional, and if a Link State
Advertisement doesn't carry this information, then the Link
Protection Type is unknown.
Link Protection Typeは任意です、そして、Link州Advertisementがこの情報を運ばないなら、Link Protection Typeは未知です。
Kompella & Rekhter Standards Track [Page 8] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[8ページ]。
2.3. Shared Risk Link Group Information
2.3. 共有されたリスクリンクグループ情報
A set of links may constitute a 'shared risk link group' (SRLG) if they share a resource whose failure may affect all links in the set. For example, two fibers in the same conduit would be in the same SRLG. A link may belong to multiple SRLGs. Thus the SRLG Information describes a list of SRLGs that the link belongs to. An SRLG is identified by a 32 bit number that is unique within an IGP domain. The SRLG Information is an unordered list of SRLGs that the link belongs to.
失敗がセットにおけるすべてのリンクに影響するかもしれないリソースを共有するなら、1セットのリンクは'共有されたリスクリンク群'(SRLG)を構成するかもしれません。 例えば、同じ導管の2つのファイバーが同じSRLGにあるでしょう。 リンクは複数のSRLGsに属すかもしれません。 したがって、SRLG情報はリンクが属すSRLGsのリストについて説明します。 SRLGは32ビットのIGPドメインの中でユニークな数によって特定されます。 SRLG情報はリンクが属すSRLGsの順不同のリストです。
The SRLG of a LSP is the union of the SRLGs of the links in the LSP. The SRLG of a bundled link is the union of the SRLGs of all the component links.
LSPのSRLGはLSPのリンクのSRLGsの組合です。 束ねられたリンクのSRLGはすべてのコンポーネントリンクのSRLGsの組合です。
If an LSR is required to have multiple diversely routed LSPs to another LSR, the path computation should attempt to route the paths so that they do not have any links in common, and such that the path SRLGs are disjoint.
LSRが複数のさまざまに発送されたLSPsを別のLSRに持つのに必要であるなら、経路計算が、経路を発送するのを試みるべきであるので、どんなリンクも共通ではありません、そして、経路SRLGsがそうであるようにものはばらばらになります。
The SRLG Information may start with a configured value, in which case it does not change over time, unless reconfigured.
SRLG情報は構成された値から始まるかもしれません、その場合、再構成されない場合、それが時間がたつにつれて、変化しません。
The SRLG Information is optional and if a Link State Advertisement doesn't carry the SRLG Information, then it means that SRLG of that link is unknown.
SRLG情報は任意です、そして、Link州AdvertisementがSRLG情報を運ばないなら、それはそのリンクのSRLGが未知であることを意味します。
2.4. Interface Switching Capability Descriptor
2.4. インタフェーススイッチング能力記述子
In the context of this document we say that a link is connected to a node by an interface. In the context of GMPLS interfaces may have different switching capabilities. For example an interface that connects a given link to a node may not be able to switch individual packets, but it may be able to switch channels within an SDH payload. Interfaces at each end of a link need not have the same switching capabilities. Interfaces on the same node need not have the same switching capabilities.
このドキュメントの文脈では、私たちは、リンクがインタフェースによってノードに接続されると言います。 GMPLSの文脈では、インタフェースは異なったスイッチング能力を持っているかもしれません。 例えば、ノードへの与えられたリンクを接続するインタフェースは個々のパケットを切り換えることができないかもしれませんが、それはSDHペイロードの中にチャンネルを切り換えることができるかもしれません。 リンクの各端のインタフェースには、同じスイッチング能力がある必要はありません。 同じノードの上のインタフェースには、同じスイッチング能力がある必要はありません。
The Interface Switching Capability Descriptor describes switching capability of an interface. For bi-directional links, the switching capabilities of an interface are defined to be the same in either direction. I.e., for data entering the node through that interface and for data leaving the node through that interface.
Interface Switching Capability Descriptorはインタフェースのスイッチング能力について説明します。 双方向のリンクに関しては、インタフェースのスイッチング能力は、どちらかの方向と同じになるように定義されます。 すなわち、それを通してノードを残して、そのインタフェースとデータのためのノードを入力するデータに関しては、連結してください。
A Link State Advertisement of a link carries the Interface Switching Capability Descriptor(s) only of the near end (the end incumbent on the LSR originating the advertisement).
リンクのLink州Advertisementは近い終わり(広告を溯源するLSRの上の終わりの現職)だけのInterface Switching Capability Descriptor(s)を運びます。
Kompella & Rekhter Standards Track [Page 9] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[9ページ]。
An LSR performing path computation uses the Link State Database to determine whether a link is unidirectional or bidirectional.
経路計算を実行するLSRは、リンクが単方向かそれとも双方向であるかを決定するのにLink州Databaseを使用します。
For a bidirectional link the LSR uses its Link State Database to determine the Interface Switching Capability Descriptor(s) of the far-end of the link, as bidirectional links with different Interface Switching Capabilities at its two ends are allowed.
双方向のリンクに関しては、LSRはリンクの遠端のInterface Switching Capability Descriptor(s)を決定するのにLink州Databaseを使用します、2つの終わりの異なったInterface Switching Capabilitiesとの双方向のリンクが許容されているとき。
For a unidirectional link it is assumed that the Interface Switching Capability Descriptor at the far-end of the link is the same as at the near-end. Thus, an unidirectional link is required to have the same interface switching capabilities at both ends. This seems a reasonable assumption given that unidirectional links arise only with packet forwarding adjacencies and for these both ends belong to the same level of the PSC hierarchy.
単方向のリンクに関しては、リンクの遠端におけるInterface Switching Capability Descriptorが近い終わりと同じであると思われます。 したがって、単方向のリンクが、両端に同じインタフェーススイッチング能力を持つのに必要です。 単方向のリンクが単にパケット推進隣接番組で起こって、これらの両端のためにPSC階層構造の同じレベルに属すなら、これは妥当な想定に見えます。
This document defines the following Interface Switching Capabilities:
このドキュメントは以下のInterface Switching Capabilitiesを定義します:
Packet-Switch Capable-1 (PSC-1)
Packet-Switch Capable-2 (PSC-2)
Packet-Switch Capable-3 (PSC-3)
Packet-Switch Capable-4 (PSC-4)
Layer-2 Switch Capable (L2SC)
Time-Division-Multiplex Capable (TDM)
Lambda-Switch Capable (LSC)
Fiber-Switch Capable (FSC)
できるできるできるできる1つ(PSC-1)のパケット交換機パケット交換機できる2(PSC-2)パケット交換機できる3(PSC-3)パケット交換機できる4(PSC-4)層-2の(TDM)λスイッチできる(LSC)ファイバースイッチ(L2SC)時分割多重スイッチ(FSC)
If there is no Interface Switching Capability Descriptor for an interface, the interface is assumed to be packet-switch capable (PSC-1).
インタフェースへのInterface Switching Capability Descriptorが全くなければ、インタフェースはパケット交換機のできる(PSC-1)であると思われます。
Interface Switching Capability Descriptors present a new constraint for LSP path computation.
インタフェースSwitching Capability DescriptorsはLSP経路計算の新しい規制を提示します。
Irrespective of a particular Interface Switching Capability, the Interface Switching Capability Descriptor always includes information about the encoding supported by an interface. The defined encodings are the same as LSP Encoding as defined in [GMPLS-SIG].
特定のInterface Switching Capabilityにおいて関係ありません、Interface Switching Capability Descriptorはいつもインタフェースによって支持されたコード化の情報を含んでいます。 定義されたencodingsは[GMPLS-SIG]で定義されるLSP Encodingと同じです。
An interface may have more than one Interface Switching Capability Descriptor. This is used to handle interfaces that support multiple switching capabilities, for interfaces that have Max LSP Bandwidth values that differ by priority level, and for interfaces that support discrete bandwidths.
インタフェースには、1Interface Switching Capability Descriptorがあるかもしれません。 これは複数のスイッチング能力を支持するインタフェースを扱うのに使用されます、優先権レベル、および離散的な帯域幅を支持するインタフェースに異なるマックスLSP Bandwidth値を持っているインタフェースに。
Depending on a particular Interface Switching Capability, the Interface Switching Capability Descriptor may include additional information, as specified below.
特定のInterface Switching Capabilityによって、Interface Switching Capability Descriptorは以下で指定されるとして追加情報を含むかもしれません。
Kompella & Rekhter Standards Track [Page 10] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[10ページ]。
2.4.1. Layer-2 Switch Capable
2.4.1. できる層-2スイッチ
If an interface is of type L2SC, it means that the node receiving data over this interface can switch the received frames based on the layer 2 address. For example, an interface associated with a link terminating on an ATM switch would be considered L2SC.
タイプL2SCにインタフェースがあるなら、それは、このインタフェースの上にデータを受け取るノードが2が記述する層に基づく容認されたフレームを切り換えることができることを意味します。 例えば、ATMスイッチで終わるリンクに関連しているインタフェースはL2SCであると考えられるでしょう。
2.4.2. Packet-Switch Capable
2.4.2. できるパケット交換機
If an interface is of type PSC-1 through PSC-4, it means that the node receiving data over this interface can switch the received data on a packet-by-packet basis, based on the label carried in the "shim" header [RFC3032]. The various levels of PSC establish a hierarchy of LSPs tunneled within LSPs.
PSC-4を通してタイプPSC-1にインタフェースがあるなら、このインタフェースの上にデータを受け取るノードがパケットごとのベースに関する受信データを切り換えることができることを意味します、「詰め物」ヘッダー[RFC3032]で運ばれたラベルに基づいて。 PSCの様々なレベルはLSPsの中でトンネルを堀られたLSPsの階層構造を確立します。
For Packet-Switch Capable interfaces the additional information includes Maximum LSP Bandwidth, Minimum LSP Bandwidth, and interface MTU.
Packet-スイッチCapableインタフェースに関しては、追加情報はMaximum LSP Bandwidth、Minimum LSP Bandwidth、およびインタフェースMTUを含んでいます。
For a simple (unbundled) link, the Maximum LSP Bandwidth at priority p is defined to be the smaller of the unreserved bandwidth at priority p and a "Maximum LSP Size" parameter which is locally configured on the link, and whose default value is equal to the Max Link Bandwidth. Maximum LSP Bandwidth for a bundled link is defined in [LINK-BUNDLE].
簡単な(「非-束ね」られる)リンクに関しては、優先権pにおけるMaximum LSP Bandwidthは、優先権pとリンクの上に局所的に構成されて、デフォルト値がマックスLink Bandwidthと等しい「最大のLSPサイズ」パラメタで無遠慮な帯域幅で、より小さくなるように定義されます。 束ねられたリンクへの最大のLSP Bandwidthは[LINK-BUNDLE]で定義されます。
The Maximum LSP Bandwidth takes the place of the Maximum Link Bandwidth ([ISIS-TE], [OSPF-TE]). However, while Maximum Link Bandwidth is a single fixed value (usually simply the link capacity), Maximum LSP Bandwidth is carried per priority, and may vary as LSPs are set up and torn down.
[OSPF-TE)、Maximum LSP BandwidthはMaximum Link Bandwidth[イシス-TE]の代理をします。 しかしながら、Maximum Link Bandwidthはただ一つの一定の価値(通常単にリンク容量)ですが、Maximum LSP Bandwidthは優先権単位で運ばれて、LSPsをセットアップして、取りこわすのに従って、異なるかもしれません。
Although Maximum Link Bandwidth is to be deprecated, for backward compatibility, one MAY set the Maximum Link Bandwidth to the Maximum LSP Bandwidth at priority 7.
Maximum Link Bandwidthはある5月に後方の互換性のために非難されることになっていますが、優先権7でMaximum LSP BandwidthにMaximum Link Bandwidthを設定してください。
The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP could reserve.
Minimum LSP BandwidthはLSPが控えることができた最小の帯域幅を指定します。
Typical values for the Minimum LSP Bandwidth and for the Maximum LSP Bandwidth are enumerated in [GMPLS-SIG].
Minimum LSP BandwidthとMaximum LSP Bandwidthのための典型的な値は[GMPLS-SIG]で列挙されます。
On a PSC interface that supports Standard SDH encoding, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy, with the leaf and the root of the branch being defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p.
Standard SDHコード化を支持するPSCインタフェースでは、優先権pにおけるLSPはSDH階層構造の部門によって許容されたどんな帯域幅も控えることができました、ブランチの葉と根が優先権pでMinimum LSP BandwidthとMaximum LSP Bandwidthによって定義されている状態で。
Kompella & Rekhter Standards Track [Page 11] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[11ページ]。
On a PSC interface that supports Arbitrary SDH encoding, an LSP at priority p could reserve any bandwidth between the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p, provided that the bandwidth reserved by the LSP is a multiple of the Minimum LSP Bandwidth.
Arbitrary SDHコード化を支持するPSCインタフェースでは、優先権pにおけるLSPは優先権pでMinimum LSP BandwidthとMaximum LSP Bandwidthの間のどんな帯域幅も控えることができました、LSPによって控えられた帯域幅がMinimum LSP Bandwidthの倍数であれば。
The Interface MTU is the maximum size of a packet that can be transmitted on this interface without being fragmented.
Interface MTUはこのインタフェースで断片化されないで伝えることができるパケットの最大サイズです。
2.4.3. Time-Division Multiplex Capable
2.4.3. できる時分割多重
If an interface is of type TDM, it means that the node receiving data over this interface can multiplex or demultiplex channels within an SDH payload.
タイプTDMにインタフェースがあるなら、それは、このインタフェースの上にデータを受け取るノードが多重送信できるか、または「反-マルチプレックス」がSDHペイロードの中に精神を集中することを意味します。
For Time-Division Multiplex Capable interfaces the additional information includes Maximum LSP Bandwidth, the information on whether the interface supports Standard or Arbitrary SDH, and Minimum LSP Bandwidth.
Time-事業部Multiplex Capableインタフェースに関しては、追加情報はMaximum LSP BandwidthかインタフェースがStandardを支持するかどうかの情報かArbitrary SDHと、Minimum LSP Bandwidthを含んでいます。
For a simple (unbundled) link the Maximum LSP Bandwidth at priority p is defined as the maximum bandwidth an LSP at priority p could reserve. Maximum LSP Bandwidth for a bundled link is defined in [LINK-BUNDLE].
簡単な(「非-束ね」られる)リンクに関しては、優先権pにおけるMaximum LSP Bandwidthは優先権pにおけるLSPが控えることができた最大の帯域幅と定義されます。 束ねられたリンクへの最大のLSP Bandwidthは[LINK-BUNDLE]で定義されます。
The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP could reserve.
Minimum LSP BandwidthはLSPが控えることができた最小の帯域幅を指定します。
Typical values for the Minimum LSP Bandwidth and for the Maximum LSP Bandwidth are enumerated in [GMPLS-SIG].
Minimum LSP BandwidthとMaximum LSP Bandwidthのための典型的な値は[GMPLS-SIG]で列挙されます。
On an interface having Standard SDH multiplexing, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy, with the leaf and the root of the branch being defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p.
Standard SDHが多重送信するインタフェースでは、優先権pにおけるLSPはSDH階層構造の部門によって許容されたどんな帯域幅も控えることができました、ブランチの葉と根が優先権pでMinimum LSP BandwidthとMaximum LSP Bandwidthによって定義されている状態で。
On an interface having Arbitrary SDH multiplexing, an LSP at priority p could reserve any bandwidth between the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p, provided that the bandwidth reserved by the LSP is a multiple of the Minimum LSP Bandwidth.
Arbitrary SDHが多重送信するインタフェースでは、優先権pにおけるLSPは優先権pでMinimum LSP BandwidthとMaximum LSP Bandwidthの間のどんな帯域幅も控えることができました、LSPによって控えられた帯域幅がMinimum LSP Bandwidthの倍数であれば。
Interface Switching Capability Descriptor for the interfaces that support sub VC-3 may include additional information. The nature and the encoding of such information is outside the scope of this document.
潜水艦VC-3をサポートするインタフェースへのインタフェースSwitching Capability Descriptorは追加情報を含むかもしれません。 このドキュメントの範囲の外にそのような情報の自然とコード化があります。
Kompella & Rekhter Standards Track [Page 12] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[12ページ]。
A way to handle the case where an interface supports multiple branches of the SDH multiplexing hierarchy, multiple Interface Switching Capability Descriptors would be advertised, one per branch. For example, if an interface supports VC-11 and VC-12 (which are not part of same branch of SDH multiplexing tree), then it could advertise two descriptors, one for each one.
インタフェースがSDHマルチプレクシング階層構造の複数の部門を支えるケースを扱う方法、複数のInterface Switching Capability Descriptorsの広告を出すでしょう、1ブランチあたり1つ。 例えば、インタフェースがVC-11とVC-12(SDHマルチプレクシング木の同じ枝の一部でない)をサポートするなら、それは2つの記述子(それぞれのためのもの)の広告を出すかもしれません。
2.4.4. Lambda-Switch Capable
2.4.4. できるλスイッチ
If an interface is of type LSC, it means that the node receiving data over this interface can recognize and switch individual lambdas within the interface. An interface that allows only one lambda per interface, and switches just that lambda is of type LSC.
タイプLSCにインタフェースがあるなら、それは、このインタフェースの上にデータを受け取るノードがインタフェースの中で個々のλを認識して、切り換えることができることを意味します。 タイプLSCにはインタフェース、およびスイッチあたり1λだけにまさしくそのλを許容するインタフェースがあります。
The additional information includes Reservable Bandwidth per priority, which specifies the bandwidth of an LSP that could be supported by the interface at a given priority number.
追加情報は1優先権あたりのReservable Bandwidthを含んでいます。(優先権は与えられた優先順位番号でインタフェースでサポートすることができたLSPの帯域幅を指定します)。
A way to handle the case of multiple data rates or multiple encodings within a single TE Link, multiple Interface Switching Capability Descriptors would be advertised, one per supported data rate and encoding combination. For example, an LSC interface could support the establishment of LSC LSPs at both STM-16 and STM-64 data rates.
独身のTE Linkの中の複数のデータ信号速度か複数のencodingsに関するケースを扱う方法、複数のInterface Switching Capability Descriptorsの広告を出すでしょう、データ信号速度であることがサポートされて、組み合わせをコード化するのあたり1つ。 例えば、LSCインタフェースはSTM-16とSTM-64データ信号速度の両方でLSC LSPsの設立をサポートするかもしれません。
2.4.5. Fiber-Switch Capable
2.4.5. できるファイバースイッチ
If an interface is of type FSC, it means that the node receiving data over this interface can switch the entire contents to another interface (without distinguishing lambdas, channels or packets). I.e., an interface of type FSC switches at the granularity of an entire interface, and can not extract individual lambdas within the interface. An interface of type FSC can not restrict itself to just one lambda.
タイプFSCにインタフェースがあるなら、それは、このインタフェースの上にデータを受け取るノードが別のインタフェース(λ、チャンネルまたはパケットを区別することのない)に全体のコンテンツを切り換えることができることを意味します。 すなわち、タイプFSCのインタフェースは、全体のインタフェースの粒状で切り替わって、インタフェースの中で個々のλを抜粋できません。 タイプFSCのインタフェースはそれ自体をちょうど1λに制限しない場合があります。
2.4.6. Multiple Switching Capabilities per Interface
2.4.6. 複数の1インタフェースあたりのスイッチング能力
An interface that connects a link to an LSR may support not one, but several Interface Switching Capabilities. For example, consider a fiber link carrying a set of lambdas that terminates on an LSR interface that could either cross-connect one of these lambdas to some other outgoing optical channel, or could terminate the lambda, and extract (demultiplex) data from that lambda using TDM, and then cross-connect these TDM channels to some outgoing TDM channels. To support this a Link State Advertisement may carry a list of Interface Switching Capabilities Descriptors.
LSRへのリンクを接続するインタフェースは1ではなく、数個のInterface Switching Capabilitiesをサポートするかもしれません。 例えば、十字接続人が、そうすることができたLSRインタフェースで終わるλのファイバーリンクキャリングaセットであると考える、ある他の辞職している光学チャンネルへのこれらのλ、TDMを使用して、次にこれらのTDMが向ける十字接続を使用するそのλから辞職している何人かのTDMチャンネルまでλを終えて、データを抜粋できました(反多重送信します)。 これがLink州AdvertisementであるとサポートするのがInterface Switching Capabilities Descriptorsのリストを運ぶかもしれません。
Kompella & Rekhter Standards Track [Page 13] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[13ページ]。
2.4.7. Interface Switching Capabilities and Labels
2.4.7. インタフェーススイッチング能力とラベル
Depicting a TE link as a tuple that contains Interface Switching Capabilities at both ends of the link, some examples links may be:
リンクの両端にInterface Switching Capabilitiesを含むtupleとしてTEリンクについて表現して、いくつかの例のリンクは以下の通りです。
[PSC, PSC] - a link between two packet LSRs
[TDM, TDM] - a link between two Digital Cross Connects
[LSC, LSC] - a link between two OXCs
[PSC, TDM] - a link between a packet LSR and Digital Cross Connect
[PSC, LSC] - a link between a packet LSR and an OXC
[TDM, LSC] - a link between a Digital Cross Connect and an OXC
[PSC、PSC]--2パケットLSRs[TDM、TDM]の間のリンク--2Digital Cross Connects[LSC、LSC]の間のリンク--2OXCs[PSC、TDM]の間のリンク--パケットLSRとDigital Cross Connect[PSC、LSC]とのリンク--パケットLSRとOXC[TDM、LSC]とのリンク--Digital Cross ConnectとOXCとのリンク
Both ends of a given TE link has to use the same way of carrying label information over that link. Carrying label information on a given TE link depends on the Interface Switching Capability at both ends of the link, and is determined as follows:
与えられたTEリンクの両端はそのリンクの上までラベル情報を運ぶ同じ方法を使用しなければなりません。 与えられたTEリンクのラベル情報を運ぶのは、リンクの両端のInterface Switching Capabilityによって、以下の通り決定しています:
[PSC, PSC] - label is carried in the "shim" header [RFC3032]
[TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
[LSC, LSC] - label represents a lambda
[FSC, FSC] - label represents a port on an OXC
[PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
[PSC, LSC] - label represents a lambda
[PSC, FSC] - label represents a port
[TDM, LSC] - label represents a lambda
[TDM, FSC] - label represents a port
[LSC, FSC] - label represents a port
[PSC、PSC]--ラベルは「詰め物」ヘッダー[RFC3032][TDM、TDM]で運ばれます--ラベルはTDMの時間帯[GMPLS Sonet SDH][LSC、LSC]を表します--ラベルはλ[FSC、FSC]を表します--ラベルはOXC[PSC、TDM]の上のポートを表します--ラベルはTDMの時間帯[GMPLS Sonet SDH][PSC、LSC]を表します--ラベルはλ[PSC、FSC]を表します--ラベルはポート[TDM、LSC]を表します--ラベルはλ[TDM、FSC]を表します--ラベルはポート[LSC、FSC]を表します--ラベルはポートを表します。
2.4.8. Other Issues
2.4.8. 他の問題
It is possible that Interface Switching Capability Descriptor will change over time, reflecting the allocation/deallocation of LSPs. For example, assume that VC-3, VC-4, VC-4-4c, VC-4-16c and VC-4-64c LSPs can be established on a STM-64 interface whose Encoding Type is SDH. Thus, initially in the Interface Switching Capability Descriptor the Minimum LSP Bandwidth is set to VC-3, and Maximum LSP Bandwidth is set to STM-64 for all priorities. As soon as an LSP of VC-3 size at priority 1 is established on the interface, it is no longer capable of VC-4-64c for all but LSPs at priority 0. Therefore, the node advertises a modified Interface Switching Capability Descriptor indicating that the Maximum LSP Bandwidth is no longer STM-64, but STM-16 for all but priority 0 (at priority 0 the Maximum LSP Bandwidth is still STM-64). If subsequently there is another VC-3 LSP, there is no change in the Interface Switching Capability Descriptor. The Descriptor remains the same until the node can no longer establish a VC-4-16c LSP over the interface (which
LSPsの配分/反配分を反映するとInterface Switching Capability Descriptorが時間がたつにつれて変化するのは、可能です。 例えば、Encoding TypeがSDHであるSTM-64インタフェースにVC-3、VC-4、VC-4-4c、VC-4-16c、およびVC-4-64c LSPsを設立できると仮定してください。 このようにして、そして、初めは、Interface Switching Capability Descriptorでは、Minimum LSP BandwidthはVC-3に用意ができています、そして、Maximum LSP BandwidthはすべてのプライオリティのためのSTM-64に用意ができています。 優先権1におけるVC-3サイズのLSPがインタフェースに設立されるとすぐに、LSPs以外のすべてにおいて、それはもう優先権0がVC-4-64cができません。 したがって、ノードは優先権0以外のすべてのためにMaximum LSP BandwidthがもうSTM-64ではなく、STM-16であることを示す変更されたInterface Switching Capability Descriptorの広告を出します(優先権0では、それでも、Maximum LSP BandwidthはSTM-64です)。 別のVC-3 LSPが次にあれば、Interface Switching Capability Descriptorにおける変化が全くありません。 ノードがもうインタフェースの上にVC-4-16c LSPを設立できないまでDescriptorが同じままで残っている、(どれ
Kompella & Rekhter Standards Track [Page 14] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[14ページ]。
means that at this point more than 144 time slots are taken by LSPs on the interface). Once this happened, the Descriptor is modified again, and the modified Descriptor is advertised to other nodes.
手段、ここに、144以上の時間帯がインタフェースのLSPsによって取られます) これがいったん起こると、再びDescriptorを変更します、そして、他のノードに変更されたDescriptorの広告を出します。
2.5. Bandwidth Encoding
2.5. 帯域幅コード化
Encoding in IEEE floating point format [IEEE] of the discrete values that could be used to identify Unreserved bandwidth, Maximum LSP bandwidth and Minimum LSP bandwidth is described in Section 3.1.2 of [GMPLS-SIG].
IEEEでは、Unreserved帯域幅、Maximum LSP帯域幅を特定するのにおいて中古、そして、Minimum LSP帯域幅がセクション3.1.2で説明されるということであるかもしれない[GMPLS-SIG]の離散的な値の浮動小数点形式[IEEE]をコード化します。
3. Examples of Interface Switching Capability Descriptor
3. インタフェーススイッチング能力記述子に関する例
3.1. STM-16 POS Interface on a LSR
3.1. STM-16 POSはLSRに連結します。
Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1
Encoding = SDH
Max LSP Bandwidth[p] = 2.5 Gbps, for all p
スイッチング能力記述子を連結してください: SDHマックスインタフェースSwitching Capability=PSC-1 Encoding=LSP Bandwidth[p]はすべてのpのために2.5Gbpsと等しいです。
If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used.
1TEがリンクするとき両端のそのようなインタフェースとの複数のリンクが広告に掲載されることになっているなら、リンクバンドリングのテクニックは使用されるでしょうに。
3.2. GigE Packet Interface on a LSR
3.2. LSRの上のGigEパケットインタフェース
Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1
Encoding = Ethernet 802.3
Max LSP Bandwidth[p] = 1.0 Gbps, for all p
スイッチング能力記述子を連結してください: イーサネット802.3マックスインタフェースSwitching Capability=PSC-1 Encoding=LSP Bandwidth[p]はすべてのpのために1.0Gbpsと等しいです。
If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used.
1TEがリンクするとき両端のそのようなインタフェースとの複数のリンクが広告に掲載されることになっているなら、リンクバンドリングのテクニックは使用されるでしょうに。
3.3. STM-64 SDH Interface on a Digital Cross Connect with Standard SDH
3.3. デジタル十字のSTM-64 SDHインタフェースは標準のSDHに接続します。
Consider a branch of SDH multiplexing tree : VC-3, VC-4, VC-4-4c, VC-4-16c, VC-4-64c. If it is possible to establish all these connections on a STM-64 interface, the Interface Switching Capability Descriptor of that interface can be advertised as follows:
SDHマルチプレクシング木の枝を考えてください: VC-3、VC-4、VC-4-4c、VC-4-16c、VC-4-64c。 STM-64インタフェースでこれらのすべての接続を確立するのが可能であるなら、以下の通りそのインタフェースのInterface Switching Capability Descriptorの広告を出すことができます:
Interface Switching Capability Descriptor:
Interface Switching Capability = TDM [Standard SDH]
Encoding = SDH
Min LSP Bandwidth = VC-3
Max LSP Bandwidth[p] = STM-64, for all p
スイッチング能力記述子を連結してください: インタフェースSwitching CapabilityはVC-3マックス=SDH Min LSP Bandwidth=LSP Bandwidth[p]=STM-64をコード化しながら、TDM[標準のSDH]と等しいです、すべてのpのために
If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used.
1TEがリンクするとき両端のそのようなインタフェースとの複数のリンクが広告に掲載されることになっているなら、リンクバンドリングのテクニックは使用されるでしょうに。
Kompella & Rekhter Standards Track [Page 15] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[15ページ]。
3.4. STM-64 SDH Interface on a Digital Cross Connect with Two Types of
SDH Multiplexing Hierarchy Supported
3.4. デジタル十字のSTM-64 SDHインタフェースはサポートされる2つのタイプのSDHマルチプレクシング階層構造に接続します。
Interface Switching Capability Descriptor 1:
Interface Switching Capability = TDM [Standard SDH]
Encoding = SDH
Min LSP Bandwidth = VC-3
Max LSP Bandwidth[p] = STM-64, for all p
スイッチング能力記述子1を連結してください: インタフェースSwitching CapabilityはVC-3マックス=SDH Min LSP Bandwidth=LSP Bandwidth[p]=STM-64をコード化しながら、TDM[標準のSDH]と等しいです、すべてのpのために
Interface Switching Capability Descriptor 2:
Interface Switching Capability = TDM [Arbitrary SDH]
Encoding = SDH
Min LSP Bandwidth = VC-4
Max LSP Bandwidth[p] = STM-64, for all p
スイッチング能力記述子2を連結してください: インタフェースSwitching CapabilityはVC-4マックス=SDH Min LSP Bandwidth=LSP Bandwidth[p]=STM-64をコード化しながら、TDM[任意のSDH]と等しいです、すべてのpのために
If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used.
1TEがリンクするとき両端のそのようなインタフェースとの複数のリンクが広告に掲載されることになっているなら、リンクバンドリングのテクニックは使用されるでしょうに。
3.5. Interface on an Opaque OXC (SDH Framed) with Support for One
Lambda per Port/Interface
3.5. ポート/インタフェースあたりの1つのλのサポートで不透明なOXC(縁どられたSDH)に連結してください。
An "opaque OXC" is considered operationally an OXC, as the whole lambda (carrying the SDH line) is switched transparently without further multiplexing/demultiplexing, and either none of the SDH overhead bytes, or at least the important ones are not changed.
「不透明なOXC」は操作上考えられます。OXC、全体のλとして、(SDH系列を運びます)は透過的にさらなるマルチプレクシング/逆多重化なしで切り換えられます、そして、いずれのSDHオーバーヘッドバイトのどれかも少なくとも重要なもののどちらかも変えられません。
An interface on an opaque OXC handles a single wavelength, and cannot switch multiple wavelengths as a whole. Thus, an interface on an opaque OXC is always LSC, and not FSC, irrespective of whether there is DWDM external to it.
不透明なOXCの上のインタフェースは、ただ一つの波長を扱って、全体で複数の波長を切り換えることができません。 したがって、いつも不透明なOXCの上のインタフェースはFSCではなく、LSCです、それへの外部のDWDMがあるかどうかの如何にかかわらず。
Note that if there is external DWDM, then the framing understood by the DWDM must be same as that understood by the OXC.
それがOXCで理解していたように外部のDWDMがあればDWDMに解釈された縁どりが同じであるに違いないことに注意してください。
A TE link is a group of one or more interfaces on an OXC. All interfaces on a given OXC are required to have identifiers unique to that OXC, and these identifiers are used as labels (see 3.2.1.1 of [GMPLS-SIG]).
TEリンクはOXCの上の1つ以上のインタフェースのグループです。 見てください。与えられたOXCの上のすべてのインタフェースが識別子をそのOXCにユニークにするのに必要であり、これらの識別子がラベルとして使用される、(3.2 .1 .1 [GMPLS-SIG)について。
The following is an example of an interface switching capability descriptor on an SDH framed opaque OXC:
以下によるSDHに関するインタフェーススイッチング能力記述子に関する例が不透明なOXCを縁どったということです:
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = SDH
Reservable Bandwidth = Determined by SDH Framer (say STM-64)
スイッチング能力記述子を連結してください: インタフェーススイッチング能力はSDH喧嘩早い人で断固とした=SDH Reservable帯域幅=をコード化するLSCと等しいです。(STM-64を言います)
Kompella & Rekhter Standards Track [Page 16] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[16ページ]。
3.6. Interface on a Transparent OXC (PXC) with External DWDM That
Understands SDH Framing
3.6. SDH縁どりを理解している外部のDWDMと共に透明なOXC(PXC)に連結してください。
This example assumes that DWDM and PXC are connected in such a way that each interface (port) on the PXC handles just a single wavelength. Thus, even if in principle an interface on the PXC could switch multiple wavelengths as a whole, in this particular case an interface on the PXC is considered LSC, and not FSC.
この例は、DWDMとPXCがPXCの上の各インタフェース(ポート)がまさしくただ一つの波長を扱うような方法で接続されると仮定します。 したがって、PXCの上のインタフェースが原則として全体で複数の波長を切り換えることができても、この場合はPXCの上のインタフェースはFSCではなく、LSCであると考えられます。
_______
| |
/|___| |
| |___| PXC |
========| |___| |
| |___| |
\| |_______|
DWDM
(SDH framed)
_______ | | /|___| | | |___| PXC| ========| |___| | | |___| | \| |_______| DWDM(縁どられたSDH)
A TE link is a group of one or more interfaces on the PXC. All interfaces on a given PXC are required to have identifiers unique to that PXC, and these identifiers are used as labels (see 3.2.1.1 of [GMPLS-SIG]).
TEリンクはPXCの上の1つ以上のインタフェースのグループです。 見てください。与えられたPXCの上のすべてのインタフェースが識別子をそのPXCにユニークにするのに必要であり、これらの識別子がラベルとして使用される、(3.2 .1 .1 [GMPLS-SIG)について。
The following is an example of an interface switching capability descriptor on a transparent OXC (PXC) with external DWDM that understands SDH framing:
↓これはSDHが以下を縁どるのを理解している外部のDWDMと透明なOXC(PXC)に関するインタフェーススイッチング能力記述子に関する例です。
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = SDH (comes from DWDM)
Reservable Bandwidth = Determined by DWDM (say STM-64)
スイッチング能力記述子を連結してください: DWDMで断固とした=SDH(DWDMから、来る)Reservable帯域幅=をコード化するインタフェーススイッチング能力=LSC(STM-64を言います)
3.7. Interface on a Transparent OXC (PXC) with External DWDM That Is
Transparent to Bit-Rate and Framing
3.7. ビット伝送速度と縁どりに透明な外部のDWDMと共に透明なOXC(PXC)に連結してください。
This example assumes that DWDM and PXC are connected in such a way that each interface (port) on the PXC handles just a single wavelength. Thus, even if in principle an interface on the PXC could switch multiple wavelengths as a whole, in this particular case an interface on the PXC is considered LSC, and not FSC.
この例は、DWDMとPXCがPXCの上の各インタフェース(ポート)がまさしくただ一つの波長を扱うような方法で接続されると仮定します。 したがって、PXCの上のインタフェースが原則として全体で複数の波長を切り換えることができても、この場合はPXCの上のインタフェースはFSCではなく、LSCであると考えられます。
Kompella & Rekhter Standards Track [Page 17] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[17ページ]。
_______
| |
/|___| |
| |___| PXC |
========| |___| |
| |___| |
\| |_______|
DWDM (transparent to bit-rate and framing)
_______ | | /|___| | | |___| PXC| ========| |___| | | |___| | \| |_______| DWDM(ビット伝送速度と縁どりように透明)です。
A TE link is a group of one or more interfaces on the PXC. All interfaces on a given PXC are required to have identifiers unique to that PXC, and these identifiers are used as labels (see 3.2.1.1 of [GMPLS-SIG]).
TEリンクはPXCの上の1つ以上のインタフェースのグループです。 見てください。与えられたPXCの上のすべてのインタフェースが識別子をそのPXCにユニークにするのに必要であり、これらの識別子がラベルとして使用される、(3.2 .1 .1 [GMPLS-SIG)について。
The following is an example of an interface switching capability descriptor on a transparent OXC (PXC) with external DWDM that is transparent to bit-rate and framing:
↓これはビット伝送速度と縁どりに透明な外部のDWDMと透明なOXC(PXC)に関するインタフェーススイッチング能力記述子に関する例です:
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = Lambda (photonic)
Reservable Bandwidth = Determined by optical technology limits
スイッチング能力記述子を連結してください: インタフェースSwitching Capability=LSC Encodingは光の技術限界によって断固としたλ(フォトニック)のReservable Bandwidth=と等しいです。
3.8. Interface on a PXC with No External DWDM
3.8. 外部のDWDMなしでPXCに連結してください。
The absence of DWDM in between two PXCs, implies that an interface is not limited to one wavelength. Thus, the interface is advertised as FSC.
2PXCsの間のDWDMの不在、インタフェースが1つの波長に制限されないのを含意します。 したがって、FSCとしてインタフェースの広告を出します。
A TE link is a group of one or more interfaces on the PXC. All interfaces on a given PXC are required to have identifiers unique to that PXC, and these identifiers are used as port labels (see 3.2.1.1 of [GMPLS-SIG]).
TEリンクはPXCの上の1つ以上のインタフェースのグループです。 見てください。与えられたPXCの上のすべてのインタフェースが識別子をそのPXCにユニークにするのに必要であり、これらの識別子がポートラベルとして使用される、(3.2 .1 .1 [GMPLS-SIG)について。
Interface Switching Capability Descriptor:
Interface Switching Capability = FSC
Encoding = Lambda (photonic)
Reservable Bandwidth = Determined by optical technology limits
スイッチング能力記述子を連結してください: インタフェースSwitching Capability=FSC Encodingは光の技術限界によって断固としたλ(フォトニック)のReservable Bandwidth=と等しいです。
Note that this example assumes that the PXC does not restrict each port to carry only one wavelength.
この例が、PXCが1つの波長だけを運ぶために各ポートを制限しないと仮定することに注意してください。
3.9. Interface on a OXC with Internal DWDM That Understands SDH Framing
3.9. SDH縁どりを理解している内部のDWDMと共にOXCに連結してください。
This example assumes that DWDM and OXC are connected in such a way that each interface on the OXC handles multiple wavelengths individually. In this case an interface on the OXC is considered LSC, and not FSC.
この例は、DWDMとOXCがOXCの上の各インタフェースが個別に複数の波長を扱うような方法で接続されると仮定します。 この場合、OXCの上のインタフェースはFSCではなく、LSCであると考えられます。
Kompella & Rekhter Standards Track [Page 18] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[18ページ]。
_______
| |
/|| ||\
| || OXC || |
========| || || |====
| || || |
\||_______||/
DWDM
(SDH framed)
_______ | | /|| ||\ | || OXC|| | ========| || || |==== | || || | \||_______||/DWDM(縁どられたSDH)
A TE link is a group of one or more of the interfaces on the OXC. All lambdas associated with a particular interface are required to have identifiers unique to that interface, and these identifiers are used as labels (see 3.2.1.1 of [GMPLS-SIG]).
TEリンクはOXCの上のインタフェースの1つ以上のグループです。 見てください。特定のインタフェースに関連しているすべてのλが識別子をそのインタフェースにユニークにするのに必要であり、これらの識別子がラベルとして使用される、(3.2 .1 .1 [GMPLS-SIG)について。
The following is an example of an interface switching capability descriptor on an OXC with internal DWDM that understands SDH framing and supports discrete bandwidths:
↓これはSDH縁どりを理解して、離散的な帯域幅をサポートする内部のDWDMとOXCに関するインタフェーススイッチング能力記述子に関する例です:
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = SDH (comes from DWDM)
Max LSP Bandwidth = Determined by DWDM (say STM-16)
スイッチング能力記述子を連結してください: DWDMで断固とした=SDH(DWDMから、来る)マックスLSP Bandwidth=をコード化するインタフェーススイッチング能力=LSC(STM-16を言います)
Interface Switching Capability = LSC
Encoding = SDH (comes from DWDM)
Max LSP Bandwidth = Determined by DWDM (say STM-64)
DWDMで断固とした=SDH(DWDMから、来る)マックスLSP Bandwidth=をコード化するインタフェーススイッチング能力=LSC(STM-64を言います)
3.10. Interface on a OXC with Internal DWDM That Is Transparent to
Bit-Rate and Framing
3.10. ビット伝送速度と縁どりに透明な内部のDWDMと共にOXCに連結してください。
This example assumes that DWDM and OXC are connected in such a way that each interface on the OXC handles multiple wavelengths individually. In this case an interface on the OXC is considered LSC, and not FSC.
この例は、DWDMとOXCがOXCの上の各インタフェースが個別に複数の波長を扱うような方法で接続されると仮定します。 この場合、OXCの上のインタフェースはFSCではなく、LSCであると考えられます。
_______
| |
/|| ||\
| || OXC || |
========| || || |====
| || || |
\||_______||/
DWDM (transparent to bit-rate and framing)
_______ | | /|| ||\ | || OXC|| | ========| || || |==== | || || | \||_______||/DWDM(ビット伝送速度と縁どりように透明)です。
Kompella & Rekhter Standards Track [Page 19] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[19ページ]。
A TE link is a group of one or more of the interfaces on the OXC. All lambdas associated with a particular interface are required to have identifiers unique to that interface, and these identifiers are used as labels (see 3.2.1.1 of [GMPLS-SIG]).
TEリンクはOXCの上のインタフェースの1つ以上のグループです。 見てください。特定のインタフェースに関連しているすべてのλが識別子をそのインタフェースにユニークにするのに必要であり、これらの識別子がラベルとして使用される、(3.2 .1 .1 [GMPLS-SIG)について。
The following is an example of an interface switching capability descriptor on an OXC with internal DWDM that is transparent to bit- rate and framing:
↓これはビットレートと縁どりに透明な内部のDWDMとOXCに関するインタフェーススイッチング能力記述子に関する例です:
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = Lambda (photonic)
Max LSP Bandwidth = Determined by optical technology limits
スイッチング能力記述子を連結してください: インタフェースSwitching Capability=LSC Encodingは光の技術限界によって断固としたλ(フォトニック)のマックスLSP Bandwidth=と等しいです。
4. Example of Interfaces That Support Multiple Switching Capabilities
4. 複数のスイッチング能力を支持するインタフェースに関する例
There can be many combinations possible, some are described below.
可能な多くの組み合わせがあることができて、或るものは以下で説明されます。
4.1. Interface on a PXC+TDM Device with External DWDM
4.1. 外部のDWDMと共にPXC+TDM装置に接続してください。
As discussed earlier, the presence of the external DWDM limits that only one wavelength be on a port of the PXC. On such a port, the attached PXC+TDM device can do one of the following. The wavelength may be cross-connected by the PXC element to other out-bound optical channel, or the wavelength may be terminated as an SDH interface and SDH channels switched.
より早く議論するように、PXCのポートの上に1つの波長しかない外部のDWDM限界について存在します。 そのようなポートでは、付属PXC+TDM装置は以下の1つができます。 波長はもう一方に十字で関連しているPXC要素に従って出かける行きの光学チャンネルであるかもしれませんかSDHインタフェースとSDHチャンネルが切り替わったとき、波長は終えられるかもしれません。
From a GMPLS perspective the PXC+TDM functionality is treated as a single interface. The interface is described using two Interface descriptors, one for the LSC and another for the TDM, with appropriate parameters. For example,
GMPLS見解から、PXC+TDMの機能性は単一のインタフェースとして扱われます。 インタフェースは、2つのInterface記述子とLSCのためのものと適切なパラメタがあるTDMのための別のものを使用することで説明されます。 例えば
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = SDH (comes from WDM)
Reservable Bandwidth = STM-64
スイッチング能力記述子を連結してください: =SDH(WDMから、来る)Reservable帯域幅をコード化するインタフェーススイッチング能力=LSCがSTM-64と等しいです。
and
そして
Interface Switching Capability Descriptor:
Interface Switching Capability = TDM [Standard SDH]
Encoding = SDH
Min LSP Bandwidth = VC-3
Max LSP Bandwidth[p] = STM-64, for all p
スイッチング能力記述子を連結してください: インタフェースSwitching CapabilityはVC-3マックス=SDH Min LSP Bandwidth=LSP Bandwidth[p]=STM-64をコード化しながら、TDM[標準のSDH]と等しいです、すべてのpのために
Kompella & Rekhter Standards Track [Page 20] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[20ページ]。
4.2. Interface on an Opaque OXC+TDM Device with External DWDM
4.2. 外部のDWDMと共に不透明なOXC+TDM装置に接続してください。
An interface on an "opaque OXC+TDM" device would also be advertised as LSC+TDM much the same way as the previous case.
また、LSC+TDMとして「不透明なOXC+TDM」装置の上のインタフェースのずっと先の事件として似たり寄ったりの状態で広告を出すでしょう。
4.3. Interface on a PXC+LSR Device with External DWDM
4.3. 外部のDWDMと共にPXC+LSR装置に接続してください。
As discussed earlier, the presence of the external DWDM limits that only one wavelength be on a port of the PXC. On such a port, the attached PXC+LSR device can do one of the following. The wavelength may be cross-connected by the PXC element to other out-bound optical channel, or the wavelength may be terminated as a Packet interface and packets switched.
より早く議論するように、PXCのポートの上に1つの波長しかない外部のDWDM限界について存在します。 そのようなポートでは、付属PXC+LSR装置は以下の1つができます。 波長はもう一方に十字で関連しているPXC要素に従って出かける行きの光学チャンネルであるかもしれませんかPacketインタフェースとパケットが切り替わったとき、波長は終えられるかもしれません。
From a GMPLS perspective the PXC+LSR functionality is treated as a single interface. The interface is described using two Interface descriptors, one for the LSC and another for the PSC, with appropriate parameters. For example,
GMPLS見解から、PXC+LSRの機能性は単一のインタフェースとして扱われます。 インタフェースは、2つのInterface記述子とLSCのためのものと適切なパラメタがあるPSCのための別のものを使用することで説明されます。 例えば
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = SDH (comes from WDM)
Reservable Bandwidth = STM-64
スイッチング能力記述子を連結してください: =SDH(WDMから、来る)Reservable帯域幅をコード化するインタフェーススイッチング能力=LSCがSTM-64と等しいです。
and
そして
Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1
Encoding = SDH
Max LSP Bandwidth[p] = 10 Gbps, for all p
スイッチング能力記述子を連結してください: SDHマックスインタフェースSwitching Capability=PSC-1 Encoding=LSP Bandwidth[p]はすべてのpのために10Gbpsと等しいです。
4.4. Interface on a TDM+LSR Device
4.4. TDM+LSR装置に接続してください。
On a TDM+LSR device that offers a channelized SDH interface the following may be possible:
channelized SDHインタフェースを提供するTDM+LSR装置では、以下は可能であるかもしれません:
- A subset of the SDH channels may be uncommitted. That is, they
are not currently in use and hence are available for allocation.
- SDHチャンネルの部分集合は未遂であるかもしれません。 すなわち、それらは、現在、使用中でなく、したがって、配分に利用可能です。
- A second subset of channels may already be committed for transit
purposes. That is, they are already cross-connected by the SDH
cross connect function to other out-bound channels and thus are
not immediately available for allocation.
- チャンネルの2番目の部分集合はトランジット目的のために既に遂行されるかもしれません。 すなわち、それらは、他の出かける行きのチャンネルへの接続機能が既にSDH十字で十字で接続したということであり、その結果、すぐに、配分に利用可能ではありません。
- Another subset of channels could be in use as terminal channels.
That is, they are already allocated by terminate on a packet
interface and packets switched.
- チャンネルの別の部分集合は端末のチャンネルとして使用中であるかもしれません。 すなわち、割り当てて、それらは既にそうです。パケットインタフェースと切り換えられたパケットで終わってください。
Kompella & Rekhter Standards Track [Page 21] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[21ページ]。
From a GMPLS perspective the TDM+PSC functionality is treated as a single interface. The interface is described using two Interface descriptors, one for the TDM and another for the PSC, with appropriate parameters. For example,
GMPLS見解から、TDM+PSCの機能性は単一のインタフェースとして扱われます。 インタフェースは、2つのInterface記述子とTDMのためのものと適切なパラメタがあるPSCのための別のものを使用することで説明されます。 例えば
Interface Switching Capability Descriptor:
Interface Switching Capability = TDM [Standard SDH]
Encoding = SDH
Min LSP Bandwidth = VC-3
Max LSP Bandwidth[p] = STM-64, for all p
スイッチング能力記述子を連結してください: インタフェースSwitching CapabilityはVC-3マックス=SDH Min LSP Bandwidth=LSP Bandwidth[p]=STM-64をコード化しながら、TDM[標準のSDH]と等しいです、すべてのpのために
and
そして
Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1
Encoding = SDH
Max LSP Bandwidth[p] = 10 Gbps, for all p
スイッチング能力記述子を連結してください: SDHマックスインタフェースSwitching Capability=PSC-1 Encoding=LSP Bandwidth[p]はすべてのpのために10Gbpsと等しいです。
5. Acknowledgements
5. 承認
The authors would like to thank Suresh Katukam, Jonathan Lang, Zhi- Wei Lin, and Quaizar Vohra for their comments and contributions to the document. Thanks too to Stephen Shew for the text regarding "Representing TE Link Capabilities".
作者はドキュメントへの彼らのコメントと貢献についてSuresh Katukam、ジョナサン・ラング、Zhiウェイ・リン、およびQuaizar Vohraに感謝したがっています。 また、「Teリンク能力を表します」に関するテキストをスティーブン・シューをありがとうございます。
6. Security Considerations
6. セキュリティ問題
There are a number of security concerns in implementing the extensions proposed here, particularly since these extensions will potentially be used to control the underlying transport infrastructure. It is vital that there be secure and/or authenticated means of transferring this information among the entities that require its use.
ここで提案された拡大を実行するのにおいて多くの安全上の配慮があります、これらの拡張子が基本的な輸送インフラを制御するのに特に潜在的に使用されるので。 そこに、いてください。それが重大である、それ、使用を必要とする実体にこの情報を移す安全な、そして/または、認証された手段。
While this document proposes extensions, it does not state how these extensions are implemented in routing protocols such as OSPF or IS-IS. The documents that do state how routing protocols implement these extensions [GMPLS-OSPF, GMPLS-ISIS] must also state how the information is to be secured.
または、このドキュメントが拡大を提案している間、これらの拡大がOSPFなどのルーティング・プロトコルでどう実行されるかを述べない、- また、ルーティング・プロトコルがどう、これらの拡大[GMPLS-OSPF、GMPLS-イシス]を実行するかを述べるドキュメントは安全にする情報がことである方法を述べなければなりません。
Kompella & Rekhter Standards Track [Page 22] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[22ページ]。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[GMPLS-OSPF] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4203, October 2005.
[GMPLS-OSPF] エドKompella、K.、エドY.Rekhter、「一般化されたマルチプロトコルラベルを支持したOSPF拡張子は(GMPLS)を切り換えること」でのRFC4203(2005年10月)。
[GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003.
[GMPLS-SIG] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、2003年1月。
[GMPLS-SONET-SDH] Mannie, E. and D. Papadimitriou, "Generalized
Multi-Protocol Label Switching (GMPLS) Extensions
for Synchronous Optical Network (SONET) and
Synchronous Digital Hierarchy (SDH) Control", RFC
3946, October 2004.
[GMPLS Sonet SDH] マニー(E.とD.Papadimitriou)は、「同期式光通信網(Sonet)と同期デジタルハイアラーキ(SDH)コントロールのためのマルチプロトコルラベルスイッチング(GMPLS)拡大を一般化しました」、RFC3946、2004年10月。
[IEEE] IEEE, "IEEE Standard for Binary Floating-Point
Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-
7653-8).
[IEEE]IEEE、「バイナリーの浮動小数点の演算における、標準のIEEE」、規格754-1985、1985(ISBN1-5593- 7653-8)。
[LINK-BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link
Bundling in MPLS Traffic Engineering (TE)", RFC
4201, October 2005.
[リンクバンドル]Kompella、K.、Rekhter、Y.、およびL.バーガー、「MPLS交通工学(Te)におけるリンクバンドリング」、RFC4201、2005年10月。
[LMP] Lang, J., Ed., "Link Management Protocol (LMP)",
RFC 4204, October 2005.
[LMP] ラング、J.、エド、「リンク管理プロトコル(LMP)」、RFC4204、10月2005日
[LSP-HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol
Label Switching (GMPLS) Traffic Engineering (TE))",
RFC 4206, October 2005.
[LSP-HIER]Kompella(K.とY.Rekhter)は「一般化されたマルチプロトコルラベルスイッチング(GMPLS)交通工学(Te)で切り換えられた経路(LSP)を階層構造とラベルします」、RFC4206、2005年10月。
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[OSPF-Te] キャッツ、D.、Kompella、K.、およびD.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、2003年9月。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label
Stack Encoding", RFC 3032, January 2001.
[RFC3032] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
Kompella & Rekhter Standards Track [Page 23] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[23ページ]。
7.2. Informative References
7.2. 有益な参照
[GMPLS-ISIS] Kompella, K., Ed. and Y. Rekhter, Ed.,
"Intermediate System to Intermediate System (IS-IS)
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4205, October 2005.
エド[GMPLS-イシス]Kompella、K.、Y.Rekhter、エド、「中間システムへの中間システム、(-、)、一般化されたマルチプロトコルを支持した拡大が切り換え(GMPLS)をラベルする、」、RFC4205(2005年10月)
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", RFC 3784, June 2004.
[イシス-Te] スミット、H.、およびT.李、「中間システムへの中間システム、(-、)、交通工学(Te)のための拡大、」、RFC3784(2004年6月)
8. Contributors
8. 貢献者
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138
アヤンバネルジーCalientネットワーク5853はフェラーリサンノゼ、カリフォルニア 95138を悔悟します。
Phone: +1.408.972.3645 EMail: abanerjee@calient.net
以下に電話をしてください。 +1.408 .972 .3645 メール: abanerjee@calient.net
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
ジョンドレイクCalientネットワーク5853はフェラーリサンノゼ、カリフォルニア 95138を悔悟します。
Phone: (408) 972-3720 EMail: jdrake@calient.net
以下に電話をしてください。 (408) 972-3720 メールしてください: jdrake@calient.net
Greg Bernstein Ciena Corporation 10480 Ridgeview Court Cupertino, CA 94014
グレッグバーンスタインCiena社10480のRidgeview法廷カルパチーノ、カリフォルニア 94014
Phone: (408) 366-4713 EMail: greg@ciena.com
以下に電話をしてください。 (408) 366-4713 メールしてください: greg@ciena.com
Don Fedyk Nortel Networks Corp. 600 Technology Park Drive Billerica, MA 01821
ドンFedykノーテルはDriveビルリカ、社600の技術Park MA 01821をネットワークでつなぎます。
Phone: +1-978-288-4506 EMail: dwfedyk@nortelnetworks.com
以下に電話をしてください。 +1-978-288-4506 メールしてください: dwfedyk@nortelnetworks.com
Kompella & Rekhter Standards Track [Page 24] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[24ページ]。
Eric Mannie Libre Exaministe
エリックマニーLibre Exaministe
EMail: eric_mannie@hotmail.com
メール: eric_mannie@hotmail.com
Debanjan Saha Tellium Optical Systems 2 Crescent Place P.O. Box 901 Ocean Port, NJ 07757
DebanjanシャハTellium光学系2の三日月形場所私書箱901海洋港、ニュージャージー 07757
Phone: (732) 923-4264 EMail: dsaha@tellium.com
以下に電話をしてください。 (732) 923-4264 メールしてください: dsaha@tellium.com
Vishal Sharma Metanoia, Inc. 335 Elan Village Lane, Unit 203 San Jose, CA 95134-2539
VishalシャルマMetanoia Inc.335活気村のレーン、サンノゼ、Unit203カリフォルニア95134-2539
Phone: +1 408-943-1794 EMail: v.sharma@ieee.org
以下に電話をしてください。 +1 408-943-1794 メールしてください: v.sharma@ieee.org
Debashis Basak AcceLight Networks, 70 Abele Rd, Bldg 1200 Bridgeville PA 15017
Debashis Basak AcceLightネットワーク、70ハクヨウ、Bldg1200Bridgeville PA 15017番目
EMail: dbasak@accelight.com
メール: dbasak@accelight.com
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
ルウバーガーMovazはInc.7926ジョーンズ支店ドライブスイート615マクリーン・ヴァージニア、22102をネットワークでつなぎます。
EMail: lberger@movaz.com
メール: lberger@movaz.com
Kompella & Rekhter Standards Track [Page 25] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[25ページ]。
Authors' Addresses
作者のアドレス
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089
Kireeti Kompella杜松はInc.1194N.マチルダ・Aveサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: kireeti@juniper.net
メール: kireeti@juniper.net
Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089
ヤコフRekhter JuniperはInc.1194N.マチルダ・Aveサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: yakov@juniper.net
メール: yakov@juniper.net
Kompella & Rekhter Standards Track [Page 26] RFC 4202 Routing Extensions for GMPLS October 2005
Kompella&Rekhter規格は2005年10月にGMPLSのためにRFC4202ルート設定拡張子を追跡します[26ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kompella & Rekhter Standards Track [Page 27]
Kompella&Rekhter標準化過程[27ページ]
一覧
スポンサーリンク
