[要約] RFC 4257は、SDH/SONETネットワークの制御におけるGMPLSベースのフレームワークを提供しています。このRFCの目的は、SDH/SONETネットワークの制御を効率化し、柔軟性を向上させることです。
Network Working Group G. Bernstein
Request for Comments: 4257 Grotto Networking
Category: Informational E. Mannie
Perceval
V. Sharma
Metanoia, Inc.
E. Gray
Marconi Corporation, plc
December 2005
Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks
一般化されたマルチプロトコルラベルスイッチング（GMPLS）ベースの同期デジタル階層/同期光ネットワーク（SDH/SONET）ネットワークのフレームワーク
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed.
Generalized Multi-Protocolラベルスイッチング（GMPLS）は、MPLSのプロトコル拡張スイートであり、一般的に適用できるようにし、例えば、非パケットベースのスイッチング、特に光スイッチングの制御を含めます。考慮事項の1つは、GMPLSプロトコルを使用して、光輸送ネットワークの制御面をアップグレードすることです。このドキュメントは、同期デジタル階層（SDH）または同期光ネットワーク（SONET）ネットワークを制御することを目的としたGMPLSプロトコルへのこれらの拡張を説明することにより、このプロセスを示しています。SDH/SONETネットワークは、さまざまな理由でこのプロセスの良い例を作成します。このドキュメントは、輸送回路のプロビジョニングに必要な（G）MPLSプロトコル拡張とともに、輸送パスの計算とネットワーク操作に必要な情報を広めるためのGMPLS関連のルーティングプロトコルへの拡張を強調しています。GMPLSコントロールプレーンがSDH/SONETネットワークにもたらす新しい機能（新しい修復方法や多層回路設立など）も議論されています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. MPLS Overview ..............................................3
1.2. SDH/SONET Overview .........................................5
1.3. The Current State of Circuit Establishment in
SDH/SONET Networks .........................................7
1.3.1. Administrative Tasks ................................8
1.3.2. Manual Operations ...................................8
1.3.3. Planning Tool Operation .............................8
1.3.4. Circuit Provisioning ................................8
1.4. Centralized Approach versus Distributed Approach ...........9
1.4.1. Topology Discovery and Resource Dissemination ......10
1.4.2. Path Computation (Route Determination) .............10
1.4.3. Connection Establishment (Provisioning) ............10
1.5. Why SDH/SONET Will Not Disappear Tomorrow .................12
2. GMPLS Applied to SDH/SONET .....................................13
2.1. Controlling the SDH/SONET Multiplex .......................13
2.2. SDH/SONET LSR and LSP Terminology .........................14
3. Decomposition of the GMPLS Circuit-Switching Problem Space .....14
4. GMPLS Routing for SDH/SONET ....................................15
4.1. Switching Capabilities ....................................16
4.1.1. Switching Granularity ..............................16
4.1.2. Signal Concatenation Capabilities ..................17
4.1.3. SDH/SONET Transparency .............................19
4.2. Protection ................................................20
4.3. Available Capacity Advertisement ..........................23
4.4. Path Computation ..........................................24
5. LSP Provisioning/Signaling for SDH/SONET .......................25
5.1. What Do We Label in SDH/SONET? Frames or Circuits? .......25
5.2. Label Structure in SDH/SONET ..............................26
5.3. Signaling Elements ........................................27
6. Summary and Conclusions ........................................29
7. Security Considerations ........................................29
8. Acknowledgements ...............................................30
9. Informative References .........................................31
10. Acronyms ......................................................33
The CCAMP Working Group of the IETF has the goal of extending MPLS [1] protocols to support multiple network layers and new services. This extended MPLS, which was initially known as Multi-Protocol Lambda Switching, is now better referred to as Generalized MPLS (or GMPLS).
IETFのCCAMPワーキンググループには、複数のネットワークレイヤーと新しいサービスをサポートするMPL [1]プロトコルを拡張するという目標があります。最初はマルチプロトコルラムダスイッチングとして知られていたこの拡張MPLSは、一般化されたMPL（またはGMPL）と呼ばれるようになりました。
The GMPLS effort is, in effect, extending IP/MPLS technology to control and manage lower layers. Using the same framework and similar signaling and routing protocols to control multiple layers can not only reduce the overall complexity of designing, deploying, and maintaining networks, but can also make it possible to operate two contiguous layers by using either an overlay model, a peer model, or an integrated model. The benefits of using a peer or an overlay model between the IP layer and its underlying layer(s) will have to be clarified and evaluated in the future. In the mean time, GMPLS could be used for controlling each layer independently.
GMPLSの取り組みは、実際には、低レイヤーを制御および管理するためにIP/MPLSテクノロジーを拡張することです。同じフレームワークと同様のシグナルおよびルーティングプロトコルを使用して複数のレイヤーを制御することは、ネットワークの設計、展開、および維持の全体的な複雑さを軽減するだけでなく、オーバーレイモデル、ピアモデル、または統合モデルのいずれかを使用して2つの連続した層を操作することもできます。IPレイヤーとその基礎となる層の間にピアまたはオーバーレイモデルを使用する利点は、将来明確にして評価する必要があります。それまでの間、GMPLは各層を個別に制御するために使用できます。
The goal of this work is to highlight how GMPLS could be used to dynamically establish, maintain, and tear down SDH/SONET circuits. The objective of using these extended IP/MPLS protocols is to provide at least the same kinds of SDH/SONET services as are provided today, but using signaling instead of provisioning via centralized management to establish those services. This will allow operators to propose new services, and will allow clients to create SDH/SONET paths on-demand, in real-time, through the provider network. We first review the essential properties of SDH/SONET networks and their operations, and we show how the label concept in GMPLS can be extended to the SDH/SONET case. We then look at important information to be disseminated by a link state routing protocol and look at the important signal attributes that need to be conveyed by a label distribution protocol. Finally, we look at some outstanding issues and future possibilities.
この作業の目標は、GMPLを使用してSDH/SONET回路を動的に確立、維持、破壊する方法を強調することです。これらの拡張されたIP/MPLSプロトコルを使用する目的は、現在提供されているものと少なくとも同じ種類のSDH/SONETサービスを提供することですが、集中管理を介してプロビジョニングする代わりにシグナリングを使用してそれらのサービスを確立することです。これにより、オペレーターは新しいサービスを提案することができ、クライアントはプロバイダーネットワークを介してリアルタイムでSDH/SONETパスをオンデマンドで作成できるようになります。まず、SDH/SONETネットワークの重要なプロパティとその操作を確認し、GMPLSのラベルの概念をSDH/SONETケースに拡張する方法を示します。次に、重要な情報をリンク状態ルーティングプロトコルによって普及させることを検討し、ラベル分布プロトコルで伝えられる必要がある重要な信号属性を調べます。最後に、いくつかの顕著な問題と将来の可能性を見ていきます。
A major advantage of the MPLS architecture [1] for use as a general network control plane is its clear separation between the forwarding (or data) plane, the signaling (or connection control) plane, and the routing (or topology discovery/resource status) plane. This allows the work on MPLS extensions to focus on the forwarding and signaling planes, while allowing well-known IP routing protocols to be reused in the routing plane. This clear separation also allows for MPLS to be used to control networks that do not have a packet-based forwarding plane.
一般的なネットワーク制御プレーンとして使用するMPLSアーキテクチャ[1]の主な利点は、転送（またはデータ）プレーン、信号（または接続制御）平面、およびルーティング（またはトポロジの発見/リソースステータス）平面との明確な分離です。これにより、MPLS拡張機能の作業が転送および信号機に焦点を合わせ、よく知られているIPルーティングプロトコルをルーティングプレーンで再利用できるようにします。また、この明確な分離により、MPLを使用して、パケットベースの転送面を持たないネットワークを制御できます。
An MPLS network consists of MPLS nodes called Label Switch Routers (LSRs) connected via Label Switched Paths (LSPs). An LSP is uni-directional and could be of several different types such as point-to-point, point-to-multipoint, and multipoint-to-point. Border LSRs in an MPLS network act as either ingress or egress LSRs, depending on the direction of the traffic being forwarded.
MPLSネットワークは、ラベルスイッチ付きパス（LSP）を介して接続されたラベルスイッチルーター（LSRS）と呼ばれるMPLSノードで構成されています。LSPは単方向であり、ポイントツーポイント、ポイントツーマルチポイント、マルチポイントツーポイントなど、いくつかの異なるタイプがあります。MPLSネットワーク内のBorder LSRは、トラフィックが転送される方向に応じて、LSRSまたは出力のいずれかとして機能します。
Each LSP is associated with a Forwarding Equivalence Class (FEC), which may be thought of as a set of packets that receive identical forwarding treatment at an LSR. The simplest example of an FEC might be the set of destination addresses lying in a given address range. All packets that have a destination address lying within this address range are forwarded identically at each LSR configured with that FEC.
各LSPは、転送等価クラス（FEC）に関連付けられており、これはLSRで同一の転送処理を受けるパケットのセットと考えられる場合があります。FECの最も単純な例は、特定のアドレス範囲にある宛先アドレスのセットです。このアドレス範囲内に宛先アドレスがあるすべてのパケットは、そのFECで構成された各LSRで同じように転送されます。
To establish an LSP, a signaling protocol (or label distribution protocol) such as LDP or RSVP-TE is required. Between two adjacent LSRs, an LSP is locally identified by a fixed length identifier called a label, which is only significant between those two LSRs. A signaling protocol is used for inter-node communication to assign and maintain these labels.
LSPを確立するには、LDPやRSVP-TEなどのシグナル伝達プロトコル（またはラベル分布プロトコル）が必要です。2つの隣接するLSRの間で、LSPはラベルと呼ばれる固定長さの識別子によってローカルに識別されます。これは、これら2つのLSRの間でのみ有意です。シグナリングプロトコルは、これらのラベルを割り当てて維持するためにノード間通信に使用されます。
When a packet enters an MPLS-based packet network, it is classified according to its FEC and, possibly, additional rules, which together determine the LSP along which the packet must be sent. For this purpose, the ingress LSR attaches an appropriate label to the packet, and forwards the packet to the next hop. The label may be attached to a packet in different ways. For example, it may be in the form of a header encapsulating the packet (the "shim" header) or it may be written in the VPI/VCI field (or DLCI field) of the layer 2 encapsulation of the packet. In case of SDH/SONET networks, we will see that a label is simply associated with a segment of a circuit, and is mainly used in the signaling plane to identify this segment (e.g., a time-slot) between two adjacent nodes.
パケットがMPLSベースのパケットネットワークに入ると、FECと、おそらく追加のルールに従って分類され、パケットを送信する必要があるLSPが一緒に決定されます。この目的のために、Ingress LSRは適切なラベルをパケットに取り付け、パケットを次のホップに転送します。ラベルは、さまざまな方法でパケットに取り付けられる場合があります。たとえば、パケット（「シム」ヘッダー）をカプセル化するヘッダーの形であるか、パケットのレイヤー2カプセル化のVPI/VCIフィールド（またはDLCIフィールド）で記述される場合があります。SDH/SONETネットワークの場合、ラベルは単に回路のセグメントに関連付けられており、主に2つの隣接するノード間のこのセグメント（例えば、タイムスロット）を識別するために信号平面で使用されていることがわかります。
When a packet reaches a packet LSR, this LSR uses the label as an index into a forwarding table to determine the next hop and the corresponding outgoing label (and, possibly, the QoS treatment to be given to the packet), writes the new label into the packet, and forwards the packet to the next hop. When the packet reaches the egress LSR, the label is removed and the packet is forwarded using appropriate forwarding, such as normal IP forwarding. We will see that for an SDH/SONET network these operations do not occur in quite the same way.
パケットがパケットLSRに到達すると、このLSRはラベルをインデックスとして転送テーブルに使用して次のホップと対応する発信ラベル（およびおそらく、パケットに与えられるQoS処理）を決定し、新しいラベルをパケットに書き込み、パケットを次のホップに転送します。パケットが出口LSRに到達すると、ラベルが削除され、通常のIP転送などの適切な転送を使用してパケットが転送されます。SDH/SONETネットワークの場合、これらの操作はまったく同じ方法で発生しないことがわかります。
There are currently two different multiplexing technologies in use in optical networks: wavelength-division multiplexing (WDM) and time division multiplexing (TDM). This work focuses on TDM technology.
現在、光学ネットワークで使用されている2つの異なる多重化技術があります：波長分割マルチプレックス（WDM）と時分割多重化（TDM）。この作業は、TDMテクノロジーに焦点を当てています。
SDH and SONET are two TDM standards widely used by operators to transport and multiplex different tributary signals over optical links, thus creating a multiplexing structure, which we call the SDH/SONET multiplex.
SDHとSONETは、オペレーターが光学リンクを介して異なる支流信号を輸送および多重化するために広く使用されている2つのTDM標準であり、SDH/SONETマルチプレックスと呼ばれる多重化構造を作成します。
ITU-T (G.707) [2] includes both the European Telecommunications Standards Institute (ETSI) SDH hierarchy and the USA ANSI SONET hierarchy [3]. The ETSI SDH and SONET standards regarding frame structures and higher-order multiplexing are the same. There are some regional differences in terminology, on the use of some overhead bytes, and lower-order multiplexing. Interworking between the two lower-order hierarchies is possible using gateways.
ITU-T（G.707）[2]には、欧州通信標準研究所（ETSI）SDH階層と米国ANSIソネット階層の両方が含まれています[3]。フレーム構造と高次の多重化に関するETSI SDHおよびSONET標準は同じです。いくつかのオーバーヘッドバイトの使用、および低次の多重化には、用語にいくつかの地域の違いがあります。ゲートウェイを使用して、2つの低次の階層間のインターワーキングが可能です。
The fundamental signal in SDH is the STM-1 that operates at a rate of about 155 Mbps, while the fundamental signal in SONET is the STS-1 that operates at a rate of about 51 Mbps. These two signals are made of contiguous frames that consist of transport overhead (header) and payload. To solve synchronization issues, the actual data is not transported directly in the payload, but rather in another internal frame that is allowed to float over two successive SDH/SONET payloads. This internal frame is named a Virtual Container (VC) in SDH and a SONET Payload Envelope (SPE) in SONET.
SDHの基本信号は、約155 Mbpsの速度で動作するSTM-1であり、SONETの基本信号は約51 Mbpsの速度で動作するSTS-1です。これらの2つの信号は、トランスポートオーバーヘッド（ヘッダー）とペイロードで構成される連続フレームで作られています。同期の問題を解決するために、実際のデータはペイロードに直接輸送されるのではなく、2つの連続したSDH/SONETペイロードに浮かぶ可能性のある別の内部フレームに輸送されます。この内部フレームは、SDHの仮想コンテナ（VC）とSONETのソネットペイロードエンベロープ（SPE）と呼ばれます。
The SDH/SONET architecture identifies three different layers, each of which corresponds to one level of communication between SDH/SONET equipment. These are, starting with the lowest, the regenerator section/section layer, the multiplex section/line layer, and (at the top) the path layer. Each of these layers, in turn, has its own overhead (header). The transport overhead of an SDH/SONET frame is mainly sub-divided in two parts that contain the regenerator section/section overhead and the multiplex section/line overhead. In addition, a pointer (in the form of the H1, H2, and H3 bytes) indicates the beginning of the VC/SPE in the payload of the overall STM/STS frame.
SDH/SONETアーキテクチャは、3つの異なるレイヤーを識別し、それぞれがSDH/SONET機器間の1つのレベルの通信に対応しています。これらは、最低の再生器セクション/セクションレイヤー、マルチプレックスセクション/ラインレイヤー、および（上部）パスレイヤーから始まります。これらのそれぞれのレイヤーには、独自のオーバーヘッド（ヘッダー）があります。SDH/SONETフレームの輸送オーバーヘッドは、主に再生器セクション/セクションオーバーヘッドとマルチプレックスセクション/ラインオーバーヘッドを含む2つの部分で下位区分されています。さらに、ポインター（H1、H2、およびH3バイトの形式）は、STM/STSフレーム全体のペイロードにおけるVC/SPEの始まりを示します。
The VC/SPE itself is made up of a header (the path overhead) and a payload. This payload can be further subdivided into sub-elements (signals) in a fairly complex way. In the case of SDH, the STM-1 frame may contain either one VC-4 or three multiplexed VC-3s. The SONET multiplex is a pure tree, while the SDH multiplex is not a pure tree, since it contains a node that can be attached to two parent nodes. The structure of the SDH/SONET multiplex is shown in Figure 1. In addition, we show reference points in this figure that are explained in later sections.
VC/SPE自体は、ヘッダー（パスオーバーヘッド）とペイロードで構成されています。このペイロードは、かなり複雑な方法でサブエレメント（信号）にさらに細分化できます。SDHの場合、STM-1フレームには、1つのVC-4または3つの多重化VC-3を含めることができます。Sonet Multiplexは純粋なツリーですが、SDHマルチプレックスは2つの親ノードに取り付けられるノードが含まれているため、純粋なツリーではありません。SDH/SONETマルチプレックスの構造を図1に示します。さらに、後のセクションで説明するこの図の基準点を示します。
The leaves of these multiplex structures are time slots (positions) of different sizes that can contain tributary signals. These tributary signals (e.g., E1, E3, etc) are mapped into the leaves using standardized mapping rules. In general, a tributary signal does not fill a time slot completely, and the mapping rules define precisely how to fill it.
これらのマルチプレックス構造の葉は、支流信号を含む可能性のあるさまざまなサイズのタイムスロット（位置）です。これらの支流信号（E1、E3など）は、標準化されたマッピングルールを使用して葉にマッピングされます。一般に、支流信号はタイムスロットを完全に埋めることはなく、マッピングルールはそれを埋める方法を正確に定義します。
What is important for the GMPLS-based control of SDH/SONET circuits is to identify the elements that can be switched from an input multiplex on one interface to an output multiplex on another interface. The only elements that can be switched are those that can be re-aligned via a pointer, i.e., a VC-x in the case of SDH and a SPE in the case of SONET.
SDH/SONET回路のGMPLSベースの制御にとって重要なのは、あるインターフェイスの入力マルチプレックスから別のインターフェイスの出力マルチプレックスに切り替えることができる要素を識別することです。切り替えることができる唯一の要素は、ポインターを介して再編成できる要素、つまりSDHの場合のVC-XとSONETの場合のSPEです。
xN x1
STM-N<----AUG<----AU-4<--VC4<------------------------------C-4 E4
^ ^
Ix3 Ix3
I I x1
I -----TUG-3<----TU-3<---VC-3<---I
I ^ C-3 DS3/E3
STM-0<------------AU-3<---VC-3<-- I ---------------------I
^ I
Ix7 Ix7
I I x1
-----TUG-2<---TU-2<---VC-2<---C-2 DS2/T2
^ ^
I I x3
I I----TU-12<---VC-12<--C-12 E1
I
I x4
I-------TU-11<---VC-11<--C-11 DS1/T1
xN
STS-N<-------------------SPE<------------------------------DS3/T3
^
Ix7
I x1
I---VT-Group<---VT-6<----SPE DS2/T2
^ ^ ^
I I I x2
I I I-----VT-3<----SPE DS1C
I I
I I x3
I I--------VT-2<----SPE E1
I
I x4
I-----------VT-1.5<--SPE DS1/T1
Figure 1. SDH and SONET multiplexing structure and typical Plesiochronous Digital Hierarchy (PDH) payload signals.
図1. SDHおよびSONET多重化構造と典型的なプレシオクロナスデジタル階層（PDH）ペイロード信号。
An STM-N/STS-N signal is formed from N x STM-1/STS-1 signals via byte interleaving. The VCs/SPEs in the N interleaved frames are independent and float according to their own clocking. To transport tributary signals in excess of the basic STM-1/STS-1 signal rates, the VCs/SPEs can be concatenated, i.e., glued together. In this case, their relationship with respect to each other is fixed in time; hence, this relieves, when possible, an end system of any inverse multiplexing bonding processes. Different types of concatenations are defined in SDH/SONET.
STM-N/STS-N信号は、バイトインターリーブを介してN x STM-1/STS-1シグナルから形成されます。NインターリーブフレームのVCS/SPEは独立しており、独自のクロッキングに従って浮かんでいます。基本的なSTM-1/STS-1シグナル速度を超える支流信号を輸送するために、VCS/SPEを連結すること、つまり接着することができます。この場合、互いに対する関係は時間内に固定されています。したがって、これは、可能であれば、あらゆる逆マルチプレックスボンディングプロセスの最終システムを解放します。さまざまなタイプの連結がSDH/SONETで定義されています。
For example, standard SONET concatenation allows the concatenation of
M x STS-1 signals within an STS-N signal with M <= N, and M = 3, 12,
48, 192, .... The SPEs of these M x STS-1s can be concatenated to
form an STS-Mc. The STS-Mc notation is short hand for describing an
STS-M signal whose SPEs have been concatenated.
In present day SDH and SONET networks, the networks are primarily statically configured. When a client of an operator requests a point-to-point circuit, the request sets in motion a process that can last for several weeks or more. This process is composed of a chain of shorter administrative and technical tasks, some of which can be fully automated, resulting in significant improvements in provisioning time and in operational savings. In the best case, the entire process can be fully automated allowing, for example, customer premise equipment (CPE) to contact an SDH/SONET switch to request a circuit. Currently, the provisioning process involves the following tasks.
現在のSDHおよびSONETネットワークでは、ネットワークは主に静的に構成されています。オペレーターのクライアントがポイントツーポイントサーキットを要求する場合、リクエストは数週間以上続くプロセスを動かします。このプロセスは、より短い管理および技術的タスクのチェーンで構成されており、その一部は完全に自動化できるため、プロビジョニング時間と運用貯蓄が大幅に改善されます。最良の場合、プロセス全体を完全に自動化することができ、たとえば、顧客の前提装備（CPE）がSDH/SONETスイッチに連絡して回路を要求できます。現在、プロビジョニングプロセスには、次のタスクが含まれます。
The administrative tasks represent a significant part of the provisioning time. Most of them can be automated using IT applications, e.g., a client still has to fill a form to request a circuit. This form can be filled via a Web-based application and can be automatically processed by the operator. A further enhancement is to allow the client's equipment to coordinate with the operator's network directly and request the desired circuit. This could be achieved through a signaling protocol at the interface between the client equipment and an operator switch, i.e., at the UNI, where GMPLS signaling [4], [5] can be used.
管理タスクは、プロビジョニング時間の重要な部分を表しています。それらのほとんどは、ITアプリケーションを使用して自動化できます。たとえば、クライアントはまだ回路を要求するためにフォームに入力する必要があります。このフォームは、Webベースのアプリケーションを介して入力でき、オペレーターによって自動的に処理できます。さらに強化されているのは、クライアントの機器がオペレーターのネットワークと直接調整し、目的の回路を要求できるようにすることです。これは、クライアント機器とオペレータースイッチの間のインターフェースで、つまりGMPLSシグナル[4]、[5]を使用できるUNIでのシグナル伝達プロトコルを通じて達成できます。
Another significant part of the time may be consumed by manual operations that involve installing the right interface in the CPE and installing the right cable or fiber between the CPE and the operator switch. This time can be especially significant when a client is in a different time zone than the operator's main office. This first-time connection time is frequently accounted for in the overall establishment time.
時間の別の重要な部分は、CPEに右のインターフェイスをインストールし、CPEとオペレータースイッチの間に右のケーブルまたはファイバーを取り付けることを含む手動操作によって消費される場合があります。クライアントがオペレーターのメインオフィスとは異なるタイムゾーンにいる場合、今回は特に重要です。この最初の接続時間は、全体的な設立時間で頻繁に説明されます。
Another portion of the time is consumed by planning tools that run simulations using heuristic algorithms to find an optimized placement for the required circuits. These planning tools can require a significant running time, sometimes on the order of days.
時間の別の部分は、ヒューリスティックアルゴリズムを使用してシミュレーションを実行して、必要な回路の最適化された配置を見つけることで消費されます。これらの計画ツールには、時には日が順に、かなりの実行時間が必要になる場合があります。
These simulations are, in general, executed for a set of demands for circuits, i.e., a batch mode, to improve the optimality of network resource usage and other parameters. Today, we do not really have a means to reduce this simulation time. On the contrary, to support fast, on-line, circuit establishment, this phase may be invoked more frequently, i.e., we will not "batch up" as many connection requests before we plan out the corresponding circuits. This means that the network may need to be re-optimized periodically, implying that the signaling should support re-optimization with minimum impact to existing services.
これらのシミュレーションは、一般に、ネットワークリソースの使用やその他のパラメーターの最適性を改善するために、回路の一連の需要、つまりバッチモードのために実行されます。今日、このシミュレーション時間を短縮する手段は実際にはありません。それどころか、高速でオンラインの回路設立をサポートするために、このフェーズはより頻繁に呼び出される可能性があります。つまり、対応する回路を計画する前に、多くの接続要求を「バッチアップ」しません。これは、ネットワークが定期的に再最適化される必要があることを意味し、シグナリングが既存のサービスに最小限の影響を与えて再最適化をサポートすることを意味します。
Once the first three steps discussed above have been completed, the operator must provision the circuits using the outputs of the planning process. The time required for provisioning varies greatly. It can be fairly short, on the order of a few minutes, if the operators already have tools that help them to do the provisioning over heterogeneous equipment. Otherwise, the process can take days. Developing these tools for each new piece of equipment and each vendor is a significant burden on the service provider. A standardized interface for provisioning, such as GMPLS signaling, could significantly reduce or eliminate this development burden. In general, provisioning is a batched activity, i.e., a few times per week an operator provisions a set of circuits. GMPLS will reduce this provisioning time from a few minutes to a few seconds and could help to transform this periodic process into a real-time process.
上記の最初の3つの手順が完了したら、オペレーターは計画プロセスの出力を使用して回路をプロビジョニングする必要があります。プロビジョニングに必要な時間は大きく異なります。オペレーターが既に不均一な機器を介してプロビジョニングを行うのに役立つツールを既に持っている場合、数分の順序でかなり短い場合があります。それ以外の場合、プロセスには数日かかる場合があります。新しい機器と各ベンダーのこれらのツールを開発することは、サービスプロバイダーに大きな負担です。GMPLSシグナル伝達などのプロビジョニング用の標準化されたインターフェイスは、この開発の負担を大幅に削減または排除する可能性があります。一般に、プロビジョニングはバッチアクティビティです。つまり、週に数回オペレーターが回路のセットを提供します。GMPLは、このプロビジョニング時間を数分から数秒に短縮し、この定期的なプロセスをリアルタイムプロセスに変換するのに役立ちます。
When a circuit is provisioned, it is not delivered directly to a client. Rather, the operator first tests its performance and behavior and, if successful, delivers the circuit to the client. This testing phase lasts, in general, up to 24 hours. The operator installs test equipment at each end and uses pre-defined test streams to verify performance. If successful, the circuit is officially accepted by the client. To speed up the verification (sometimes known as "proving") process, it would be necessary to support some form of automated performance testing.
回路がプロビジョニングされている場合、クライアントに直接配信されません。むしろ、オペレーターは最初にそのパフォーマンスと動作をテストし、成功した場合、クライアントに回路を配信します。このテストフェーズは、一般に、最大24時間続きます。オペレーターは両端にテスト機器をインストールし、事前に定義されたテストストリームを使用してパフォーマンスを確認します。成功した場合、回路はクライアントによって正式に受け入れられます。検証（「証明」と呼ばれることもある）プロセスをスピードアップするには、何らかの形の自動パフォーマンステストをサポートする必要があります。
Whether a centralized approach or a distributed approach will be used to control SDH/SONET networks is an open question, since each approach has its merits. The application of GMPLS to SDH/SONET networks does not preclude either model, although GMPLS is itself a distributed technology.
集中型アプローチまたは分散アプローチを使用して、SDH/SONETネットワークを制御するために使用されるかどうかは、各アプローチにメリットがあるため、未解決の問題です。GMPLSはどちらのモデルも排除するものではありませんが、GMPLSをSDH/SONETネットワークに適用することは、それ自体が分散テクノロジーです。
The basic tradeoff between the centralized and distributed approaches is that of complexity of the network elements versus that of the network management system (NMS). Since adding functionality to existing SDH/SONET network elements may not be possible, a centralized approach may be needed in some cases. The main issue facing centralized control via an NMS is one of scalability. For instance, this approach may be limited in the number of network elements that can be managed (e.g., one thousand). It is, therefore, quite common for operators to deploy several NMS in parallel at the Network Management Layer, each managing a different zone. In that case, however, a Service Management Layer must be built on the top of several individual NMS to take care of end-to-end on-demand services. On the other hand, in a complex and/or dense network, restoration could be faster with a distributed approach than with a centralized approach.
集中化されたアプローチと分散アプローチの間の基本的なトレードオフは、ネットワーク要素の複雑さとネットワーク管理システム（NMS）のトレードオフです。既存のSDH/SONETネットワーク要素に機能を追加することは不可能な場合があるため、場合によっては集中的なアプローチが必要になる場合があります。NMSを介した集中制御が直面している主な問題は、スケーラビリティの1つです。たとえば、このアプローチは、管理できるネットワーク要素の数（たとえば、1000）に制限される場合があります。したがって、オペレーターがネットワーク管理レイヤーに複数のNMを並行して展開することは非常に一般的であり、それぞれが異なるゾーンを管理しています。ただし、その場合、エンドツーエンドのオンデマンドサービスの世話をするには、いくつかの個別のNMの上部にサービス管理層を構築する必要があります。一方、複雑なネットワークや密度の高いネットワークでは、集中的なアプローチよりも分散アプローチの方が速くなる可能性があります。
Let's now look at how the major control plane functional components are handled via the centralized and distributed approaches:
次に、主要なコントロールプレーンの機能コンポーネントが集中化され、分散されたアプローチを介してどのように処理されるかを見てみましょう。
Currently, an NMS maintains a consistent view of all the networking layers under its purview. This can include the physical topology, such as information about fibers and ducts. Since most of this information is entered manually, it remains error prone.
現在、NMSは、すべてのネットワークレイヤーの一貫したビューをその範囲で維持しています。これには、繊維やダクトに関する情報などの物理的トポロジーが含まれます。この情報のほとんどは手動で入力されるため、エラーが発生しやすいままです。
A link state GMPLS routing protocol, on the other hand, could perform automatic topology discovery and disseminate the topology as well as resource status. This information would be available to all nodes in the network, and hence also the NMS. Hence, one can look at a continuum of functionality between manually provisioned topology information (of which there will always be some) and fully automated discovery and dissemination (as in a link state protocol). Note that, unlike the IP datagram case, a link state routing protocol applied to the SDH/SONET network does not have any service impacting implications. This is because in the SDH/SONET case, the circuit is source-routed (so there can be no loops), and no traffic is transmitted until a circuit has been established and an acknowledgement received at the source.
一方、リンク状態GMPLSルーティングプロトコルは、自動トポロジの発見を実行し、トポロジとリソースステータスを広めることができます。この情報は、ネットワーク内のすべてのノードが利用できるため、NMSも利用できます。したがって、手動でプロビジョニングされたトポロジ情報（常にあるものがある）と完全に自動化された発見と普及（リンク状態プロトコルのように）の間の連続性を見ることができます。IPデータグラムのケースとは異なり、SDH/SONETネットワークに適用されるリンク状態ルーティングプロトコルには、影響に影響を与えるサービスはないことに注意してください。これは、SDH/SONETのケースでは、回路がソースルーティング（ループがない可能性があるため）であり、回路が確立され、ソースで確認が受信されるまでトラフィックが送信されないためです。
In the SDH/SONET case, unlike the IP datagram case, there is no need for network elements to all perform the same path calculation [6]. In addition, path determination is an area for vendors to provide a potentially significant value addition in terms of network efficiency, reliability, and service differentiation. In this sense, a centralized approach to path computation may be easier to operate and upgrade. For example, new features such as new types of path diversity or new optimization algorithms can be introduced with a simple NMS software upgrade. On the other hand, updating switches with new path computation software is a more complicated task. In addition, many of the algorithms can be fairly computationally intensive and may be completely unsuitable for the embedded processing environment available on most switches. In restoration scenarios, the ability to perform a reasonably sophisticated level of path computation on the network element can be particularly useful for restoring traffic during major network faults.
SDH/SONETの場合、IPデータグラムの場合とは異なり、ネットワーク要素はすべて同じパス計算を実行する必要はありません[6]。さらに、パスの決定は、ベンダーがネットワークの効率、信頼性、およびサービスの差別化に関して潜在的に重要な価値を追加する領域です。この意味で、パス計算への集中化されたアプローチは、操作とアップグレードが容易になる場合があります。たとえば、新しいタイプのパスダイバーシティや新しい最適化アルゴリズムなどの新機能は、シンプルなNMSソフトウェアアップグレードで導入できます。一方、新しいパス計算ソフトウェアでスイッチを更新することは、より複雑なタスクです。さらに、アルゴリズムの多くはかなり計算集中的である可能性があり、ほとんどのスイッチで利用可能な埋め込み処理環境には完全に不適切な場合があります。復元シナリオでは、ネットワーク要素で合理的に洗練されたレベルのパス計算を実行する機能は、主要なネットワーク障害中のトラフィックの回復に特に役立ちます。
The actual setting up of circuits, i.e., a coupled collection of cross connects across a network, can be done either via the NMS setting up individual cross connects or via a "soft permanent LSP" (SPLSP) type approach. In the SPLSP approach, the NMS may just kick off the connection at the "ingress" switch with GMPLS signaling setting up the connection from that point onward. Connection establishment is the trickiest part to distribute, however, since errors in the connection setup/tear down process are service impacting.
サーキットの実際のセットアップ、つまり、ネットワーク全体のクロスコネクトの結合コレクションは、個々のクロスコネクトをセットアップするNMSまたは「ソフトパーマネントLSP」（SPLSP）タイプのアプローチを介して行うことができます。SPLSPアプローチでは、NMSは、GMPLSシグナリングがその時点から接続をセットアップする「Ingress」スイッチで接続をキックオフするだけです。ただし、接続のセットアップ/解体プロセスのエラーがサービスに影響を与えるため、接続確立は分配するのが最も難しい部分です。
The table below compares the two approaches to connection establishment.
以下の表は、接続確立に対する2つのアプローチを比較しています。
Table 1. Qualitative comparison between centralized and distributed approaches.
表1.集中型と分散型アプローチの定性的比較。
Distributed approach Centralized approach
分散アプローチ集中アプローチ
Packet-based control plane Management plane like TMN or (like GMPLS or PNNI) useful? SNMP Do we really need it? Being Always needed! Already there, added/specified by several proven and understood. standardization bodies
TMNのようなパケットベースのコントロールプレーン管理プレーンまたは（GMPLSやPNNIなど）便利ですか？SNMP私たちは本当にそれを必要としていますか？常に必要です！すでにそこに、いくつかの実証済みと理解されたいくつかによって追加/指定されています。標準化機関
High survivability (e.g., in Potential single point(s) of case of partition) failure
高い生存性（たとえば、パーティションの場合の潜在的な単一点）障害
Distributed load Bottleneck: #requests and actions to/from NMS
分散型ロードボトルネック：#Requests andアクションNMSからのアクション
Individual local routing Centralized routing decision,
decision can be done per block of
requests
Routing scalable as for the Assumes a few big
Internet administrative domains
Complex to change routing Very easy local upgrade (non-protocol/algorithm intrusive)
ルーティングを変更する複雑なローカルアップグレード（非プロトコル/アルゴリズムの邪魔になる）
Requires enhanced routing Better consistency protocol (traffic engineering)
強化されたルーティングを必要とする一貫性プロトコル（トラフィックエンジニアリング）
Ideal for inter-domain Not inter-domain friendly
ドメイン間にやさしくないドメイン間に最適です
Suitable for very dynamic For less dynamic demands demands (longer lived)
よりダイナミックな要求の要求に応じて非常にダイナミックに適しています（長生き）
Probably faster to restore, Probably slower to restore,but but more difficult to have could effect reliable reliable restoration. restoration.
おそらく復元がより速く、おそらく復元が遅くなりますが、信頼できる信頼できる復元に影響を与える可能性があります。復元。
High scalability Limited scalability: #nodes,
(hierarchical) links, circuits, messages
Planning (optimization) Planning is a background
harder to achieve centralized activity
Easier future integration with other control plane layers
他のコントロールプレーンレイヤーとの将来の統合が簡単です
As IP traffic becomes the dominant traffic transported over the transport infrastructure, it is useful to compare the statistical multiplexing of IP with the time division multiplexing of SDH and SONET.
IPトラフィックが輸送インフラストラクチャに輸送される支配的なトラフィックになると、IPの統計的多重化とSDHおよびSONETの時分割多重化を比較することが有用です。
Consider, for instance, a scenario where IP over WDM is used everywhere and lambdas are optically switched. In such a case, a carrier's carrier would sell dynamically controlled lambdas with each customers building their own IP backbones over these lambdas.
たとえば、WDMを介したIPがどこでも使用され、ラムダが光学的に切り替えられるシナリオを検討してください。このような場合、キャリアのキャリアは動的に制御されたラムダを販売し、各顧客がこれらのラムダの上に独自のIPバックボーンを構築します。
This simple model implies that a carrier would sell lambdas instead of bandwidth. The carrier's goal will be to maximize the number of wavelengths/lambdas per fiber, with each customer having to fully support the cost for each end-to-end lambda whether or not the wavelength is fully utilized. Although, in the near future, we may have technology to support up to several hundred lambdas per fiber, a world where lambdas are so cheap and abundant that every individual customer buys them, from one point to any other point, appears an unlikely scenario today.
この単純なモデルは、キャリアが帯域幅の代わりにラムダを販売することを意味します。キャリアの目標は、ファイバーあたりの波長/ラムダの数を最大化することです。各顧客は、波長が完全に利用されているかどうかにかかわらず、各エンドツーエンドのラムダのコストを完全にサポートする必要があります。近い将来、繊維あたり数百匹のラムダをサポートする技術があるかもしれませんが、ラムダが非常に安くて豊富な世界では、すべての個々の顧客がある時点から他のポイントまで購入することは、今日はありそうもないシナリオのように見えます。
More realistically, there is still room for a multiplexing technology that provides circuits with a lower granularity than a wavelength. (Not everyone needs a minimum of 10 Gbps or 40 Gbps per circuit, and IP does not yet support all telecom applications in bulk efficiently.)
より現実的には、波長よりも粒度が低い回路を提供する多重化技術の余地がまだあります。（誰もが回路あたり最低10 gbpsまたは40 gbpsを必要とするわけではなく、IPはすべての通信アプリケーションをバルク効率的にまだサポートしていません。）
SDH and SONET possess a rich multiplexing hierarchy that permits fairly fine granularity and that provides a very cheap and simple physical separation of the transported traffic between circuits, i.e., QoS. Moreover, even IP datagrams cannot be transported directly over a wavelength. A framing or encapsulation is always required to delimit IP datagrams. The Total Length field of an IP header cannot be trusted to find the start of a new datagram, since it could be corrupted and would result in a loss of synchronization. The typical framing used today for IP over Dense WDM (DWDM) is defined in RFC1619/RFC2615 and is known as POS (Packet Over SDH/SONET), i.e., IP over PPP (in High-Level Data Link Control (HDLC)-like format) over SDH/SONET. SDH and SONET are actually efficient encapsulations for IP. For instance, with an average IP datagram length of 350 octets, an IP over Gigabit Ethernet (GbE) encapsulation using an 8B/10B encoding results in 28% overhead, an IP/ATM/SDH encapsulation results in 22% overhead, and an IP/PPP/SDH encapsulation results in only 6% overhead.
SDHとSONETは、かなり細かい粒度を可能にし、回路間の輸送されたトラフィック、つまりQOSの非常に安価でシンプルな物理的分離を提供する豊富な多重階層を持っています。さらに、IPデータグラムでさえ波長を直接輸送することはできません。IPデータグラムを区切るには、常にフレーミングまたはカプセル化が必要です。IPヘッダーの総長さフィールドは、新しいデータグラムの開始を見つけることを信頼することはできません。これは、破損し、同期が失われる可能性があるためです。密度の高いWDM（DWDM）に今日使用されている典型的なフレーミングは、RFC1619/RFC2615で定義されており、POS（SDH/SONET上のパケット）、つまりPPP上（高レベルのデータリンクコントロール（HDLC）-like形式）/sdh/sonetのppp上のIPとして知られています。SDHとSONETは、実際にはIPの効率的なカプセルです。たとえば、平均IPデータグラムの長さは350オクテットで、8B/10Bエンコードを使用したギガビットイーサネット（GBE）のカプセル化は28％オーバーヘッドになり、IP/ATM/SDHカプセル化は22％オーバーヘッドになり、IP/PPP/SDHカプセル化はわずか6％のオーバーヘッドになります。
Any encapsulation of IP over WDM should, in the data plane, at least provide the following: error monitoring capabilities (to detect signal degradation); error correction capabilities, such as FEC (Forward Error Correction) that are particularly needed for ultra long haul transmission; and sufficient timing information, to allow robust synchronization (that is, to detect the beginning of a packet). In the case where associated signaling is used (that is, where the control and data plane topologies are congruent), the encapsulation should also provide the capacity to transport signaling, routing, and management messages, in order to control the optical switches. Rather, SDH and SONET cover all these aspects natively, except FEC, which tends to be supported in a proprietary way. (We note, however, that associated signaling is not a requirement for the GMPLS-based control of SDH/SONET networks. Rather, it is just one option. Non associated signaling, as would happen with an out-of-band control plane network is another equally valid option.)
WDMを介したIPのカプセル化は、データプレーンでは、少なくとも以下を提供する必要があります。エラー監視機能（信号分解を検出するため）。超長距離伝送に特に必要なFEC（前方エラー補正）などのエラー修正機能。堅牢な同期（つまり、パケットの開始を検出するため）を可能にするための十分なタイミング情報。関連するシグナル伝達が使用される場合（つまり、コントロールおよびデータプレーントポロジが一致する場合）、カプセル化は、光スイッチを制御するために、信号、ルーティング、および管理メッセージを輸送する能力も提供する必要があります。むしろ、SDHとSONETは、これらのすべての側面をネイティブにカバーしています。ただし、FECは独自の方法でサポートされる傾向があります。（ただし、関連するシグナル伝達は、SDH/SONETネットワークのGMPLSベースの制御の要件ではないことに注意してください。むしろ、それは1つのオプションにすぎません。帯域外のコントロールプレーンネットワークで起こるように、関連するシグナリングは別の等しく有効なオプションです。）
Since IP encapsulated in SDH/SONET is efficient and widely used, the only real difference between an IP over WDM network and an IP over SDH over WDM network is the layers at which the switching or forwarding can take place. In the first case, it can take place at the IP and optical layers. In the second case, it can take place at the IP, SDH/SONET, and optical layers.
SDH/SONETでカプセル化されたIPは効率的で広く使用されているため、WDMネットワークを介したIPとSDH上のIPをWDMネットワーク上のIPの唯一の実際の違いは、スイッチングまたは転送が行われるレイヤーです。最初のケースでは、IPおよび光学層で行われます。2番目のケースでは、IP、SDH/SONET、および光レイヤーで行われます。
Almost all transmission networks today are based on SDH or SONET. A client is connected either directly through an SDH or SONET interface or through a PDH interface, the PDH signal being transported between the ingress and the egress interfaces over SDH or SONET. What we are arguing here is that it makes sense to do switching or forwarding at all these layers.
今日のほとんどすべての送信ネットワークは、SDHまたはSONETに基づいています。クライアントは、SDHまたはSONETインターフェイスまたはPDHインターフェイスを介して直接接続されます。PDH信号は、SDHまたはSONET上の侵入インターフェイスと出口インターフェイスの間に輸送されます。ここで私たちが主張しているのは、これらすべてのレイヤーで切り替えまたは転送を行うことが理にかなっているということです。
Controlling the SDH/SONET multiplex implies deciding which of the different switchable components of the SDH/SONET multiplex we wish to control using GMPLS. Essentially, every SDH/SONET element that is referenced by a pointer can be switched. These component signals are the VC-4, VC-3, VC-2, VC-12, and VC-11 in the SDH case; and the VT and STS SPEs in the SONET case. The SPEs in SONET do not have individual names, although they can be referred to simply as VT-N SPEs. We will refer to them by identifying the structure that contains them, namely STS-1, VT-6, VT-3, VT-2, and VT-1.5.
SDH/SONETマルチプレックスを制御することは、GMPLSを使用して制御したいSDH/SONETマルチプレックスのさまざまな切り替え可能なコンポーネントのどれを決定することを意味します。基本的に、ポインターによって参照されるすべてのSDH/SONET要素を切り替えることができます。これらのコンポーネント信号は、SDHの場合のVC-4、VC-3、VC-2、VC-12、およびVC-11です。ソネットの場合のVTおよびSTS SPE。SONETのSPEには個々の名前はありませんが、単にVT-N SPEと呼ぶことができます。それらを含む構造、すなわちSTS-1、VT-6、VT-3、VT-2、およびVT-1.5を識別することにより、それらを参照します。
The STS-1 SPE corresponds to a VC-3, a VT-6 SPE corresponds to a VC-2, a VT-2 SPE corresponds to a VC-12, and a VT-1.5 SPE corresponds to a VC-11. The SONET VT-3 SPE has no correspondence in SDH, however SDH's VC-4 corresponds to SONET's STS-3c SPE.
STS-1 SPEはVC-3に対応し、VT-6 SPEはVC-2に対応し、VT-2 SPEはVC-12に対応し、VT-1.5 SPEはVC-11に対応します。SONET VT-3 SPEはSDHには対応していませんが、SDHのVC-4はSONETのSTS-3C SPEに対応しています。
In addition, it is possible to concatenate some of the structures that contain these elements to build larger elements. For instance, SDH allows the concatenation of X contiguous AU-4s to build a VC-4-Xc and of m contiguous TU-2s to build a VC-2-mc. In that case, a VC-4- Xc or a VC-2-mc can be switched and controlled by GMPLS. SDH also defines virtual (non-contiguous) concatenation of TU-2s; however, in that case, each constituent VC-2 is switched individually.
さらに、これらの要素を含む構造の一部を連結して、より大きな要素を構築することができます。たとえば、SDHは、X連続AU-4の連結を許可し、VC-4-XCとM連続TU-2を構築してVC-2-MCを構築します。その場合、VC-4- XCまたはVC-2-MCをGMPLSによって切り替えて制御できます。SDHは、Tu-2の仮想（依存のない）連結も定義します。ただし、その場合、各構成VC-2は個別に切り替えられます。
Let an SDH or SONET Terminal Multiplexer (TM), Add-Drop Multiplexer (ADM), or cross-connect (i.e., a switch) be called an SDH/SONET LSR. An SDH/SONET path or circuit between two SDH/SONET LSRs now becomes a GMPLS LSP. An SDH/SONET LSP is a logical connection between the point at which a tributary signal (client layer) is adapted into its virtual container, and the point at which it is extracted from its virtual container.
SDHまたはSONETターミナルマルチプレクサ（TM）、アドロップマルチプレクサ（ADM）、またはクロスコネクト（つまり、スイッチ）をSDH/SONET LSRと呼びます。2つのSDH/SONET LSRの間のSDH/SONETパスまたは回路がGMPLS LSPになりました。SDH/SONET LSPは、支流信号（クライアントレイヤー）が仮想コンテナに適合しているポイントと、仮想コンテナから抽出されるポイントとの間の論理的な接続です。
To establish such an LSP, a signaling protocol is required to configure the input interface, switch fabric, and output interface of each SDH/SONET LSR along the path. An SDH/SONET LSP can be point-to-point or point-to-multipoint, but not multipoint-to-point, since no merging is possible with SDH/SONET signals.
このようなLSPを確立するには、パスに沿った各SDH/SONET LSRの入力インターフェイス、スイッチファブリック、および出力インターフェイスを構成するために、シグナリングプロトコルが必要です。SDH/SONET LSPは、SDH/SONET信号とのマージが不可能なため、ポイントツーポイントまたはポイントツーマルチポイントではありませんが、マルチポイントツーポイントではありません。
To facilitate the signaling and setup of SDH/SONET circuits, an SDH/SONET LSR must, therefore, identify each possible signal individually per interface, since each signal corresponds to a potential LSP that can be established through the SDH/SONET LSR. It turns out, however, that not all SDH signals correspond to an LSP and therefore not all of them need be identified. In fact, only those signals that can be switched need identification.
SDH/SONET回路のシグナルとセットアップを容易にするために、SDH/SONET LSRは、各信号がSDH/SONET LSRを介して確立できる潜在的なLSPに対応するため、インターフェイスごとに各可能な信号を個別に識別する必要があります。ただし、すべてのSDH信号がLSPに対応しているわけではないため、それらのすべてを識別する必要があるわけではないことがわかります。実際、切り替えることができる信号のみが識別が必要です。
Although those familiar with GMPLS may be familiar with its application in a variety of application areas (e.g., ATM, Frame Relay, and so on), here we quickly review its decomposition when applied to the optical switching problem space.
GMPLSに精通している人は、さまざまなアプリケーション領域（ATM、フレームリレーなど）でのアプリケーションに精通している可能性がありますが、ここでは、光スイッチングの問題スペースに適用した場合、その分解をすばやく確認します。
(i) Information needed to compute paths must be made globally available throughout the network. Since this is done via the link state routing protocol, any information of this nature must either be in the existing link state advertisements (LSAs) or the LSAs must be supplemented to convey this information. For example, if it is desirable to offer different levels of service in a network, based on whether a circuit is routed over SDH/SONET lines that are ring protected versus being routed over those that are not ring protected (differentiation based on reliability), the type of protection on a SDH/SONET line would be an important topological parameter that would have to be distributed via the link state routing protocol.
(i) パスを計算するために必要な情報は、ネットワーク全体でグローバルに利用可能にする必要があります。これはリンク状態ルーティングプロトコルを介して行われるため、この性質の情報は既存のリンク状態広告（LSA）にあるか、LSAを補完するためにこの情報を伝える必要があります。たとえば、ネットワーク内で異なるレベルのサービスを提供することが望ましい場合、回路がリング保護されていないSDH/SONETライン上で回路をルーティングしているかどうかに基づいて、リング保護されていないものに対してルーティングされている場合（信頼性に基づいて差別化）、SDH/SONETラインの保護の種類は、リンク状態を介して分散する必要がある重要なトポロジーパラメーターです。
(ii) Information that is only needed between two "adjacent" switches for the purposes of connection establishment is appropriate for distribution via one of the label distribution protocols. In fact, this information can be thought of as the "virtual" label. For example, in SONET networks, when distributing information to switches concerning an end-to-end STS-1 path traversing a network, it is critical that adjacent switches agree on the multiplex entry used by this STS-1 (but this information is only of local significance between those two switches). Hence, the multiplex entry number in this case can be used as a virtual label. Note that the label is virtual, in that it is not appended to the payload in any way, but it is still a label in the sense that it uniquely identifies the signal locally on the link between the two switches.
（ii）接続確立の目的で2つの「隣接する」スイッチの間でのみ必要な情報は、ラベル分布プロトコルのいずれかを介した配布に適しています。実際、この情報は「仮想」ラベルと考えることができます。たとえば、SONETネットワークでは、ネットワークを通過するエンドツーエンドのSTS-1パスに関するスイッチに情報を配布する場合、隣接するスイッチがこのSTS-1で使用されるマルチプレックスエントリに同意することが重要です（ただし、この情報はこれら2つのスイッチ間で局所的な重要性を持っています）。したがって、この場合のマルチプレックスエントリ番号は、仮想ラベルとして使用できます。ラベルは仮想であり、ペイロードにはいかなる方法でも追加されていませんが、2つのスイッチ間のリンク上の信号を局所的に識別するという意味で、ラベルです。
(iii) Information that all switches in the path need to know about a circuit will also be distributed via the label distribution protocol. Examples of such information include bandwidth, priority, and preemption.
（iii）パス内のすべてのスイッチが回路について知る必要があるという情報も、ラベル分布プロトコルを介して配布されます。そのような情報の例には、帯域幅、優先度、および先制が含まれます。
(iv) Information intended only for end systems of the connection. Some of the payload type information may fall into this category.
（iv）接続の終了システムのみを対象とした情報。ペイロードタイプ情報の一部は、このカテゴリに分類される場合があります。
Modern SDH/SONET transport networks excel at interoperability in the performance monitoring (PM) and fault management (FM) areas [7], [8]. They do not, however, interoperate in the areas of topology discovery or resource status. Although link state routing protocols, such as IS-IS and OSPF, have been used for some time in the IP world to compute destination-based next hops for routes (without routing loops), they are particularly valuable for providing timely topology and network status information in a distributed manner, i.e., at any network node. If resource utilization information is disseminated along with the link status (as done in ATM's PNNI routing protocol), then a very complete picture of network status is available to a network operator for use in planning, provisioning, and operations.
最新のSDH/SONETトランスポートネットワークは、パフォーマンス監視（PM）および障害管理（FM）領域[7]、[8]の相互運用性に優れています。ただし、トポロジーの発見やリソースステータスの領域では相互運用しません。IS-ISやOSPFなどのリンク状態ルーティングプロトコルは、IPの世界でしばらく使用されており、ルートの宛先ベースの次のホップを計算します（ルーティングループなし）が、タイムリーなトポロジとネットワークステータス情報を分散した方法で、つまりどのネットワークノードでも提供するために特に価値があります。リソース利用情報がリンクステータス（ATMのPNNIルーティングプロトコルで行われているように）とともに普及している場合、ネットワークステータスの非常に完全な画像が、計画、プロビジョニング、および運用に使用するためにネットワークオペレーターが利用できます。
The information needed to compute the path a connection will take through a network is important to distribute via the routing protocol. In the TDM case, this information includes, but is not limited to: the available capacity of the network links, the switching and termination capabilities of the nodes and interfaces, and the protection properties of the link. This is what is being proposed in the GMPLS extensions to IP routing protocols [9], [10], [11].
ネットワークを介して接続がとるパスを計算するために必要な情報は、ルーティングプロトコルを介して配布するために重要です。TDMの場合、この情報には、ネットワークリンクの利用可能な容量、ノードとインターフェイスの切り替えおよび終端機能、およびリンクの保護特性が含まれますが、これらに限定されません。これは、IPルーティングプロトコル[9]、[10]、[11]へのGMPLS拡張で提案されているものです。
When applying routing to circuit switched networks, it is useful to compare and contrast this situation with the datagram routing case [12]. In the case of routing datagrams, all routes on all nodes must be calculated exactly the same to avoid loops and "black holes". In circuit switching, this is not the case since routes are established per circuit and are fixed for that circuit. Hence, unlike the datagram case, routing is not service impacting in the circuit switched case. This is helpful because, to accommodate the optical layer, routing protocols need to be supplemented with new information, as compared to the datagram case. This information is also likely to be used in different ways for implementing different user services. Due to the increase in information transferred in the routing protocol, it may be useful to separate the relatively static parameters concerning a link from those that may be subject to frequent changes. However, the current GMPLS routing extensions [9], [10], [11] do not make such a separation.
回路スイッチ付きネットワークにルーティングを適用する場合、この状況をデータグラムのルーティングケース[12]と比較して対比することが役立ちます。ルーティングデータグラムの場合、ループや「ブラックホール」を避けるために、すべてのノードのすべてのルートをまったく同じように計算する必要があります。回路の切り替えでは、回路ごとにルートが確立され、その回路に固定されているため、これは当てはまりません。したがって、データグラムのケースとは異なり、ルーティングは回路スイッチされたケースでサービスに影響を与えるものではありません。これは、光学層に対応するために、データグラムのケースと比較して、ルーティングプロトコルに新しい情報を補充する必要があるためです。この情報は、さまざまなユーザーサービスを実装するためにさまざまな方法で使用される可能性があります。ルーティングプロトコルで転送される情報の増加により、リンクに関する比較的静的なパラメーターを頻繁に変化させる可能性のあるものと分離することが有用かもしれません。ただし、現在のGMPLSルーティング拡張機能[9]、[10]、[11]は、そのような分離を行いません。
Indeed, from the carriers' perspective, the up-to-date dissemination of all link properties is essential and desired, and the use of a link-state routing protocol to distribute this information provides timely and efficient delivery. If GMPLS-based networks got to the point that bandwidth updates happen very frequently, it makes sense, from an efficiency point of view, to separate them out for update. This situation is not yet seen in actual networks; however, if GMPLS signaling is put into widespread use then the need could arise.
実際、キャリアの観点から見ると、すべてのリンクプロパティの最新の普及が不可欠であり、この情報を配布するためのリンク状態ルーティングプロトコルを使用することで、タイムリーで効率的な配信を提供します。GMPLSベースのネットワークが、帯域幅の更新が非常に頻繁に発生するという点に達した場合、効率の観点からは、更新のためにそれらを分離することは理にかなっています。この状況は、実際のネットワークではまだ見られません。ただし、GMPLSシグナリングが広範囲に使用される場合、必要性が生じる可能性があります。
The main switching capabilities that characterize an SDH/SONET end system and thus need to be advertised via the link state routing protocol are: the switching granularity, supported forms of concatenation, and the level of transparency.
SDH/SONETエンドシステムを特徴付けるため、リンク状態ルーティングプロトコルを介して宣伝する必要がある主なスイッチング機能は、スイッチング粒度、サポートされた形式の連結、および透明性のレベルです。
From references [2], [3], and the overview section on SDH/SONET we see that there are a number of different signals that compose the SDH/SONET hierarchies. Those signals that are referenced via a pointer (i.e., the VCs in SDH and the SPEs in SONET) will actually be switched within an SDH/SONET network. These signals are subdivided into lower order signals and higher order signals as shown in Table 2.
参考文献[2]、[3]、およびSDH/SONETの概要セクションから、SDH/SONET階層を構成する多くの異なる信号があることがわかります。ポインター（つまり、SDHのVCSおよびSONETのSPES）を介して参照されるこれらの信号は、実際にはSDH/SONETネットワーク内に切り替えられます。これらの信号は、表2に示すように、低次信号と高次信号に細分されます。
Table 2. SDH/SONET switched signal groupings.
表2. SDH/SONETは信号グループ化を切り替えました。
Signal Type SDH SONET
信号タイプSDHソネット
Lower Order VC-11, VC-12, VC-2 VT-1.5 SPE, VT-2 SPE, VT-3 SPE, VT-6 SPE
低次VC-11、VC-12、VC-2 VT-1.5 SPE、VT-2 SPE、VT-3 SPE、VT-6 SPE
Higher VC-3, VC-4 STS-1 SPE, STS-3c SPE Order
より高いVC-3、VC-4 STS-1 SPE、STS-3C SPEオーダー
Manufacturers today differ in the types of switching capabilities their systems support. Many manufacturers today switch signals starting at VC-4 for SDH or STS-1 for SONET (i.e., down the basic frame) and above (see Section 5.1.2 on concatenation), but they do not switch lower order signals. Some of them only allow the switching of entire aggregates (concatenated or not) of signals such as 16 VC-4s, i.e., a complete STM-16, and nothing finer. Some go down to the VC-3 level for SDH. Finally, some offer highly integrated switches that switch at the VC-3/STS-1 level down to lower order signals such as VC-12s. In order to cover the needs of all manufacturers and operators, GMPLS signaling ([4], [5]) covers both higher order and lower order signals.
今日のメーカーは、システムがサポートするスイッチング機能の種類が異なります。今日、多くのメーカーは、SDHのVC-4またはSONETのSTS-1（つまり、基本フレームを下る）以上のSTS-1から始まる信号を切り替えます（連結に関するセクション5.1.2を参照）が、低次の信号を切り替えません。それらのいくつかは、16のVC-4などの信号の全体（連結または非）、つまり完全なSTM-16などの信号の切り替えのみを許可します。SDHのVC-3レベルに下がる人もいます。最後に、VC-3/STS-1レベルで切り替える高度に統合されたスイッチを提供するものもあります。すべてのメーカーとオペレーターのニーズをカバーするために、GMPLSシグナル伝達（[4]、[5]）は、高次信号と低次シグナルの両方をカバーしています。
As stated in the SDH/SONET overview, to transport tributary signals with rates in excess of the basic STM-1/STS-1 signal, the VCs/SPEs can be concatenated, i.e., glued together. Different types of concatenations are defined: contiguous standard concatenation, arbitrary concatenation, and virtual concatenation with different rules concerning their size, placement, and binding.
SDH/SONETの概要に記載されているように、基本的なSTM-1/STS-1信号を超えるレートで支流信号を輸送するために、VCS/SPEは連結すること、つまり接着することができます。さまざまなタイプの連結が定義されています：連続的な標準的連結、arbitrary意的な連結、およびそのサイズ、配置、および結合に関するさまざまなルールとの仮想連結。
Standard SONET concatenation allows the concatenation of M x STS-1 signals within an STS-N signal with M <= N, and M = 3, 12, 48, 192, STS-Mc. The STS-Mc notation is shorthand for describing an STS-M signal whose SPEs have been concatenated. The multiplexing procedures for SDH and SONET are given in references [2] and [3], respectively. Constraints are imposed on the size of STS-Mc signals, i.e., they must be a multiple of 3, and on their starting location and interleaving.
標準のSONET連結により、M <= nおよびM = 3、12、48、192、STS-MCを含むSTS-N信号内のM x STS-1シグナルの連結が可能になります。STS-MC表記は、SPEが連結されたSTS-M信号を記述するための速記です。SDHとSONETの多重化手順は、それぞれ参照[2]と[3]に記載されています。制約は、STS-MC信号のサイズに課されます。つまり、それらは3の倍数でなければならず、開始場所とインターリーブでなければなりません。
This has the following advantages: (a) restriction to multiples of 3 helps with SDH compatibility (there is no STS-1 equivalent signal in SDH); (b) the restriction to multiples of 3 reduces the number of connection types; (c) the restriction on the placement and interleaving could allow more compact representation of the "label";
これには次の利点があります。（a）3の倍数への制限は、SDHの互換性に役立ちます（SDHにはSTS-1等価信号はありません）。（b）3の倍数への制限により、接続タイプの数が減少します。（c）配置とインターリーブの制限により、「ラベル」のよりコンパクトな表現が可能になります。
The major disadvantages of these restrictions are: (a) Limited flexibility in bandwidth assignment (somewhat inhibits finer grained traffic engineering). (b) The lack of flexibility in starting time slots for STS-Mc signals and in their interleaving (where the rest of the signal gets put in terms of STS-1 slot numbers) leads to the requirement for re-grooming (due to bandwidth fragmentation).
これらの制限の主な欠点は次のとおりです。（a）帯域幅の割り当てにおける柔軟性が限られている（やや細かい粒子の交通工学を阻害する）。（b）STS-MC信号の開始時間スロットとそのインターリーブ（残りの信号がSTS-1スロット番号の観点から置かれる場所）に柔軟性がないため、再梱包の要件（帯域幅の断片化のため）。
Due to these disadvantages, some SONET framer manufacturers now support "flexible" or arbitrary concatenation. That is, they support concatenation with no restrictions on the size of an STS-Mc (as long as M <= N) and no constraints on the STS-1 timeslots used to convey it, i.e., the signals can use any combination of available time slots.
これらの不利な点により、一部のソネットフレーマーメーカーは現在、「柔軟な」または任意の連結をサポートしています。つまり、STS-MCのサイズ（M <= nである限り）に制限なしで連結をサポートし、それを伝えるために使用されるSTS-1タイムスロットの制約はありません。つまり、信号は利用可能な時間スロットの任意の組み合わせを使用できます。
Standard and flexible concatenations are network services, while virtual concatenation is an SDH/SONET end-system service approved by the Committee T1 of ANSI [3] and the ITU-T [2]. The essence of this service is to have SDH/SONET end systems "glue" together the VCs or SPEs of separate signals, rather than requiring that the signals be carried through the network as a single unit. In one example of virtual concatenation, two end systems supporting this feature could essentially "inverse multiplex" two STS-1s into an STS-1-2v for the efficient transport of 100 Mbps Ethernet traffic. Note that this inverse multiplexing process (or virtual concatenation) can be significantly easier to implement with SDH/SONET than packet switched circuits, because ensuring that timing and in-order frame delivery is preserved may be simpler to establish using SDH/SONET, rather than packet switched circuits, where more sophisticated techniques may be needed.
標準的で柔軟な連結はネットワークサービスですが、仮想連結は、ANSI [3]およびITU-T [2]の委員会T1によって承認されたSDH/SONETエンドシステムサービスです。このサービスの本質は、SDH/SONETエンドシステムを、単一のユニットとしてネットワークを介して信号を運ぶことを要求するのではなく、個別の信号のVCまたはSPEを「接着」することです。仮想連結の一例では、この機能をサポートする2つのエンドシステムは、100 Mbpsイーサネットトラフィックの効率的な輸送のために、2つのSTS-1を基本的に「逆多重化」する可能性があります。この逆マルチプレックスプロセス（または仮想連結）は、パケットスイッチングされた回路よりもSDH/SONETよりもSDH/SONETで実装するのが大幅に簡単になる可能性があることに注意してください。
Since virtual concatenation is provided by end systems, it is compatible with existing SDH/SONET networks. Virtual concatenation is defined for both higher order signals and low order signals. Table 3 shows the nomenclature and capacity for several lower-order virtually concatenated signals contained within different higher-order signals.
仮想連結はENDシステムによって提供されるため、既存のSDH/SONETネットワークと互換性があります。仮想連結は、高次信号と低次信号の両方で定義されます。表3は、異なる高次信号内に含まれるいくつかの低次の事実上連結信号の命名法と容量を示しています。
Table 3. Capacity of Virtually Concatenated VTn-Xv (9/G.707)
表3.実質的に連結されたVTN-XVの容量（9/g.707）
Carried In X Capacity In steps of
のステップでx容量で運ばれます
VT1.5/ STS-1/VC-3 1 to 28 1600kbit/s to 1600kbit/s VC-11-Xv 44800kbit/s
VT1.5/STS-1/VC-3 1から28 1600KBIT/S〜1600KBIT/S VC-11-XV 44800KBIT/S
VT2/ STS-1/VC-3 1 to 21 2176kbit/s to 2176kbit/s VC-12-Xv 45696kbit/s
VT2/STS-1/VC-3 1から21 2176KBIT/S〜2176KBIT/S VC-12-XV 45696KBIT/S
VT1.5/ STS-3c/VC-4 1 to 64 1600kbit/s to 1600kbit/s VC-11-Xv 102400kbit/s
VT1.5/STS-3C/VC-4 1〜64 1600KBIT/S〜1600KBIT/S VC-11-XV 102400KBIT/S
VT2/ STS-3c/VC-4 1 to 63 2176kbit/s to 2176kbit/s VC-12-Xv 137088kbit/s
VT2/STS-3C/VC-4 1〜63 2176KBIT/Sから2176KBIT/S VC-12-XV 137088KBIT/S
The purposed of SDH/SONET is to carry its payload signals in a transparent manner. This can include some of the layers of SONET itself. An example of this is a situation where the path overhead can never be touched, since it actually belongs to the client. This was another reason for not coding an explicit label in the SDH/SONET path overhead. It may be useful to transport, multiplex and/or switch lower layers of the SONET signal transparently.
SDH/SONETの目的は、ペイロード信号を透明な方法で運ぶことです。これには、ソネット自体の層の一部が含まれます。この例は、実際にクライアントに属しているため、パスオーバーヘッドに触れることができない状況です。これが、SDH/SONETパスオーバーヘッドで明示的なラベルをコーディングしないもう1つの理由でした。SONET信号の下層層を透過的に輸送、マルチプレックス、および/または切り替えると便利かもしれません。
As mentioned in the introduction, SONET overhead is broken into three layers: Section, Line, and Path. Each of these layers is concerned with fault and performance monitoring. The Section overhead is primarily concerned with framing, while the Line overhead is primarily concerned with multiplexing and protection. To perform pipe multiplexing (that is, multiplexing of 50 Mbps or 150 Mbps chunks), a SONET network element should be line terminating. However, not all SONET multiplexers/switches perform SONET pointer adjustments on all the STS-1s contained within a higher order SONET signal passing through them. Alternatively, if they perform pointer adjustments, they do not terminate the line overhead. For example, a multiplexer may take four SONET STS-48 signals and multiplex them onto an STS-192 without performing standard line pointer adjustments on the individual STS-1s. This can be looked at as a service since it may be desirable to pass SONET signals, like an STS-12 or STS-48, with some level of transparency through a network and still take advantage of TDM technology. Transparent multiplexing and switching can also be viewed as a constraint, since some multiplexers and switches may not switch with as fine a granularity as others. Table 4 summarizes the levels of SDH/SONET transparency.
導入部で述べたように、ソネットのオーバーヘッドは、セクション、ライン、パスの3つのレイヤーに分割されます。これらの各レイヤーは、障害とパフォーマンスの監視に関係しています。セクションオーバーヘッドは主にフレーミングに関係していますが、ラインオーバーヘッドは主に多重化と保護に関係しています。パイプの多重化（つまり、50 Mbpsまたは150 Mbpsチャンクの多重化）を実行するには、SONETネットワーク要素をライン終了する必要があります。ただし、すべてのSONETマルチプレクサ/スイッチが、それらを通過する高次ソネット信号内に含まれるすべてのSTS-1でソネットポインター調整を実行するわけではありません。あるいは、ポインター調整を実行した場合、ラインオーバーヘッドを終了しません。たとえば、マルチプレクサは、4つのSONET STS-48信号を採取し、個々のSTS-1Sで標準ラインポインター調整を実行せずにSTS-192にマルチプレックスする場合があります。これは、STS-12やSTS-48などのSONET信号を渡すことが望ましいため、ネットワークを介したある程度の透明性を備えており、TDMテクノロジーを利用することが望ましいため、サービスと見なすことができます。一部のマルチプレクサとスイッチは、他のマルチプレクサとスイッチは他のマルチプレクサとスイッチが細かく切り替えられない場合があるため、透明なマルチプレックスとスイッチングも制約と見なすことができます。表4は、SDH/SONETの透明性のレベルをまとめたものです。
Table 4. SDH/SONET transparency types and their properties.
表4. SDH/SONETの透明性タイプとそのプロパティ。
Transparency Type Comments
透明性タイプのコメント
Path Layer (or Line Standard higher order SONET path Terminating) switching. Line overhead is terminated or modified.
パスレイヤー（またはライン標準高次ソネットパス終端）スイッチング。ラインオーバーヘッドは終了または変更されます。
Line Level (or Section Preserves line overhead and switches Terminating) the entire line multiplex as a whole. Section overhead is terminated or modified.
ラインレベル（またはセクションは、ラインオーバーヘッドと終了のスイッチを保持します）全体として、ライン全体のマルチプレックスを使用します。セクションオーバーヘッドが終了または変更されます。
Section layer Preserves all section overhead, Basically does not modify/terminate any of the SDH/SONET overhead bits.
セクションレイヤーは、すべてのセクションのオーバーヘッドを保存します。基本的には、SDH/SONETオーバーヘッドビットを変更/終了しません。
SONET and SDH networks offer a variety of protection options at both the SONET line (SDH multiplex section) and SDH/SONET path level [7], [8]. Standardized SONET line level protection techniques include: Linear 1+1 and linear 1:N automatic protection switching (APS) and both two-fiber and four-fiber bi-directional line switched rings (BLSRs). At the path layer, SONET offers uni-directional path switched ring protection. Likewise, standardized SDH multiplex section protection techniques include linear 1+1 and 1:N automatic p protection switching and both two-fiber and four-fiber bi-directional MS-SPRings (Multiplex Section-Shared Protection Rings).
SONETおよびSDHネットワークは、SONETライン（SDHマルチプレックスセクション）とSDH/ソネットパスレベル[7]、[8]の両方で、さまざまな保護オプションを提供します。標準化されたソネットラインレベル保護技術には、リニア1 1および線形1：n自動保護スイッチング（APS）と2ファイバーおよび4ファイバーの両方の双方向ラインスイッチングリング（BLSR）が含まれます。パス層で、ソネットは一方向のパススイッチ付きリング保護を提供します。同様に、標準化されたSDHマルチプレックスセクション保護技術には、線形1 1および1：N自動P保護スイッチングと2ファイバーおよび4ファイバーの両方の双方向MSスプリング（マルチプレックスセクション共有保護リング）が含まれます。
At the path layer, SDH offers SNCP (sub-network connection protection) ring protection.
パスレイヤーで、SDHはSNCP（サブネットワーク接続保護）リング保護を提供します。
Both ring and 1:N line protection also allow for "extra traffic" to be carried over the protection line when that line is not being used, i.e., when it is not carrying traffic for a failed working line. These protection methods are summarized in Table 5. It should be noted that these protection methods are completely separate from any GMPLS layer protection or restoration mechanisms.
リングと1：Nライン保護の両方により、そのラインが使用されていないとき、つまり失敗した作業ラインのトラフィックを運ばないときに、「追加のトラフィック」を保護ラインの上に運ぶことができます。これらの保護方法は、表5に要約されています。これらの保護方法は、GMPLS層の保護または復元メカニズムとは完全に分離されていることに注意してください。
Table 5. Common SDH/SONET protection mechanisms.
表5.一般的なSDH/SONET保護メカニズム。
Protection Type Extra Comments Traffic Optionally Supported
保護タイプ追加コメントトラフィックはオプションでサポートされています
1+1 No Requires no coordination
Unidirectional between the two ends of the
circuit. Dedicated
protection line.
1+1 Bi- No Coordination via K byte
directional protocol. Lines must be
consistently configured.
Dedicated protection line.
1:1 Yes Dedicated protection.
1:N Yes One Protection line shared
by N working lines
4F-BLSR (4 Yes Dedicated protection, with
fiber bi- alternative ring path.
directional
line switched
ring)
2F-BLSR (2 Yes Dedicated protection, with
fiber bi- alternative ring path
directional
line switched
ring)
UPSR (uni- No Dedicated protection via
directional alternative ring path.
path switched Typically used in access
ring) networks.
It may be desirable to route some connections over lines that support protection of a given type, while others may be routed over unprotected lines, or as "extra traffic" over protection lines. Also, to assist in the configuration of these various protection methods, it can be extremely valuable to advertise the link protection attributes in the routing protocol, as is done in the current GMPLS routing protocols. For example, suppose that a 1:N protection group is being configured via two nodes. One must make sure that the lines are "numbered the same" with respect to both ends of the connection, or else the APS (K1/K2 byte) protocol will not correctly operate.
特定のタイプの保護をサポートする線にいくつかの接続をルーティングすることが望ましい場合がありますが、他のものは保護されていないライン上で、または保護ライン上の「余分なトラフィック」としてルーティングされる場合があります。また、これらのさまざまな保護方法の構成を支援するために、現在のGMPLSルーティングプロトコルで行われるように、ルーティングプロトコルでリンク保護属性を宣伝することが非常に価値があります。たとえば、1：n保護グループが2つのノードを介して構成されていると仮定します。接続の両端に関して、行が「同じ数字」になっていることを確認する必要があります。そうしないと、APS（K1/K2バイト）プロトコルが正しく動作しないことを確認する必要があります。
Table 6. Parameters defining protection mechanisms.
表6.保護メカニズムを定義するパラメーター。
Protection Comments Related Link Information
保護コメント関連リンク情報
Protection Type Indicates which of the protection types delineated in Table 5.
保護タイプは、表5に描かれた保護タイプのどれを示します。
Protection Indicates which of several protection
Group Id groups (linear or ring) that a node belongs
to. Must be unique for all groups that a
node participates in
Working line Important in 1:N case and to differentiate number between working and protection lines
1：nのケースで重要なワーキングラインと、作業ラインと保護ラインを区別する
Protection line Used to indicate if the line is a number protection line.
ラインが数の保護ラインであるかどうかを示すために使用される保護ライン。
Extra Traffic Yes or No Supported
追加のトラフィックはいまたはノーサポートされています
Layer If this protection parameter is specific to SONET then this parameter is unneeded, otherwise it would indicate the signal layer that the protection is applied.
レイヤーこの保護パラメーターがSONETに固有の場合、このパラメーターは不要になります。そうしないと、保護が適用されるという信号層を示します。
An open issue concerning protection is the extent of information regarding protection that must be disseminated. The contents of Table 6 represent one extreme, while a simple enumerated list (Extra-Traffic/Protection line, Unprotected, Shared (1:N)/Working line, Dedicated (1:1, 1+1)/Working Line, Enhanced (Ring) /Working Line) represents the other.
保護に関する未解決の問題は、普及しなければならない保護に関する情報の範囲です。表6の内容は1つの極端なものを表しますが、単純な列挙リスト（トラフィック/保護ライン、保護されていない、共有（1：n）/ワーキングライン、専用（1：1、1 1）/ワーキングライン、強化（リング）/ワーキングライン）は他のものを表します。
There is also a potential implication for link bundling [13], [15] that is, for each link, the routing protocol could advertise whether that link is a working or protection link and possibly some parameters from Table 6. A possible drawback of this scheme is that the routing protocol would be burdened with advertising properties even for those protection links in the network that could not, in fact, be used for routing working traffic, e.g., dedicated protection links. An alternative method would be to bundle the working and protection links together, and advertise the bundle instead. Now, for each bundled link, the protocol would have to advertise the amount of bandwidth available on its working links, as well as the amount of bandwidth available on those protection links within the bundle that were capable of carrying "extra traffic". This would reduce the amount of information to be advertised. An issue here would be to decide which types of working and protection links to bundle together. For instance, it might be preferable to bundle working links (and their corresponding protection links) that are "shared" protected separately from working links that are "dedicated" protected.
また、リンクバンドリング[13]、[15]には潜在的な意味があります。つまり、リンクごとに、ルーティングプロトコルはそのリンクが機能するか保護リンクであるか、おそらく表6からのパラメーターであるかどうかを宣伝できます。別の方法は、作業リンクと保護リンクをバンドルし、代わりにバンドルを宣伝することです。バンドルされたリンクごとに、プロトコルは、作業リンクで利用可能な帯域幅の量と、「余分なトラフィック」を運ぶことができるバンドル内のそれらの保護リンクで利用可能な帯域幅の量を宣伝する必要があります。これにより、宣伝される情報の量が減ります。ここでの問題は、どのタイプの作業および保護リンクをバンドルするかを決定することです。たとえば、「専用」保護された作業リンクとは別に「共有」保護されている作業リンク（および対応する保護リンク）をバンドルすることが望ましい場合があります。
Each SDH/SONET LSR must maintain an internal table per interface that indicates each signal in the multiplex structure that is allocated at that interface. This internal table is the most complete and accurate view of the link usage and available capacity.
各SDH/SONET LSRは、インターフェイスごとの内部テーブルを維持する必要があります。インターフェイスは、そのインターフェイスで割り当てられている多重構造の各信号を示すものです。この内部テーブルは、リンクの使用と利用可能な容量の最も完全かつ正確なビューです。
For use in path computation, this information needs to be advertised in some way to all other SDH/SONET LSRs in the same domain. There is a trade off to be reached concerning: the amount of detail in the available capacity information to be reported via a link state routing protocol, the frequency or conditions under which this information is updated, the percentage of connection establishments that are unsuccessful on their first attempt due to the granularity of the advertised information, and the extent to which network resources can be optimized. There are different levels of summarization that are being considered today for the available capacity information. At one extreme, all signals that are allocated on an interface could be advertised; while at the other extreme, a single aggregated value of the available bandwidth per link could be advertised.
PATH計算で使用するには、この情報は、同じドメインの他のすべてのSDH/SONET LSRに何らかの方法で宣伝する必要があります。リンク状態ルーティングプロトコルを介して報告される利用可能な容量情報の詳細の量、この情報が更新される頻度または条件、広告情報の粒度のために最初の試みで失敗した接続施設の割合、ネットワークリソースを最適化できる範囲。利用可能な容量情報のために今日考慮されている要約にはさまざまなレベルがあります。極端に、インターフェイスに割り当てられたすべての信号を宣伝できます。もう一方の極端には、リンクごとに利用可能な帯域幅の単一の集約値を宣伝できます。
Consider first the relatively simple structure of SONET and its most common current and planned usage. DS1s and DS3s are the signals most often carried within a SONET STS-1. Either a single DS3 occupies the STS-1 or up to 28 DS1s (4 each within the 7 VT groups) are carried within the STS-1. With a reasonable VT1.5 placement algorithm within each node, it may be possible to just report on aggregate bandwidth usage in terms of number of whole STS-1s (dedicated to DS3s) used and the number of STS-1s dedicated to carrying DS1s allocated for this purpose. This way, a network optimization program could try to determine the optimal placement of DS3s and DS1s to minimize wasted bandwidth due to half-empty STS-1s at various places within the transport network. Similarly consider the set of super rate SONET signals (STS-Nc). If the links between the two switches support flexible concatenation, then the reporting is particularly straightforward since any of the STS-1s within an STS-M can be used to comprise the transported STS-Nc. However, if only standard concatenation is supported, then reporting gets trickier since there are constraints on where the STS-1s can be placed. SDH has still more options and constraints, hence it is not yet clear which is the best way to advertise bandwidth resource availability/usage in SDH/SONET. At present, the GMPLS routing protocol extensions define minimum and maximum values for available bandwidth, which allows a remote node to make some deductions about the amount of capacity available at a remote link and the types of signals it can accommodate. However, due to the multiplexed nature of the signals, reporting of bandwidth particular to signal types, rather than as a single aggregate bit rate, may be desirable. For details on why this may be the case, we refer the reader to ITU-T publications G.7715.1 [16] and to Chapter 12 of [17].
SONETの比較的単純な構造と、その最も一般的な現在および計画された使用法を最初に考えてください。DS1SおよびDS3Sは、SONET STS-1内で最も頻繁に運ばれる信号です。単一のDS3がSTS-1を占めるか、最大28のDS1（7つのVTグループ内にそれぞれ4つ）がSTS-1内に運ばれます。各ノード内の合理的なVT1.5配置アルゴリズムを使用すると、使用されるSTS-1全体（DS3S専用）全体の数と、この目的のために割り当てられたDS1Sを運ぶことに専念するSTS-1の数に関して、集約帯域幅の使用についてのみ報告することができるかもしれません。このようにして、ネットワーク最適化プログラムは、輸送ネットワーク内のさまざまな場所での半分空のSTS-1Sによる無駄な帯域幅を最小限に抑えるために、DS3とDS1の最適な配置を決定しようとすることができます。同様に、スーパーレートソネット信号（STS-NC）のセットを考慮します。2つのスイッチ間のリンクが柔軟な連結をサポートする場合、STS-M内のSTS-1のいずれかを使用して輸送されたSTS-NCを構成できるため、レポートは特に簡単です。ただし、標準的な連結のみがサポートされている場合、STS-1を配置できる場所に制約があるため、報告はよりトリッキーになります。SDHにはさらに多くのオプションと制約があるため、SDH/SONETで帯域幅のリソースの可用性/使用を宣伝する最良の方法はまだ明確ではありません。現在、GMPLSルーティングプロトコル拡張は、利用可能な帯域幅の最小値と最大値を定義します。これにより、リモートノードは、リモートリンクで利用可能な容量の量と収容できる信号の種類について控除することができます。ただし、信号の多重化された性質により、単一の集計ビットレートとしてではなく、信号タイプに特有の帯域幅を報告することが望ましい場合があります。これが事実である理由の詳細については、読者にITU-T出版物G.7715.1 [16]および[17]の第12章を参照します。
Although a link state routing protocol can be used to obtain network topology and resource information, this does not imply the use of an "open shortest path first" route [6]. The path must be open in the sense that the links must be capable of supporting the desired signal type and that capacity must be available to carry the signal. Other constraints may include hop count, total delay (mostly propagation), and underlying protection. In addition, it may be desirable to route traffic in order to optimize overall network capacity, or reliability, or some combination of the two. Dikstra's algorithm computes the shortest path with respect to link weights for a single connection at a time. This can be much different than the paths that would be selected in response to a request to set up a batch of connections between a set of endpoints in order to optimize network link utilization. One can think of this along the lines of global or local optimization of the network in time.
リンク状態ルーティングプロトコルを使用して、ネットワークトポロジとリソース情報を取得することができますが、これは「最初のオープンパス」ルート[6]の使用を意味するものではありません。リンクが目的の信号タイプをサポートできる必要があり、信号を運ぶために容量を使用できる必要があるという意味で、パスは開く必要があります。その他の制約には、ホップ数、総遅延（主に伝播）、および基礎となる保護が含まれます。さらに、全体的なネットワーク容量、信頼性、または2つの組み合わせを最適化するために、トラフィックをルーティングすることが望ましい場合があります。Dikstraのアルゴリズムは、一度に単一の接続のリンク重みに関する最短パスを計算します。これは、ネットワークリンクの使用率を最適化するために、一連のエンドポイント間の接続のバッチを設定するリクエストに応じて選択されるパスとは大きく異なる場合があります。これは、ネットワークのグローバルまたはローカル最適化のラインに沿って時間内に考えることができます。
Due to the complexity of some of the connection routing algorithms (high dimensionality, non-linear integer programming problems) and various criteria by which one may optimize a network, it may not be possible or desirable to run these algorithms on network nodes. However, it may still be desirable to have some basic path computation ability running on the network nodes, particularly for use during restoration situations. Such an approach is in line with the use of GMPLS for traffic engineering, but is much different than typical OSPF or IS-IS usage where all nodes must run the same routing algorithm.
接続ルーティングアルゴリズム（高次元、非線形整数プログラミングの問題）の複雑さと、ネットワークを最適化する可能性のあるさまざまな基準のため、ネットワークノードでこれらのアルゴリズムを実行することは不可能または望ましくない場合があります。ただし、特に復元状況で使用するために、ネットワークノードで基本的なパス計算機能を実行することが望ましい場合があります。このようなアプローチは、トラフィックエンジニアリングにGMPLSの使用と一致していますが、すべてのノードが同じルーティングアルゴリズムを実行する必要がある典型的なOSPFまたはIS使用の使用とは大きく異なります。
Traditionally, end-to-end circuit connections in SDH/SONET networks have been set up via network management systems (NMSs), which issue commands (usually under the control of a human operator) to the various network elements involved in the circuit, via an equipment vendor's element management system (EMS). Very little multi-vendor interoperability has been achieved via management systems. Hence, end-to-end circuits in a multi-vendor environment typically require the use of multiple management systems and the infamous configuration via "yellow sticky notes". As discussed in Section 3, a common signaling protocol -- such as RSVP with TE extensions or CR-LDP -- appropriately extended for circuit switching applications, could therefore help to solve these interoperability problems. In this section, we examine the various components involved in the automated provisioning of SDH/SONET LSPs.
従来、SDH/SONETネットワークのエンドツーエンドの回路接続は、ネットワーク管理システム（NMSS）を介してセットアップされており、コマンド（通常は人間のオペレーターの制御下）が、機器ベンダーの要素管理システム（EMS）を介して、回路に関与するさまざまなネットワーク要素にコマンドを発行しています。管理システムを介して、マルチベンダーの相互運用性はほとんど達成されていません。したがって、マルチベンダー環境のエンドツーエンド回路では、通常、「黄色の粘着ノート」を介して複数の管理システムと悪名高い構成を使用する必要があります。セクション3で説明したように、回路スイッチングアプリケーションのために適切に拡張された、TE拡張機能またはCR-LDPを備えたRSVPなどの一般的なシグナル伝達プロトコルは、これらの相互運用性の問題を解決するのに役立ちます。このセクションでは、SDH/SONET LSPの自動化されたプロビジョニングに関与するさまざまなコンポーネントを調べます。
GMPLS was initially introduced to control asynchronous technologies like IP, where a label was attached to each individual block of data, such as an IP packet or a Frame Relay frame. SONET and SDH, however, are synchronous technologies that define a multiplexing structure (see Section 3), which we referred to as the SDH (or SONET) multiplex. This multiplex involves a hierarchy of signals, lower order signals embedded within successive higher order ones (see Fig. 1). Thus, depending on its level in the hierarchy, each signal consists of frames that repeat periodically, with a certain number of byte time slots per frame.
GMPLSは、IPのような非同期テクノロジーを制御するために最初に導入され、IPパケットやフレームリレーフレームなど、データの個々のブロックにラベルが取り付けられていました。ただし、SONETとSDHは、SDH（またはSONET）マルチプレックスと呼ばれる多重化構造（セクション3を参照）を定義する同期テクノロジーです。このマルチプレックスには、連続した高次のシグナルに埋め込まれた下位信号の階層が含まれます（図1を参照）。したがって、階層のレベルに応じて、各信号は、フレームごとに一定数のバイト時間スロットで定期的に繰り返されるフレームで構成されています。
The question then arises: is it these frames that we label in GMPLS? It will be seen in what follows that each SONET or SDH "frame" need not have its own label, nor is it necessary to switch frames individually. Rather, the unit that is switched is a "flow" comprised of a continuous sequence of time slots that appear at a given position in a frame. That is, we switch an individual SONET or SDH signal, and a label associated with each given signal.
その後、問題が発生します。GMPLSでラベル付けされているのはこれらのフレームですか？各SONETまたはSDHの「フレーム」には独自のラベルが必要でもないことも、フレームを個別に切り替える必要もありません。むしろ、切り替えられたユニットは、フレーム内の特定の位置に表示される連続時間スロットの連続シーケンスで構成される「フロー」です。つまり、個々のソネットまたはSDH信号を切り替え、与えられた各信号に関連付けられたラベルを切り替えます。
For instance, the payload of an SDH STM-1 frame does not fully contain a complete unit of user data. In fact, the user data is contained in a virtual container (VC) that is allowed to float over two contiguous frames for synchronization purposes. The H1-H2-H3 Au-n pointer bytes in the SDH overhead indicates the beginning of the VC in the payload. Thus, frames are now inter-related, since each consecutive pair may share a common virtual container. From the point of view of GMPLS, therefore, it is not the successive frames that are treated independently or labeled, but rather the entire user signal. An identical argument applies to SONET.
たとえば、SDH STM-1フレームのペイロードには、ユーザーデータの完全な単位が完全に含まれていません。実際、ユーザーデータは、同期の目的で2つの連続したフレームに浮かぶことが許可されている仮想コンテナ（VC）に含まれています。SDHオーバーヘッドのH1-H2-H3 Au-Nポインターバイトは、ペイロード内のVCの開始を示しています。したがって、各連続ペアが共通の仮想コンテナを共有する可能性があるため、フレームは相互に関連しています。したがって、GMPLSの観点からは、独立してラベル付けされているのは連続したフレームではなく、ユーザーシグナル全体です。同一の引数がSONETに適用されます。
Observe also that the GMPLS signaling used to control the SDH/SONET multiplex must honor its hierarchy. In other words, the SDH/SONET layer should not be viewed as homogeneous and flat, because this would limit the scope of the services that SDH/SONET can provide. Instead, GMPLS tunnels should be used to dynamically and hierarchically control the SDH/SONET multiplex. For example, one unstructured VC-4 LSP may be established between two nodes, and later lower order LSPs (e.g., VC-12) may be created within that higher order LSP. This VC-4 LSP can, in fact, be established between two non-adjacent internal nodes in an SDH network, and later advertised by a routing protocol as a new (virtual) link called a Forwarding Adjacency (FA) [14].
また、SDH/SONETマルチプレックスを制御するために使用されるGMPLSシグナル伝達は、その階層を尊重する必要があることを観察します。言い換えれば、SDH/SONET層は、SDH/SONETが提供できるサービスの範囲を制限するため、均一でフラットと見なされるべきではありません。代わりに、GMPLSトンネルを使用して、SDH/SONETマルチプレックスを動的かつ階層的に制御する必要があります。たとえば、1つの非構造化されたVC-4 LSPが2つのノードの間に確立される場合があり、その後の下位LSP（例：VC-12）がその高次LSP内に作成される場合があります。このVC-4 LSPは、実際には、SDHネットワーク内の2つの非隣接内部ノードの間に確立でき、後に転送隣接隣接（FA）と呼ばれる新しい（仮想）リンクとしてルーティングプロトコルによって宣伝されます[14]。
An SDH/SONET-LSR will have to identify each possible signal individually per interface to fulfill the GMPLS operations. In order to stay transparent, the LSR obviously should not touch the SDH/SONET overheads; this is why an explicit label is not encoded in the SDH/SONET overheads. Rather, a label is associated with each individual signal. This approach is similar to the one considered for lambda switching, except that it is more complex, since SONET and SDH define a richer multiplexing structure. Therefore, a label is associated with each signal, and is locally unique for each signal at each interface. This signal could, and will most probably, occupy different time-slots at different interfaces.
SDH/SONET-LSRは、GMPLS操作を満たすために、インターフェイスごとに各可能な信号を個別に識別する必要があります。透明性を保つために、LSRは明らかにSDH/SONETのオーバーヘッドに触れてはなりません。これが、明示的なラベルがSDH/SONETオーバーヘッドにエンコードされていない理由です。むしろ、ラベルは個々の信号に関連付けられています。このアプローチは、SONETとSDHがより豊かな多重化構造を定義するため、より複雑であることを除いて、Lambdaスイッチングで考慮されたアプローチと類似しています。したがって、ラベルは各信号に関連付けられており、各インターフェイスの各信号に対して局所的に一意です。この信号は、さまざまなインターフェイスで異なるタイムスロットを占める可能性があります。
The signaling protocol used to establish an SDH/SONET LSP must have specific information elements in it to map a label to the particular signal type that it represents, and to the position of that signal in the SDH/SONET multiplex. As we will see shortly, with a carefully chosen label structure, the label itself can be made to function as this information element.
SDH/SONET LSPを確立するために使用されるシグナル伝達プロトコルには、特定の信号タイプにラベルをマッピングするために、SDH/SONETマルチプレックスのその信号の位置にラベルをマッピングするために特定の情報要素が必要です。まもなくわかるように、慎重に選択されたラベル構造により、ラベル自体をこの情報要素として機能させることができます。
In general, there are two ways to assign labels for signals between neighboring SDH/SONET LSRs. One way is for the labels to be allocated completely independently of any SDH/SONET semantics; e.g., labels could just be unstructured 16 or 32 bit numbers. In that case, in the absence of appropriate binding information, a label gives no visible information about the flow that it represents. From a management and debugging point of view, therefore, it becomes difficult to match a label with the corresponding signal, since , as we saw in Section 6.1, the label is not coded in the SDH/SONET overhead of the signal.
一般に、隣接するSDH/SONET LSRの間に信号にラベルを割り当てる方法は2つあります。1つの方法は、ラベルをSDH/SONETセマンティクスとは独立して完全に割り当てることです。たとえば、ラベルは16または32ビットの数値を構造化されていない場合があります。その場合、適切なバインディング情報がない場合、ラベルはそれが表す流れに関する目に見える情報を提供しません。したがって、管理とデバッグの観点からは、セクション6.1で見たように、ラベルは信号のSDH/SONETオーバーヘッドでコーディングされていないため、ラベルを対応する信号と一致させることが困難になります。
Another way is to use the well-defined and finite structure of the SDH/SONET multiplexing tree to devise a signal numbering scheme that makes use of the multiplex as a naming tree, and assigns each multiplex entry a unique associated value. This allows the unique identification of each multiplex entry (signal) in terms of its type and position in the multiplex tree. By using this multiplex entry value itself as the label, we automatically add SDH/SONET semantics to the label! Thus, simply by examining the label, one can now directly deduce the signal that it represents, as well as its position in the SDH/SONET multiplex. We refer to this as multiplex-based labeling. This is the idea that was incorporated in the GMPLS signaling specifications for SDH/SONET [15].
別の方法は、SDH/SONET多重化ツリーの明確に定義された有限構造を使用して、マルチプレックスを命名ツリーとして使用し、各マルチプレックスエントリに一意の関連値を割り当てる信号番号スキームを考案することです。これにより、各マルチプレックスエントリ（信号）の一意の識別が、マルチプレックスツリーのその種類と位置に関して可能になります。このマルチプレックスエントリ値自体をラベルとして使用することにより、SDH/SONETセマンティクスをラベルに自動的に追加します！したがって、単にラベルを調べるだけで、SDH/SONET Multiplexでの位置と同様に、それが表す信号を直接推定できるようになりました。これをマルチプレックスベースのラベルと呼びます。これは、SDH/SONET [15]のGMPLS信号仕様に組み込まれたアイデアです。
In the preceding sections, we defined the meaning of an SDH/SONET label and specified its structure. A question that arises naturally at this point is the following. In an LSP or connection setup request, how do we specify the signal for which we want to establish a path (and for which we desire a label)?
前のセクションでは、SDH/SONETラベルの意味を定義し、その構造を指定しました。この時点で自然に発生する質問は次のとおりです。LSPまたは接続セットアップリクエストでは、パスを確立する（およびラベルを希望する）をどのように指定しますか？
Clearly, information that is required to completely specify the desired signal and its characteristics must be transferred via the label distribution protocol, so that the switches along the path can be configured to correctly handle and switch the signal. This information is specified in three parts [15], each of which refers to a different network layer.
明らかに、目的の信号とその特性を完全に指定するために必要な情報は、パスに沿ったスイッチを構成して信号を正しく処理および切り替えるように構成できるように、ラベル分布プロトコルを介して転送する必要があります。この情報は3つの部分[15]で指定されており、それぞれが異なるネットワークレイヤーを指します。
1. GENERALIZED_LABEL REQUEST (as in [4], [5]), which contains three parts: LSP Encoding Type, Switching Type, and G-PID.
1. generalized_labelリクエスト（[4]、[5]のように）。これには、LSPエンコーディングタイプ、スイッチングタイプ、g-pidの3つの部分が含まれています。
The first specifies the nature/type of the LSP or the desired SDH/SONET channel, in terms of the particular signal (or collection of signals) within the SDH/SONET multiplex that the LSP represents, and is used by all the nodes along the path of the LSP.
最初のものは、LSPが表すSDH/SONETマルチプレックス内の特定の信号（または信号のコレクション）の観点から、LSPを表し、LSPの経路に沿ったすべてのノードで使用されるSDH/SONETマルチプレックス内の特定の信号（または信号のコレクション）の観点から、LSPまたは目的のSDH/SONETチャネルの性質/タイプを指定します。
The second specifies certain link selection constraints, which control, at each hop, the selection of the underlying link that is used to transport this LSP.
2番目は、各ホップでこのLSPの輸送に使用される基礎となるリンクの選択を制御する特定のリンク選択制約を指定します。
The third specifies the payload carried by the LSP or SDH/SONET channel, in terms of the termination and adaptation functions required at the end points, and is used by the source and destination nodes of the LSP.
3番目は、エンドポイントで必要な終了および適応関数の観点から、LSPまたはSDH/SONETチャネルが運ぶペイロードを指定し、LSPのソースおよび宛先ノードで使用されます。
2. SONET/SDH TRAFFIC_PARAMETERS (as in [15], Section 2.1) used as a SENDER_TSPEC/FLOWSPEC, which contains 7 parts: Signal Type, (Requested Contiguous Concatenation (RCC), Number of Contiguous Components (NCC), Number of Virtual Components (NVC)), Multiplier (MT), Transparency, and Profile.
2. SONET/SDH Traffic_Parameters（[15]、セクション2.1のように）は、7つの部分を含むsender_tspec/flowspecとして使用されます。信号タイプ（Request Contiguous Concatenation（RCC）、連続コンポーネント数（NCC）、仮想コンポーネント（NVC）の数）、マルチプライヤー（MT）、翻訳およびProge。
The Signal Type indicates the type of elementary signal comprising the LSP, while the remaining fields indicate transforms that can be applied to the basic signal to build the final signal that corresponds to the LSP actually being requested. For instance (see [15] for details):
信号タイプは、LSPを含む基本信号のタイプを示し、残りのフィールドは基本信号に適用して実際に要求されているLSPに対応する最終信号を構築できる変換を示します。たとえば、詳細については[15]を参照）：
- Contiguous concatenation (by using the RCC and NCC fields) can be optionally applied on the Elementary Signal, resulting in a contiguously concatenated signal.
- （RCCおよびNCCフィールドを使用することにより）連続的な連結は、正常信号にオプションで適用され、連続的に連結されたシグナルをもたらすことができます。
- Then, virtual concatenation (by using the NVC field) can be optionally applied on the Elementary Signal, resulting in a virtually concatenated signal.
- 次に、仮想連結（NVCフィールドを使用することにより）をオプションで初等信号に適用することができ、実質的に連結された信号が得られます。
- Third, some transparency (by using the Transparency field) can be optionally specified when requesting a frame as a signal rather than an SPE- or VC-based signal.
- 第三に、SPEまたはVCベースの信号ではなく信号としてフレームを要求するときに、いくつかの透明度（透明度フィールドを使用することにより）をオプションで指定できます。
- Fourth, a multiplication (by using the Multiplier field) can be optionally applied either directly on the Elementary Signal or on the contiguously concatenated signal obtained from the first phase, or on the virtually concatenated signal obtained from the second phase, or on these signals combined with some transparency.
- 第4に、乗算は（乗数フィールドを使用することにより）、正常信号または第1フェーズから得られた連続的に連結した連結信号、または第2フェーズから得られた実質的に連結された信号、またはこれらの信号とある程度の透明度のいずれかに直接適用できます。
Transparency indicates precisely which fields in these overheads must be delivered unmodified at the other end of the LSP. An ingress LSR requesting transparency will pass these overhead fields that must be delivered to the egress LSR without any change. From the ingress and egress LSRs point of views, these fields must be seen as unmodified.
透明性は、これらのオーバーヘッドのどのフィールドがLSPの反対側で修正されずに配信されなければならないことを正確に示しています。透明性を要求するIngress LSRは、これらのオーバーヘッドフィールドを通過し、変更せずに出力LSRに配信する必要があります。侵入と出口のLSRSの視点から、これらのフィールドは変更されていないと見なされなければなりません。
Transparency is not applied at the interfaces with the initiating and terminating LSRs, but is only applied between intermediate LSRs.
透明性は、LSRを開始および終了するインターフェイスでは適用されませんが、中間LSR間でのみ適用されます。
The transparency field is used to request an LSP that supports the requested transparency type; it may also be used to setup the transparency process to be applied at each intermediate LSR.
透明度フィールドは、要求された透明性タイプをサポートするLSPを要求するために使用されます。また、各中間LSRで適用する透明性プロセスをセットアップするためにも使用できます。
Finally, the profile field is intended to specify particular capabilities that must be supported for the LSP, for example monitoring capabilities. However, no standard profile is currently defined.
最後に、プロファイルフィールドは、LSPにサポートする必要がある特定の機能を指定することを目的としています。たとえば、機能を監視します。ただし、現在定義されている標準プロファイルはありません。
3. UPSTREAM_LABEL for Bi-directional LSP's (as in [4], [5]).
3. 双方向LSPのupstream_label（[4]、[5]のように）。
4. Local Link Selection, e.g., IF_ID_RSVP_HOP Object (as in [5]).
4. ローカルリンクの選択、例えば、if_id_rsvp_hopオブジェクト（[5]のように）。
We provided a detailed account of the issues involved in applying generalized GMPLS-based control (GMPLS) to TDM networks.
一般化されたGMPLSベースの制御（GMPLS）をTDMネットワークに適用することに伴う問題の詳細な説明を提供しました。
We began with a brief overview of GMPLS and SDH/SONET networks, discussing current circuit establishment in TDM networks, and arguing why SDH/SONET technologies will not be "outdated" in the foreseeable future. Next, we looked at IP/MPLS applied to SDH/SONET networks, where we considered why such an application makes sense, and reviewed some GMPLS terminology as applied to TDM networks.
GMPLSとSDH/SONETネットワークの簡単な概要から始め、TDMネットワークでの現在の回路確立について議論し、SDH/SONETテクノロジーが予見可能な将来に「時代遅れ」にならない理由について議論しました。次に、SDH/SONETネットワークに適用されるIP/MPLSを調べました。そこでは、そのようなアプリケーションが理にかなっている理由を検討し、TDMネットワークに適用されるGMPLS用語をレビューしました。
We considered the two main areas of application of IP/MPLS methods to TDM networks, namely routing and signaling, and discussed how Generalized MPLS routing and signaling are used in the context of TDM networks. We reviewed in detail the switching capabilities of TDM equipment, and the requirement to learn about the protection capabilities of underlying links, and how these influence the available capacity advertisement in TDM networks.
TDMネットワークへのIP/MPLSメソッドの適用領域、つまりルーティングとシグナル伝達を検討し、TDMネットワークのコンテキストで一般化されたMPLSルーティングとシグナリングがどのように使用されるかについて説明しました。TDM機器のスイッチング機能と、基礎となるリンクの保護機能について学ぶための要件、およびTDMネットワークでの利用可能な容量広告にどのように影響するかを詳細にレビューしました。
We focused briefly on path computation methods, pointing out that these were not subject to standardization. We then examined optical path provisioning or signaling, considering the issue of what constitutes an appropriate label for TDM circuits and how this label should be structured; and we focused on the importance of hierarchical label allocation in a TDM network. Finally, we reviewed the signaling elements involved when setting up a TDM circuit, focusing on the nature of the LSP, the type of payload it carries, and the characteristics of the links that the LSP wishes to use at each hop along its path for achieving a certain reliability.
パス計算方法に簡単に焦点を当て、これらは標準化の対象ではないことを指摘しました。次に、TDM回路に適したラベルを構成するものと、このラベルを構成する方法の問題を考慮して、光学パスのプロビジョニングまたはシグナリングを検討しました。また、TDMネットワークでの階層ラベル割り当ての重要性に焦点を当てました。最後に、TDM回路をセットアップするときに関係するシグナル要素をレビューし、LSPの性質、携帯するペイロードの種類、およびLSPが特定の信頼性を達成するためのパスに沿って各ホップで使用したいリンクの特性に焦点を当てました。
The use of a control plane to provision connectivity through a SONET/SDH network shifts the security burden significantly from the management plane to the control plane. Before the introduction of a control plane, the communications that had to be secured were between the management stations (Element Management Systems or Network Management Systems) and each network element that participated in the network connection. After the introduction of the control plane, the only management plane communication that needs to be secured is that to the head-end (ingress) network node as the end-to-end service is requested. On the other hand, the control plane introduces a new requirement to secure signaling and routing communications between adjacent nodes in the network plane.
SONET/SDHネットワークを介して接続をプロビジョニングするための制御プレーンの使用は、セキュリティの負担を管理プレーンからコントロールプレーンに大幅にシフトします。制御プレーンの導入前は、保護する必要がある通信は、管理ステーション（要素管理システムまたはネットワーク管理システム）とネットワーク接続に参加した各ネットワーク要素の間でした。コントロールプレーンの導入後、保護する必要がある唯一の管理プレーン通信は、エンドツーエンドサービスが要求されているため、ヘッドエンド（イングレス）ネットワークノードに対するものです。一方、コントロールプレーンは、ネットワークプレーンの隣接するノード間の信号とルーティングの通信を保護するための新しい要件を導入します。
The security risk from impersonated management stations is significantly reduced by the use of a control plane. In particular, where unsecure versions of network management protocols such as SNMP versions 1 and 2 were popular configuration tools in transport networks, the use of a control plane may significantly reduce the security risk of malicious and false assignment of network resources that could cause the interception or disruption of data traffic.
成績の良い管理ステーションからのセキュリティリスクは、コントロールプレーンを使用することにより大幅に削減されます。特に、SNMPバージョン1や2などのネットワーク管理プロトコルの無事バージョンが輸送ネットワークで人気のある構成ツールであった場合、コントロールプレーンの使用は、データトラフィックの傍受または破壊を引き起こす可能性のあるネットワークリソースの悪意のあるおよび誤った割り当てのセキュリティリスクを大幅に減らす可能性があります。
On the other hand, the control plane may increase the number of security relationships that each network node must maintain. Instead of a single security relationship with its management element, each network node must now maintain a security relationship with each of its signaling and routing neighbors in the control plane.
一方、コントロールプレーンは、各ネットワークノードが維持する必要があるセキュリティ関係の数を増やす可能性があります。管理要素との単一のセキュリティ関係の代わりに、各ネットワークノードは、制御プレーン内の各信号およびルーティングネイバーとのセキュリティ関係を維持する必要があります。
There is a strong requirement for signaling and control plane exchanges to be secured, and any protocols proposed for this purpose must be capable of secure message exchanges. This is already the case for the existing GMPLS routing and signaling protocols.
シグナリングおよび制御プレーンの交換を保護するための強力な要件があり、この目的のために提案されているプロトコルは、メッセージ交換を安全に行うことができなければなりません。これは、既存のGMPLSルーティングおよびシグナリングプロトコルの場合にすでに当てはまります。
We acknowledge all the participants of the MPLS and CCAMP WGs, whose constant enquiry about GMPLS issues in TDM networks motivated the writing of this document, and whose questions helped shape its contents. Also, thanks to Kireeti Kompella for his careful reading of the last version of this document, and for his helpful comments and feedback, and to Dimitri Papadimitriou for his review on behalf of the Routing Area Directorate, which provided many useful inputs to help update the document to conform to the standards evolutions since this document passed last call.
MPLSおよびCCAMP WGSの参加者全員が、TDMネットワークでのGMPLの問題に関する絶え間ない調査がこのドキュメントの執筆を動機付け、その質問がその内容を形成するのに役立つことを認めています。また、このドキュメントの最後のバージョンを慎重に読んでくれたKireeti Kompella、そして彼の有益なコメントとフィードバック、およびルーティングエリア局に代わって彼のレビューのためにDimitri Papadimitriouに感謝します。
In the ITU references below, please see http://www.itu.int for availability of ITU documents. For ANSI references, please see the Library available through http://www.ansi.org.
以下のITU参照では、ITUドキュメントの可用性については、http：//www.itu.intを参照してください。ANSI参照については、http：//www.ansi.orgから入手可能なライブラリを参照してください。
[1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[1] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[2] G.707, Network Node Interface for the Synchronous Digital Hierarchy (SDH), International Telecommunication Union, March 1996.
[2] G.707、同期デジタル階層（SDH）のネットワークノードインターフェイス、国際電気通信ユニオン、1996年3月。
[3] ANSI T1.105-1995, Synchronous Optical Network (SONET) Basic Description including Multiplex Structure, Rates, and Formats, American National Standards Institute.
[3] ANSI T1.105-1995、同期光学ネットワーク（SONET）マルチプレックス構造、レート、フォーマット、American National Standards Instituteなどの基本的な説明。
[4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[4] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[5] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[5] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソースリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[6] Bernstein, G., Yates, J., Saha, D., "IP-Centric Control and Management of Optical Transport Networks," IEEE Communications Mag., Vol. 40, Issue 10, October 2000.
[6] Bernstein、G.、Yates、J.、Saha、D。、「光学輸送ネットワークのIP中心の制御と管理」、IEEE Communications Mag。、Vol。40、第10号、2000年10月。
[7] ANSI T1.105.01-1995, Synchronous Optical Network (SONET) Automatic Protection Switching, American National Standards Institute.
[7] ANSI T1.105.01-1995、同期光学ネットワーク（SONET）自動保護スイッチング、American National Standards Institute。
[8] G.841, Types and Characteristics of SDH Network Protection Architectures, ITU-T, July 1995.
[8] G.841、SDHネットワーク保護アーキテクチャの種類と特性、ITU-T、1995年7月。
[9] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[9] Kompella、K.、ed。and Y. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[10] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[10] Kompella、K.、ed。and Y. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。
[11] 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.
[11] Kompella、K.、ed。およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートする中間システム（IS-IS）拡張」、RFC 4205、2005年10月。
[12] Bernstein, G., Sharma, V., Ong, L., "Inter-domain Optical Routing," OSA J. of Optical Networking, vol. 1, no. 2, pp. 80- 92.
[12] Bernstein、G.、Sharma、V.、Ong、L。、「ドメイン間光ルーティング」、OSA J. of Optical Networking、Vol。1、いいえ。2、pp。80-92。
[13] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[13] Kompella、K.、Rekhter、Y。およびL. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。
[14] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[14] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、RFC 4206、2005年10月。
[15] 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.
[15] Mannie、E。and D. Papadimitriou、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）同期光学ネットワーク（SONET）および同期デジタル階層（SDH）コントロールの拡張」、RFC 3946、2004年10月。
[16] G.7715.1, ASON Routing Architecture and Requirements for Link-State Protocols, International Telecommunications Union, February 2004.
[16] G.7715.1、ASONルーティングアーキテクチャとリンク状態プロトコルの要件、国際電気通信ユニオン、2004年2月。
[17] Bernstein, G., Rajagopalan, R., and Saha, D., "Optical Network Control: Protocols, Architectures, and Standards," Addison-Wesley, July 2003.
[17] Bernstein、G.、Rajagopalan、R。、およびSaha、D。、「光ネットワーク制御：プロトコル、アーキテクチャ、および標準」、Addison-Wesley、2003年7月。
ANSI - American National Standards Institute APS - Automatic Protection Switching ATM - Asynchronous Transfer Mode BLSR - Bi-directional Line Switch Ring CPE - Customer Premise Equipment DLCI - Data Link Connection Identifier ETSI - European Telecommunication Standards Institute FEC - Forwarding Equivalency Class GMPLS - Generalized MPLS IP - Internet Protocol IS-IS - Intermediate System to Intermediate System (RP) LDP - Label Distribution Protocol LSP - Label Switched Path LSR - Label Switching Router MPLS - Multi-Protocol Label Switching NMS - Network Management System OSPF - Open Shortest Path First (RP) PNNI - Private Network Node Interface PPP - Point to Point Protocol QoS - Quality of Service RP - Routing Protocol RSVP - ReSerVation Protocol SDH - Synchronous Digital Hierarchy SNMP - Simple Network Management Protocol SONET - Synchronous Optical NETworking SPE - SONET Payload Envelope STM - Synchronous Transport Module (or Terminal Multiplexer) STS - Synchronous Transport Signal TDM - Time Division Multiplexer TE - Traffic Engineering TMN - Telecommunication Management Network UPSR - Uni-directional Path Switch Ring VC - Virtual Container (SDH) or Virtual Circuit VCI - Virtual Circuit Identifier (ATM) VPI - Virtual Path Identifier (ATM) VT - Virtual Tributary WDM - Wavelength-Division Multiplexing
ANSI-アメリカ国立標準研究所APS-自動保護スイッチングATM-非同期転送モードBLSR-双方向ラインスイッチリングCPE-顧客前提型機器DLCI-データリンク接続識別子ETSI-欧州通信標準Institute FEC -FECの転送等価クラスGMPLS- LSP-ラベルスイッチ付きパスLSR-ラベルスイッチングルーターMPLS -Multi -ProtocolラベルスイッチングNMS -Network Management System OSPF -Open Shortest Path First（RP）PNNI-プライベートネットワークノードインターフェイスPPP -Point To Point Protocol Qos -QUS -QUSOLY of Servic RP- RP -Routing Protocol RSVP -Reservation Protocol Synch -Synchon MedanctOus Prot Contoc -dididous Prot -HierAchy Hierachy hiser光ネットワーキングSPE-ソネットペイロードエンベロープSTM-同期トランスポートモジュール（または端子マルチプレクサ）STS-同期トランスポートシグナルTDM-タイムディビジョンマルチプレクサTE-トラフィックエンジニアリングTMN-電気通信管理ネットワークUPSR-ユニディレクトパススイッチリングリングVC-仮想パスティッキーアイデンティティVT-仮想支流WDM -Wavelength -Division Multiplexing
Author's Addresses
著者のアドレス
Greg Bernstein Grotto Networking
グレッグバーンスタインの洞窟ネットワーキング
Phone: +1 510 573-2237
EMail: gregb@grotto-networking.com
Eric Mannie Perceval Rue Tenbosch, 9 1000 Brussels Belgium
エリックマニーパーセバルRue Tenbosch、9 1000ブリュッセルベルギー
Phone: +32-2-6409194
EMail: eric.mannie@perceval.net
Vishal Sharma Metanoia, Inc. 888 Villa Street, Suite 500 Mountain View, CA 94041
Vishal Sharma Metanoia、Inc。888 Villa Street、Suite 500 Mountain View、CA 94041
Phone: +1 650 641 0082
Email: v.sharma@ieee.org
Eric Gray Marconi Corporation, plc 900 Chelmsford Street Lowell, MA 01851 USA
Eric Gray Marconi Corporation、PLC 900 Chelmsford Street Lowell、MA 01851 USA
Phone: +1 978 275 7470
EMail: Eric.Gray@Marconi.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスが利用可能になる可能性がある範囲に関連する可能性があると主張される可能性のある他の権利の範囲に関してはありません。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.ietf.org/IPRでIETFオンラインIPRリポジトリから取得できます。
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エディター機能の資金は現在、インターネット協会によって提供されています。