RFC4203 日本語訳
4203 OSPF Extensions in Support of Generalized Multi-Protocol LabelSwitching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2005. (Format: TXT=23130 bytes) (Updates RFC3630) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Kompella, Ed. Request for Comments: 4203 Y. Rekhter, Ed. Updates: 3630 Juniper Networks Category: Standards Track October 2005
ワーキンググループK.Kompella、エドをネットワークでつないでください。コメントのために以下を要求してください。 エド4203Y.Rekhter、アップデート: 3630年の杜松はカテゴリをネットワークでつなぎます: 標準化過程2005年10月
OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)
一般化されたマルチプロトコルラベルスイッチングを支持したOSPF拡張子(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 encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS).
このドキュメントはGeneralized Multi-プロトコルLabel Switching(GMPLS)を支持してOSPFルーティング・プロトコルに拡大のコード化を指定します。
1. Introduction
1. 序論
This document specifies extensions to the OSPF routing protocol [OSPF] in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). The set of required enhancements to OSPF are outlined in [GMPLS-ROUTING].
Generalized Multi-プロトコルLabel Switching(GMPLS)のためのリンク州の情報を運ぶことを支持してこのドキュメントはOSPFルーティング・プロトコル[OSPF]に拡大を指定します。 OSPFへの必要な増進のセットは[GMPLS-ルート設定]に概説されています。
In this section, we define the enhancements to the Traffic Engineering (TE) properties of GMPLS TE links that can be announced in OSPF TE LSAs. The TE LSA, which is an opaque LSA with area flooding scope [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and has one or more nested sub-TLVs for extensibility. The top-level TLV can take one of two values (1) Router Address or (2) Link. In this document, we enhance the sub-TLVs for the Link TLV in support of GMPLS. Specifically, we add the following sub-TLVs to the Link TLV:
このセクションで、私たちはOSPF TE LSAsで発表できるGMPLS TEリンクのTraffic Engineering(TE)の特性と増進を定義します。 TE LSA(領域の氾濫範囲[OSPF-TE]がある不透明なLSAである)には、1人のトップレベルType/長さ/価値(TLV)の三つ子しかいないで、伸展性のための1入れ子にされたサブTLVsがあります。 先端平らなTLVは2値(1)ルータAddressか(2)リンクの1つを取ることができます。 本書では、私たちはGMPLSを支持したLink TLVのためのサブTLVsを高めます。 明確に、私たちはLink TLVへのサブTLVsの以下を加えます:
Kompella & Rekhter Standards Track [Page 1] RFC 4203 OSPF Extensions in MPLS October 2005
Kompella&Rekhter規格は2005年10月にMPLSでRFC4203OSPF拡張子を追跡します[1ページ]。
Sub-TLV Type Length Name
11 8 Link Local/Remote Identifiers
14 4 Link Protection Type
15 variable Interface Switching Capability Descriptor
16 variable Shared Risk Link Group
11サブTLV Type Length Nameの8Link Local/リモートなIdentifiers14 4Link Protection Type15の可変Interface Switching Capability Descriptor16の可変Shared Risk Link Group
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. Link Local/Remote Identifiers
1.1. 地方の、または、リモートな識別子をリンクしてください。
Link Local/Remote Identifiers is a sub-TLV of the Link TLV. The type of this sub-TLV is 11, and length is eight octets. The value field of this sub-TLV contains four octets of Link Local Identifier followed by four octets of Link Remote Identifier (see Section "Support for unnumbered links" of [GMPLS-ROUTING]). If the Link Remote Identifier is unknown, it is set to 0.
リンクLocal/リモートなIdentifiersはLink TLVのサブTLVです。 このサブTLVのタイプは11歳です、そして、長さは8つの八重奏です。 このサブTLVの値の分野はLink Remote Identifierの4つの八重奏があとに続いたLink Local Identifierの4つの八重奏を含んでいます(「無数のリンクのサポート」という[GMPLS-ルート設定]のセクションを見てください)。 Link Remote Identifierが未知であるなら、それは0に設定されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Remote Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルの識別子をリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リモート識別子をリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A node can communicate its Link Local Identifier to its neighbor using a link local Opaque LSA, as described in Section "Exchanging Link Local TE Information".
ノードはリンクの地方のOpaque LSAを使用することでLink Local Identifierを隣人に伝えることができます、「リンクのローカルのTe情報を交換する」というセクションで説明されるように。
1.2. Link Protection Type
1.2. リンク保護タイプ
The Link Protection Type is a sub-TLV of the Link TLV. The type of this sub-TLV is 14, and length is four octets.
Link Protection TypeはLink TLVのサブTLVです。 このサブTLVのタイプは14歳です、そして、長さは4つの八重奏です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protection Cap | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |保護キャップ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first octet is a bit vector describing the protection capabilities of the link (see Section "Link Protection Type" of [GMPLS-ROUTING]). They are:
最初の八重奏はリンクの保護能力について説明するしばらくベクトル([GMPLS-ルート設定]のセクション「リンク保護タイプ」を見る)です。 それらは以下の通りです。
0x01 Extra Traffic
0×01 余分な交通
Kompella & Rekhter Standards Track [Page 2] RFC 4203 OSPF Extensions in MPLS October 2005
Kompella&Rekhter規格は2005年10月にMPLSでRFC4203OSPF拡張子を追跡します[2ページ]。
0x02 Unprotected
0×02、保護のなさ
0x04 Shared
0×04は共有されました。
0x08 Dedicated 1:1
0×08 ひたむきな1:1
0x10 Dedicated 1+1
0×10は+1に1を捧げました。
0x20 Enhanced
高められた0×20
0x40 Reserved
予約された0×40
0x80 Reserved
予約された0×80
The remaining three octets SHOULD be set to zero by the sender, and SHOULD be ignored by the receiver.
3八重奏SHOULDのままで残っていて、送付者、およびSHOULDによってゼロに設定されてください。受信機で、無視されます。
The Link Protection Type sub-TLV may occur at most once within the Link TLV.
Link Protection TypeサブTLVはLink TLVの中に高々一度起こるかもしれません。
1.3. Shared Risk Link Group (SRLG)
1.3. 共有されたリスクリンク群(SRLG)
The SRLG is a sub-TLV (of type 16) of the Link TLV. The length is the length of the list in octets. The value is an unordered list of 32 bit numbers that are the SRLGs that the link belongs to. The format of the value field is as shown below:
SRLGはLink TLVのサブTLV(タイプ16の)です。 長さは八重奏で、リストの長さです。 値はリンクが属すSRLGsである32ビットの数の順不同のリストです。 以下で示されるとして値の分野の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 共有されたリスクリンク階級値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 共有されたリスクリンク階級値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV carries the Shared Risk Link Group information (see Section "Shared Risk Link Group Information" of [GMPLS-ROUTING]).
このサブTLVはShared Risk Link Group情報を運びます([GMPLS-ルート設定]のセクション「共有されたリスクリンク群情報」を見てください)。
The SRLG sub-TLV may occur at most once within the Link TLV.
SRLGサブTLVはLink TLVの中に高々一度起こるかもしれません。
1.4. Interface Switching Capability Descriptor
1.4. インタフェーススイッチング能力記述子
The Interface Switching Capability Descriptor is a sub-TLV (of type 15) of the Link TLV. The length is the length of value field in octets. The format of the value field is as shown below:
Interface Switching Capability DescriptorはLink TLVのサブTLV(タイプ15の)です。 長さは八重奏で、値の分野の長さです。 以下で示されるとして値の分野の形式があります:
Kompella & Rekhter Standards Track [Page 3] RFC 4203 OSPF Extensions in MPLS October 2005
Kompella&Rekhter規格は2005年10月にMPLSでRFC4203OSPF拡張子を追跡します[3ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability-specific information |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 切り換えキャップ| コード化| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 優先権0におけるマックスLSP Bandwidth| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 優先権1におけるマックスLSP Bandwidth| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 優先権2におけるマックスLSP Bandwidth| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 優先権3におけるマックスLSP Bandwidth| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 優先権4におけるマックスLSP Bandwidth| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 優先権5におけるマックスLSP Bandwidth| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 優先権6におけるマックスLSP Bandwidth| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 優先権7におけるマックスLSP Bandwidth| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 切り換えCapability-特殊情報| | (可変)です。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Switching Capability (Switching Cap) field contains one of the following values:
Switching Capability(切り換えCap)分野は以下の値の1つを含んでいます:
1 Packet-Switch Capable-1 (PSC-1)
2 Packet-Switch Capable-2 (PSC-2)
3 Packet-Switch Capable-3 (PSC-3)
4 Packet-Switch Capable-4 (PSC-4)
51 Layer-2 Switch Capable (L2SC)
100 Time-Division-Multiplex Capable (TDM)
150 Lambda-Switch Capable (LSC)
200 Fiber-Switch Capable (FSC)
1 できるできる1つのパケット交換機(PSC-1)2パケット交換機できる2(PSC-2)3パケット交換機できる3(PSC-3)4パケット交換機できる4(PSC-4)51層-2のスイッチのできる(L2SC)100時分割多重のできる(TDM)150λスイッチのできる(LSC)200ファイバースイッチ(FSC)
The Encoding field contains one of the values specified in Section 3.1.1 of [GMPLS-SIG].
Encoding分野は[GMPLS-SIG]についてセクション3.1.1で指定された値の1つを含んでいます。
Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in the IEEE floating point format [IEEE], with priority 0 first and priority 7 last. The units are bytes (not bits!) per second.
最大のLSP Bandwidthは最後に4八重奏が最初に優先権0でIEEE浮動小数点形式[IEEE]でさばく8と優先権7のリストとしてコード化されます。 ユニットは1秒あたりバイト(ビットでない!)です。
The content of the Switching Capability specific information field depends on the value of the Switching Capability field.
Switching Capability特殊情報分野の内容はSwitching Capability分野の値に依存します。
Kompella & Rekhter Standards Track [Page 4] RFC 4203 OSPF Extensions in MPLS October 2005
Kompella&Rekhter規格は2005年10月にMPLSでRFC4203OSPF拡張子を追跡します[4ページ]。
When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, the Switching Capability specific information field includes Minimum LSP Bandwidth, Interface MTU, and padding.
Switching Capability分野がPSC-1、PSC-2、PSC-3、またはPSC-4であるときに、Switching Capability特殊情報分野はMinimum LSP Bandwidth、Interface MTU、および詰め物を含んでいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum LSP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最小のLSP帯域幅| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースMTU| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Minimum LSP Bandwidth is encoded in a 4 octets field in the IEEE floating point format. The units are bytes (not bits!) per second. The Interface MTU is encoded as a 2 octets integer. The padding is 2 octets, and is used to make the Interface Switching Capability Descriptor sub-TLV 32-bits aligned. It SHOULD be set to zero by the sender and SHOULD be ignored by the receiver.
Minimum LSP Bandwidthは4八重奏分野でIEEE浮動小数点形式でコード化されます。 ユニットは1秒あたりバイト(ビットでない!)です。 Interface MTUは2八重奏整数としてコード化されます。 詰め物は、2つの八重奏であり、Interface Switching Capability DescriptorサブTLVを32ビット並べさせるのに使用されます。 送付者とSHOULDによってゼロに設定されてください。それ、SHOULD、受信機で、無視されます。
When the Switching Capability field is L2SC, there is no Switching Capability specific information field present.
Switching Capability分野がL2SCであるときに、どんな存在しているSwitching Capability特殊情報分野もありません。
When the Switching Capability field is TDM, the Switching Capability specific information field includes Minimum LSP Bandwidth, an indication whether the interface supports Standard or Arbitrary SONET/SDH, and padding.
Switching Capability分野がTDMであるときに、インタフェースがStandardかArbitrary Sonet/SDHと、詰め物を支持するか否かに関係なく、Switching Capability特殊情報分野はMinimum LSP Bandwidth、指示を含んでいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum LSP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Indication | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最小のLSP帯域幅| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 指示| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Minimum LSP Bandwidth is encoded in a 4 octets field in the IEEE floating point format. The units are bytes (not bits!) per second. The indication whether the interface supports Standard or Arbitrary SONET/SDH is encoded as 1 octet. The value of this octet is 0 if the interface supports Standard SONET/SDH, and 1 if the interface supports Arbitrary SONET/SDH. The padding is 3 octets, and is used to make the Interface Switching Capability Descriptor sub-TLV 32-bits aligned. It SHOULD be set to zero by the sender and SHOULD be ignored by the receiver.
Minimum LSP Bandwidthは4八重奏分野でIEEE浮動小数点形式でコード化されます。 ユニットは1秒あたりバイト(ビットでない!)です。 インタフェースがStandardかArbitrary Sonet/SDHを支持するか否かに関係なく、指示は1つの八重奏としてコード化されます。 インタフェースがArbitrary Sonet/SDHを支持するならインタフェースがStandard Sonet/SDH、および1を支持するなら、この八重奏の値は0です。 詰め物は、3つの八重奏であり、Interface Switching Capability DescriptorサブTLVを32ビット並べさせるのに使用されます。 送付者とSHOULDによってゼロに設定されてください。それ、SHOULD、受信機で、無視されます。
When the Switching Capability field is LSC, there is no Switching Capability specific information field present.
Switching Capability分野がLSCであるときに、どんな存在しているSwitching Capability特殊情報分野もありません。
Kompella & Rekhter Standards Track [Page 5] RFC 4203 OSPF Extensions in MPLS October 2005
Kompella&Rekhter規格は2005年10月にMPLSでRFC4203OSPF拡張子を追跡します[5ページ]。
To support interfaces that have more than one Interface Switching Capability Descriptor (see Section "Interface Switching Capability Descriptor" of [GMPLS-ROUTING]) the Interface Switching Capability Descriptor sub-TLV may occur more than once within the Link TLV.
1Interface Switching Capability Descriptor([GMPLS-ルート設定]のセクション「インタフェーススイッチング能力記述子」を見る)を持っているインタフェースを支持するために、Interface Switching Capability DescriptorサブTLVはLink TLVの中の一度より起こるかもしれません。
2. Implications on Graceful Restart
2. 優雅な再開での含意
The restarting node should follow the OSPF restart procedures [OSPF-RESTART], and the RSVP-TE restart procedures [GMPLS-RSVP].
再開ノードはOSPF再開手順[OSPF-RESTART]に従うはずです、そして、RSVP-TEは手順[GMPLS-RSVP]を再開します。
When a restarting node is going to originate its TE LSAs, the TE LSAs containing Link TLV should be originated with 0 unreserved bandwidth, Traffic Engineering metric set to 0xffffffff, and if the Link has LSC or FSC as its Switching Capability then also with 0 as Max LSP Bandwidth, until the node is able to determine the amount of unreserved resources taking into account the resources reserved by the already established LSPs that have been preserved across the restart. Once the restarting node determines the amount of unreserved resources, taking into account the resources reserved by the already established LSPs that have been preserved across the restart, the node should advertise these resources in its TE LSAs.
再開ノードがTE LSAsを溯源するだろうというとき、0xffffffffに用意ができていて、Linkがそして、マックスLSP Bandwidthとしての0をもってもSwitching CapabilityとしてLSCかFSCを持っているなら、0が無遠慮な帯域幅であって、Traffic Engineeringメートル法であることでLink TLVを含むTE LSAsは溯源されるべきです、ノードが再開の向こう側に保存された既に確立したLSPsによって予約されたリソースを考慮に入れる無遠慮なリソースの量を測定できるまで。 再開の向こう側に保存された既に確立したLSPsによって予約されたリソースを考慮に入れて、再開ノードがいったん無遠慮なリソースの量を測定すると、ノードはTE LSAsのこれらのリソースの広告を出すはずです。
In addition in the case of a planned restart prior to restarting, the restarting node SHOULD originate the TE LSAs containing Link TLV with 0 as unreserved bandwidth, and if the Link has LSC or FSC as its Switching Capability then also with 0 as Max LSP Bandwidth. This would discourage new LSP establishment through the restarting router.
さらに、再開の前の計画された再開の場合では、無遠慮な帯域幅とLinkではそして、マックスLSP Bandwidthとしての0をもってもSwitching CapabilityとしてLSCかFSCがあるかどうかとして再開ノードSHOULDは0でLink TLVを含むTE LSAsを溯源します。 これは再開ルータを通した新しいLSP設立に水をさしているでしょう。
Neighbors of the restarting node should continue advertise the actual unreserved bandwidth on the TE links from the neighbors to that node.
再開ノードのネイバーズを続けるべきです。隣人からそのノードまでTEリンクにおける実際の無遠慮な帯域幅の広告を出してください。
Regular graceful restart should not be aborted if a TE LSA or TE topology changes. TE graceful restart need not be aborted if a TE LSA or TE topology changes.
TE LSAかTEトポロジーが変化するなら、定期的な優雅な再開を中止するべきではありません。 TE LSAかTEトポロジーが変化するなら、TEの優雅な再開は中止される必要はありません。
3. Exchanging Link Local TE Information
3. リンクのローカルのTe情報を交換します。
It is often useful for a node to communicate some Traffic Engineering information for a given interface to its neighbors on that interface. One example of this is a Link Local Identifier. If nodes X and Y are connected by an unnumbered point-to-point interface I, then X's Link Local Identifier for I is Y's Link Remote Identifier for I. X can communicate its Link Local Identifier for I by exchanging with Y a TE link local opaque LSA described below. Note that this information need only be exchanged over interface I, hence the use of a link local Opaque LSA.
ノードがそのインタフェースで与えられたインタフェースのための何らかのTraffic Engineering情報を隣人に伝えるのは、しばしば役に立ちます。 この1つの例がLink Local Identifierです。 ノードXとYが無数の二地点間インタフェースIによって接続されるなら、XのLink Local Identifierは、IがI.XのためのYのLink Remote Identifierであるので、IのためにYと共に地方の不透明なLSAが以下で説明したTEリンクを交換することによって、Link Local Identifierを伝えることができます。 この情報が交換して、したがって、私、使用がオーバー連結するということであるだけでよいことにリンクの地方のOpaque LSAに注意してください。
Kompella & Rekhter Standards Track [Page 6] RFC 4203 OSPF Extensions in MPLS October 2005
Kompella&Rekhter規格は2005年10月にMPLSでRFC4203OSPF拡張子を追跡します[6ページ]。
A TE Link Local LSA is an opaque LSA of type 9 (link-local flooding scope) with Opaque Type 1 (TE LSA) and Opaque ID of 0.
TE Link Local LSAはOpaque Type1(TE LSA)があるタイプ9(リンク地方の氾濫範囲)の不透明なLSAと0のOpaque IDです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS時代| オプション| 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 分っているタイプ| 不透明なID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + TLVs-+| ... |
The format of the TLVs that make up the body of the TE Link Local LSA is the same as that of the TE TLVs: a 2-octet Type field followed by a 2-octet Length field which indicates the length of the Value field in octets. The Top Level Type for the Link Local TLV is 4. The Value field is zero-padded at the end to a four octet boundary.
TE Link Local LSAのボディーを作るTLVsの形式はTE TLVsのものと同じです: 2八重奏のType野原は八重奏における、Value分野の長さを示す2八重奏のLength分野のそばで続きました。 Link Local TLVのためのTop Level Typeは4歳です。 Value分野は4八重奏境界の終わりに無そっと歩いています。
The only TLV defined here is the Link Local Identifier TLV, with Type 1, Length 4 and Value the 32 bit Link Local Identifier for the link over which the TE Link Local LSA is exchanged.
ここで定義された唯一のTLVがLink Local Identifier TLVです、Type1と共に、TE Link Local LSAが交換されるリンクへのLength4とValueの32の噛み付いているLink Local Identifier。
4. Contributors
4. 貢献者
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: +1.408.972.3720 EMail: jdrake@calient.net
以下に電話をしてください。 +1.408 .972 .3720 メール: jdrake@calient.net
Kompella & Rekhter Standards Track [Page 7] RFC 4203 OSPF Extensions in MPLS October 2005
Kompella&Rekhter規格は2005年10月にMPLSでRFC4203OSPF拡張子を追跡します[7ページ]。
Greg Bernstein Ciena Corporation 10480 Ridgeview Court Cupertino, CA 94014
グレッグバーンスタインCiena社10480のRidgeview法廷カルパチーノ、カリフォルニア 94014
Phone: +1.408.366.4713 EMail: greg@ciena.com
以下に電話をしてください。 +1.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
Eric Mannie Independent Consultant
エリック・マニーから独立しているコンサルタント
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: +1.732.923.4264 EMail: dsaha@tellium.com
以下に電話をしてください。 +1.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
5. Acknowledgements
5. 承認
The authors would like to thank Suresh Katukam, Jonathan Lang, Quaizar Vohra, and Alex Zinin for their comments on the document.
作者はドキュメントの彼らのコメントについてSuresh Katukam、ジョナサン・ラング、Quaizar Vohra、およびアレックス・ジニンに感謝したがっています。
Kompella & Rekhter Standards Track [Page 8] RFC 4203 OSPF Extensions in MPLS October 2005
Kompella&Rekhter規格は2005年10月にMPLSでRFC4203OSPF拡張子を追跡します[8ページ]。
6. Security Considerations
6. セキュリティ問題
This document specifies the contents of Opaque LSAs in OSPFv2. As Opaque LSAs are not used for SPF computation or normal routing, the extensions specified here have no direct effect on IP routing. Tampering with GMPLS TE LSAs may have an effect on the underlying transport (optical and/or SONET-SDH) network. [OSPF-TE] suggests mechanisms such as [OSPF-SIG] to protect the transmission of this information, and those or other mechanisms should be used to secure and/or authenticate the information carried in the Opaque LSAs.
このドキュメントはOSPFv2でOpaque LSAsのコンテンツを指定します。 Opaque LSAsがSPF計算か正常なルーティングに使用されないとき、ここで指定された拡大はIPルーティングに直接効果を全く持っていません。 GMPLS TE LSAsをいじると影響が基本的な輸送に与えられるかもしれない、(光学、Sonet-SDH) そして/または、ネットワーク。 [OSPF-TE]はこの情報の伝達を保護するために[OSPF-SIG]などのメカニズムを示して、それらか他のメカニズムが、Opaque LSAsで運ばれた情報を安全にする、そして/または、認証するのに使用されるべきです。
7. IANA Considerations
7. IANA問題
The memo introduces four new sub-TLVs of the TE Link TLV in the TE Opaque LSA for OSPF v2; [OSPF-TE] says that the sub-TLVs of the TE Link TLV in the range 10-32767 must be assigned by Expert Review, and must be registered with IANA.
メモはOSPF v2のためにTE Opaque LSAでTE Link TLVの4新しいサブTLVsを導入します。 [OSPF-TE]は範囲のTE Link TLVのサブTLVs10-32767をExpert Reviewが割り当てなければならなくて、IANAに登録しなければならないと言います。
The memo has four suggested values for the four sub-TLVs of the TE Link TLV; it is strongly recommended that the suggested values be granted, as there are interoperable implementations using these values.
メモには、TE Link TLVの4サブTLVsのための4つの提案された値があります。 これらの値を使用する共同利用できる実現があるとき、提案された値が与えられることが強く勧められます。
Finally, a new Top Level Type for OSPF TE LSAs for the Link Local TLV has been allocated from the Standards Action space.
最終的に、Standards ActionスペースからLink Local TLVのためのOSPF TE LSAsのための新しいTop Level Typeを割り当てました。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[GMPLS-ROUTING] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4202, October 2005.
[GMPLSを発送しています]のKompella、K.(エド)、およびY.Rekhter(エド)、「一般化されたマルチプロトコルを支持したルート設定拡大は切り換え(GMPLS)をラベルします」、RFC4202、2005年10月。
[GMPLS-RSVP] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[GMPLS-RSVP] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、2003年1月。
[GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[GMPLS-SIG] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、2003年1月。
[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)。
Kompella & Rekhter Standards Track [Page 9] RFC 4203 OSPF Extensions in MPLS October 2005
Kompella&Rekhter規格は2005年10月にMPLSでRFC4203OSPF拡張子を追跡します[9ページ]。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[OSPF]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[OSPF-RESTART] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful
OSPF Restart", RFC 3623, November 2003.
[OSPF-再開] MoyとJ.とPillay-Esnault、P.とA.Lindem、「優雅なOSPFは再開する」RFC3623、2003年11月。
[OSPF-SIG] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997.
1997年6月の[OSPF-SIG]のマーフィーとS.とムジナ、M.とB.ウェリントン、「デジタル署名があるOSPF」RFC2154。
[OSPF-TE] Katz, D., Kompella, K., and Yeung, D., "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[OSPF-Te] キャッツ、D.、Kompella、K.、およびYeung、D.、「(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月。
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 10] RFC 4203 OSPF Extensions in MPLS October 2005
Kompella&Rekhter規格は2005年10月にMPLSでRFC4203OSPF拡張子を追跡します[10ページ]。
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 11]
Kompella&Rekhter標準化過程[11ページ]
一覧
スポンサーリンク
