RFC4257 日本語訳
4257 Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/SynchronousOptical Networking (SDH/SONET) Networks. G. Bernstein, E. Mannie, V.Sharma, E. Gray. December 2005. (Format: TXT=86974 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループG.バーンスタイン要求をネットワークでつないでください: 4257年の洞窟ネットワークカテゴリ: 情報のE.のMetanoia Inc.E.グレーマルコニーマニーPerceval V.シャルマ社、plc2005年12月
Framework for Generalized Multi-Protocol Label
Switching (GMPLS)-based Control of Synchronous Digital
Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks
同期デジタルハイアラーキ/同期の光のネットワーク(SDH/Sonet)ネットワークの一般化されたマルチプロトコルラベルスイッチング(GMPLS)ベースのコントロールのための枠組み
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)インターネット協会(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.
一般化されたMulti-プロトコルLabel Switching(GMPLS)は、それを一般に、適切にするMPLSへの例えば非パケットベースの切り換え、および特に光学切り換えることのコントロールを含むためにはひとそろいのプロトコル拡大です。 1つの考慮は光学転送ネットワークの制御飛行機をアップグレードさせるのにGMPLSプロトコルを使用することです。 このドキュメントは、同期デジタルハイアラーキ(SDH)かSynchronous Optical Networking(Sonet)ネットワークを制御するのが目的とされるGMPLSプロトコルにそれらの拡大について説明することによって、この過程を例証します。 SDH/Sonetネットワークはさまざまな理由でこの過程の好例を作ります。 このドキュメントは輸送経路計算とネットワーク操作で必要である情報を広めるためにGMPLS関連のルーティング・プロトコルに拡大を強調します、(G) 輸送サーキットの食糧を供給するのに必要であるMPLSプロトコル拡張子と共に。 また、GMPLS制御飛行機がSDH/Sonetネットワークにもたらす新しい回復方法やマルチ層のサーキット設立などの新しい能力について議論します。
Bernstein, et al. Informational [Page 1] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[1ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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
1. 序論…3 1.1. MPLS概観…3 1.2. SDH/Sonet概観…5 1.3. SDH/Sonetネットワークにおける、サーキット設立の現状…7 1.3.1. 管理タスク…8 1.3.2. 手動…8 1.3.3. 計画ツール操作…8 1.3.4. サーキットの食糧を供給すること…8 1.4. 分散型アプローチに対してアプローチを集結します…9 1.4.1. トポロジー発見とリソース普及…10 1.4.2. 経路計算(ルート決断)…10 1.4.3. 接続設立(食糧を供給します)…10 1.5. なぜSDH/Sonetは明日、見えなくならないだろうか…12 2. GMPLSはSDH/Sonetに適用しました…13 2.1. SDH/Sonetを制御して、多重送信してください…13 2.2. SDH/Sonet LSRとLSP用語…14 3. GMPLS回線交換問題スペースの分解…14 4. SDH/SonetのためのGMPLSルート設定…15 4.1. 能力を切り換えます…16 4.1.1. 粒状を切り換えます…16 4.1.2. 連結能力に合図してください…17 4.1.3. SDH/Sonet透明…19 4.2. 保護…20 4.3. 利用可能な容量広告…23 4.4. 経路計算…24 5. SDH/SonetのためのLSP食糧を供給する/シグナリング…25 5.1. 私たちはSDH/Sonetで何をラベルしますか? フレームですかそれともサーキットですか? .......25 5.2. SDH/Sonetの構造をラベルしてください…26 5.3. シグナリング要素…27 6. 概要と結論…29 7. セキュリティ問題…29 8. 承認…30 9. 有益な参照…31 10. 頭文字語…33
Bernstein, et al. Informational [Page 2] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[2ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
1. Introduction
1. 序論
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作業部会には、複数のネットワーク層と新種業務を支持するためにMPLS[1]プロトコルを広げるという目標があります。 この拡張MPLS(初めは、Multi-プロトコルLambda Switchingとして知られていた)は現在、Generalized MPLS(または、GMPLS)と呼ばれるほうがよいです。
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層とその下位層の間の同輩かオーバレイモデルを使用する利益は、将来、はっきりさせられて、評価されなければならないでしょう。 その間に、独自に各層を制御するのにGMPLSを使用できました。
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.
この仕事の目標はダイナミックにSDH/Sonetサーキットを確立して、維持して、取りこわすのにどうGMPLSを使用できたかを強調することです。 これらの拡張IP/MPLSプロトコルを使用する目的はそれらのサービスを証明するために集結にされるを通して管理に食糧を供給することの代わりに少なくとも今日提供しますが、シグナリングを使用することに対する同じ種類のSDH/Sonetのサービスを提供することです。 これは、オペレータが新種業務を提案するのを許容して、クライアントが要求次第でSDH/Sonet経路を作成するのを許容するでしょう、リアルタイムでで、プロバイダーネットワークを通して。 私たちは最初にSDH/Sonetネットワークと彼らの操作の不可欠の特性を見直します、そして、どうSDH/SonetケースにGMPLSのラベル概念について敷衍できるかを示しています。 そして、私たちは、リンク州のルーティング・プロトコルによって広められて、ラベル分配プロトコルによって運ばれる必要がある重要な信号属性を見るために重要情報を見ます。 最終的に、私たちはいくつかの未解決の問題と将来の可能性を見ます。
1.1. MPLS Overview
1.1. MPLS概観
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]の主要な利点は推進(または、データ)飛行機と、シグナリング(または、接続コントロール)飛行機と、ルーティング(または、トポロジー発見/リソース状態)飛行機の間の明確な分離です。 これで、周知のIPルーティング・プロトコルがルーティング飛行機で再利用されるのを許容している間、MPLS拡張子に対する仕事は、推進と飛行機に合図するのは焦点を合わせることができます。 また、この明確な分離は、MPLSがパケットベースの推進飛行機を持っていないネットワークを制御するのに使用されるのを許容します。
Bernstein, et al. Informational [Page 3] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[3ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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ネットワークはLabel Switched Paths(LSPs)を通して接続されたLabel Switch Routers(LSRs)と呼ばれるMPLSノードから成ります。 LSPはuni方向上であり、ポイントで指すようないくつかの異なったタイプ、ポイントツーマルチポイント、および多点からポイントのものであるかもしれません。 MPLSネットワークにおける境界LSRsはイングレスか出口のどちらか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はForwarding Equivalence Class(FEC)に関連しています。(Forwarding Equivalence ClassはLSRで同じ推進処理を受ける1セットのパケットとして考えられるかもしれません)。 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を証明するために、自由民主党かRSVP-TEなどのシグナリングプロトコル(または、ラベル分配プロトコル)が必要です。 2隣接しているLSRsの間では、LSPはそれらの2LSRsの間で重要であるだけであるラベルと呼ばれる固定長識別子によって局所的に特定されます。 節間コミュニケーションがこれらのラベルを割り当てて、維持するのにシグナリングプロトコルは使用されます。
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を一緒に、決定しますか? このために、イングレスLSRは適切なラベルをパケットに取り付けて、次のホップにパケットを送ります。 ラベルは異なった方法でパケットに取り付けられるかもしれません。 例えば、それはパケット(「詰め物」ヘッダー)をカプセルに入れっているヘッダーの形にあるかもしれませんか、それがパケットのVPI/VCI分野に層について書かれた(または、DLCI分野)2カプセル化であるかもしれません。 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ネットワークのために、これらの操作がかなり同じ方法で起こらないのがわかるでしょう。
Bernstein, et al. Informational [Page 4] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[4ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
1.2. SDH/SONET Overview
1.2. 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]はヨーロッパのTelecommunications Standards Institute(ETSI)SDH階層構造とUSA ANSI SONET階層構造[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の基本的な信号はおよそ155Mbpsのレートで作動するSTM-1です、Sonetの基本的な信号がおよそ51Mbpsのレートで作動するSTS-1ですが。 これらの2つの信号が輸送オーバーヘッド(ヘッダー)から成る隣接のフレームとペイロードで作られています。 同期問題を解決するために、実際のデータは直接ペイロード、しかし、むしろ2個以上の連続したSDH/Sonetペイロードを浮かべることができる別の内部のフレームで輸送されません。 この内部のフレームはSDHとSonet有効搭載量Envelope(SPE)でSonetでVirtual Container(VC)と命名されます。
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
VC/SPE自身はヘッダー(経路オーバーヘッド)とペイロードで作られます。 さらにかなり複雑な方法でこのペイロードを下位要素(信号)に細分できます。 SDHの場合では、STM-1フレームが1VC-4を含むかもしれませんか、または3はVC-3を多重送信しました。 Sonetマルチプレックスは純粋な木です、SDHマルチプレックスが純粋な木ではありませんが、2親に愛着できるノードを含んでいるので
Bernstein, et al. Informational [Page 5] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[5ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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.
ノード。 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.
これらのマルチプレックス構造の葉は進貢している信号を含むことができる異なったサイズの時間帯(位置)です。 これらの進貢している信号(例えば、1E、3Eなど)は、標準化された配置規則を使用することで葉に写像されます。 一般に、進貢している信号は完全に時間帯をいっぱいにするというわけではありません、そして、配置規則は正確にそれをいっぱいにする方法を定義します。
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ベースのコントロールに、重要なことは別のインタフェースで1つのインタフェースの入力マルチプレックスから出力マルチプレックスに切り換えることができる要素を特定することになっています。 切り換えることができる唯一の要素がすなわち、ポインタ、Sonetの場合におけるSDHとSPEの場合におけるVC-xを通して再編成できるものです。
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 x1 STM-N<。----8月の<。----Au-4<--VC4<。------------------------------C-4E4^ ^Ix3 Ix3I I x1I-----強い引き-3<。----トゥ-3<。---VC-3<。---^3C-3DS3/EのI I STM-0<。------------Au-3<。---VC-3<--私---------------------I^I Ix7 Ix7I I x1-----強い引き-2<。---トゥ-2<。---VC-2<。---C-2DS2/T2^ ^I I x3I I----トゥ-12<。---VC-12<--C-12 1ユーロのI I x4I-------トゥ-11<。---VC-11<--C-11DS1/T1
Bernstein, et al. Informational [Page 6] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[6ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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
xN STS-N<。-------------------SPE<。------------------------------DS3/T3^Ix7I x1I---バーモント-グループ<。---バーモント-6<。----SPE DS2/T2^ ^ ^I I I x2I I I-----バーモント-3<。----SPE DS1C I I I I x3I I--------バーモント-2<。----SPE E1I I x4I-----------バーモント-1.5<--SPE DS1/T1
Figure 1. SDH and SONET multiplexing structure and typical Plesiochronous Digital Hierarchy (PDH) payload signals.
図1。 SDH、Sonetマルチプレクシング構造、および典型的なPlesiochronous Digital Hierarchy(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/SPEsは独立していて、それら自身が時間を計るのに従って、浮きます。 基本のSTM-1/STS-1信号レートを超えて進貢している信号を輸送するために、すなわち、にかわで接がれた状態でVCs/SPEsを一緒に連結できます。 この場合、互いに関するそれらの関係は時間内に、修理されています。 可能であるときに、したがって、どんな逆さのマルチプレクシングのエンドシステムも過程を接着して、これは救います。 異なったタイプの連結は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.
例えば、標準のSonetの連結は3、12、N、およびSTS-1がM<と共にSTS-N信号の中で合図するM x=M=48の連結、192を許容します… STS-mcを形成するためにこれらのM x STS-1sのSPEsを連結できます。 STS-mc記法は、SPEsが連結されたSTS-M信号について説明するための短い手です。
1.3. The Current State of Circuit Establishment in SDH/SONET Networks
1.3. SDH/Sonetネットワークにおける、サーキット設立の現状
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スイッチに連絡するのを許容しながら、全体の過程を完全に自動化できます。 現在、食糧を供給することの過程は以下のタスクを伴います。
Bernstein, et al. Informational [Page 7] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[7ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
1.3.1. Administrative Tasks
1.3.1. 管理業務
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アプリケーションを使用することでそれらの大部分を自動化できます、例えば、クライアントはサーキットを要求するためにまだフォームをいっぱいにしなければなりません。 このフォームをウェブベースのアプリケーションでいっぱいにすることができて、オペレータは自動的に処理できます。 さらなる増進はクライアントの設備がオペレータのネットワークと共に直接調整して、必要なサーキットを要求するのを許容することです。 クライアント設備とオペレータスイッチとのインタフェースのシグナリングプロトコルを通してこれを達成できました、すなわち、UNIで。そこでは、GMPLSシグナリング[4]、[5]を使用できます。
1.3.2. Manual Operations
1.3.2. 手動
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とオペレータスイッチの間に右のケーブルかファイバーを取り付けることを伴う手動によって、消費されるかもしれません。 オペレータの本社と異なった時間帯にクライアントがいるとき、今回は特に重要である場合があります。 総合的な設立時代の接続時間が頻繁に説明されるこの第1回。
1.3.3. Planning Tool Operation
1.3.3. 計画ツール操作
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.
現代のもう1つの部分が必要なサーキットのための最適化されたプレースメントを見つけるのに発見しているアルゴリズムを使用することでシミュレーションを走らせる計画ツールによって消費されます。 これらの計画ツールは時々何日もの注文ときに重要な実行時間を必要とすることができます。
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.
一般に、すなわち、サーキットの要求、1セットのaバッチ・モードのために実行されて、ネットワーク資源用法と他のパラメタの最適を改良するために、これらのシミュレーションがあります。 今日、私たちには、このシミュレーション時間に減少する手段が本当にありません。 これに反して、速くて、オンラインのサーキット設立を支持するために、このフェーズは、より頻繁に呼び出されるかもしれません、すなわち、対応するサーキットを綿密に計画する前に私たちがどんな多くの同じくらい「バッチは同じくらい上昇する」接続にも要求を望んでいません。 これは、ネットワークが、定期的に再最適化されている必要であるかもしれないことを意味します、シグナリングが最小の衝撃で既存のサービスに再最適化を支持するべきであるのを含意して。
1.3.4. Circuit Provisioning
1.3.4. サーキットの食糧を供給すること
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
上で議論した最初の3ステップがいったん終了されると、計画過程の出力を使用することでオペレータはサーキットに食糧を供給しなければなりません。 食糧を供給するのに必要である時間は大いに異なります。 それはかなり短い場合があります、数分の注文に関して、オペレータにそれらが食糧を供給することをするのを助けるツールが既にあるなら
Bernstein, et al. Informational [Page 8] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[8ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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.
異種の設備の上で。 さもなければ、過程は何日もかかるかもしれません。 それぞれの新しい設備と各業者のためにこれらのツールを開発するのは、サービスプロバイダーでの重要な負担です。 GMPLSなどのようにシグナリングに食糧を供給するための標準化されたインタフェースは、この開発負担をかなり減少するか、または排除するかもしれません。 一般に、食糧を供給するのがbatched活動である、すなわち、1週間に数回、オペレータは1セットのサーキットに食糧を供給します。 GMPLSは、数分から数秒までの時間に食糧を供給しながらこれを減少させて、この周期的な過程をリアルタイムの過程に変えるのを助けるかもしれません。
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時間続きます。 オペレータは、テスト設備を各端にインストールして、性能について確かめるのに事前に定義されたテストの流れを使用します。 うまくいくなら、サーキットはクライアントによって公式に受け入れられます。 検証(「立証する」として時々知られている)の過程を早くするために、何らかのフォームの自動化された性能テストを支持するのが必要でしょう。
1.4. Centralized Approach versus Distributed Approach
1.4. 集結されたアプローチ対分散型アプローチ
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はそれ自体で分配された技術ですが、SDH/SonetネットワークへのGMPLSのアプリケーションはどちらのモデルも排除しません。
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です。スケーラビリティについて。 例えば、このアプローチは対処できるネットワーク要素(例えば、1,000)の数が制限されるかもしれません。 したがって、オペレータがNetwork Management Layerで平行な数個のNMSを配備するのは、全く一般的です、それぞれ異なったゾーンを管理して。 しかしながら、その場合、終わりから終わりへのオンデマンドサービスの世話をするために数個の個々のNMSの先端にService Management Layerを造らなければなりません。 他方では、回復は複雑な、そして/または、濃いネットワークが集結されたアプローチより分散型アプローチで速いかもしれません。
Let's now look at how the major control plane functional components are handled via the centralized and distributed approaches:
今、主要な制御飛行機機能的なコンポーネントが集結されて分配されたアプローチでどう扱われるかを見ましょう:
Bernstein, et al. Informational [Page 9] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[9ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
1.4.1. Topology Discovery and Resource Dissemination
1.4.1. トポロジー発見とリソース普及
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にも利用可能でしょう。したがって、人は手動で食糧を供給されたトポロジー情報(そこには何かがいつもある)と、完全に自動化された発見と普及の間の機能性の連続を見ることができます(リンク州のプロトコルのように)。 SDH/Sonetネットワークに適用されたリンク州のルーティング・プロトコルがIPデータグラムケースと異なって含意に影響を与える少しのサービスも持っていないことに注意してください。 これはSDH/Sonet場合では、サーキットが情報筋によって発送されていて(したがって、輪が全くあるはずがありません)、サーキットが確立されて、承認がソースで受信されるまで交通が全く伝えられないからです。
1.4.2. Path Computation (Route Determination)
1.4.2. 経路計算(ルート決断)
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ソフトウェアの更新で新しいタイプの経路の多様性か新しい最適化アルゴリズムなどの新機能を導入できます。 他方では、新しい経路計算ソフトウェアでスイッチをアップデートするのは、より複雑なタスクです。 さらに、アルゴリズムの多くが、かなり計算上徹底的である場合があり、ほとんどのスイッチで利用可能な埋め込まれた処理環境には、完全に不適当であるかもしれません。 回復シナリオでは、合理的に洗練されたレベルの経路計算をネットワーク要素に実行する能力は特に主要なネットワーク障害の間、交通を復元することの役に立つ場合があります。
1.4.3. Connection Establishment (Provisioning)
1.4.3. コネクション確立(食糧を供給すること)
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
すなわち、サーキット、十字の結合した収集を上がっている実際の設定はネットワークの向こう側に接続します、個々の十字をセットアップすると接続するNMSを通して、または、「柔らかい永久的なLSP」を通してされた(SPLSP)タイプがアプローチであったかもしれないなら。 SPLSPアプローチでは、GMPLSがそのポイントから接続を前方へセットアップしながら合図している状態で、NMSは「イングレス」スイッチでただ接続を開始するかもしれません。 接続
Bernstein, et al. Informational [Page 10] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[10ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
establishment is the trickiest part to distribute, however, since errors in the connection setup/tear down process are service impacting.
過程の下側への接続設定/裂け目の誤りがサービスの影響を与えることであるので、しかしながら、設立は分配する中で最も油断のならない部分です。
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
分散型アプローチCentralizedアプローチ
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)のように役に立つパケットベースの制御飛行機Management飛行機? SNMP Do、私たちは本当にそれがそうしなければなりません。 Alwaysが必要とした存在! 既にそこでは、加えられるか、または指定されて、数個が. 標準化本体を立証して、理解していました。
High survivability (e.g., in Potential single point(s) of
case of partition) failure
高生存性(例えば、パーティションのPotentialの単一のポイントの場合における)失敗
Distributed load Bottleneck: #requests and
actions to/from NMS
分配された負荷Bottleneck: #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
個々のローカルのルーティングCentralizedルーティング決定、1Assumesのようなルート設定スケーラブルな要求のブロック単位で決定できる、いくつかの大きいインターネット管理ドメイン
Complex to change routing Very easy local upgrade (non-
protocol/algorithm intrusive)
Veryの簡単な地方のアップグレードを発送しながら変化するように、複雑です。(非プロトコル/アルゴリズム押しつけがましい)です。
Requires enhanced routing Better consistency
protocol (traffic
engineering)
高められたルーティングBetter一貫性プロトコルを必要とします。(交通工学)
Ideal for inter-domain Not inter-domain friendly
相互ドメインNot相互ドメインに、好意的な理想
Suitable for very dynamic For less dynamic demands
demands (longer lived)
非常にダイナミックなForそれほどダイナミックでない要求要求に適しています。(より長い間、送られます)
Probably faster to restore, Probably slower to restore,but
but more difficult to have could effect reliable
reliable restoration. restoration.
回復するのにおいてたぶんより速くて、しかし、回復するより遅いのにもかかわらずの、持っているのが、より難しいProbablyは信頼できる信頼できる回復回復に作用できました。
High scalability Limited scalability: #nodes,
(hierarchical) links, circuits, messages
高いスケーラビリティ株式会社スケーラビリティ: #ノード、(階層的)のリンク、サーキット、メッセージ
Bernstein, et al. Informational [Page 11] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[11ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
Planning (optimization) Planning is a background
harder to achieve centralized activity
計画(最適化)計画は集結された活動をより達成しにくいバックグラウンドです。
Easier future integration
with other control plane
layers
他のコントロール飛行機層による、より簡単な今後の統合
1.5. Why SDH/SONET Will Not Disappear Tomorrow
1.5. SDH/Sonetが明日見えなくならない理由
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交通が輸送インフラの上で輸送された優位な交通になるので、SDHとSonetの時分割多重化とIPの統計的多重化を比べるのは役に立ちます。
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.
この単純モデルは、キャリヤーが帯域幅の代わりにλを販売すると暗示します。 キャリヤーの目標は1ファイバーあたりの波長/λの数を最大にすることでしょう、波長が完全に利用されるか否かに関係なく、終わりから終わりへのそれぞれのλのために費用を完全に支持しなければならない各顧客と共に。 私たちには、近い将来、1ファイバーあたりのλを数100までサポートする技術があるかもしれませんが、λが非常に安くて、豊富であるのですべての個々の顧客がそれらを買う世界は今日、1ポイントからいかなる他のポイントまでもありそうもないシナリオに現れます。
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.)
より現実的に、波長より低い粒状をサーキットに提供するマルチプレクシング技術の余地がまだあります。 (皆は1サーキットあたり最低10Gbpsか40Gbpsを必要とするというわけではなくて、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
SDHとSonetはサーキット(すなわち、QoS)の間にすばらしい粒状を公正に可能にして、輸送された交通の非常に安くて簡単な物理的分離を提供する豊かなマルチプレクシング階層構造を持っています。 そのうえ、IPデータグラムさえ波長の直接上輸送できません。 縁どりかカプセル化が、IPデータグラムを区切るのにいつも必要です。IPヘッダーのTotal Length分野が新しいデータグラムの始まりを見つけると信じることができません、崩壊できて、同期の損失をもたらすでしょう、したがって。 今日IPにDense WDM(DWDM)の上で使用されている典型的な縁どりは、RFC1619/RFC2615で定義されて、POS(パケットOver SDH/Sonet)(すなわち、SDH/Sonetの上のPPP(High-レベルのData Link Controlの(HDLC)のような形式の)の上のIP)として知られています。 SDHとSonetはIPには、実際に効率的なカプセル化です。 例えば、平均したIP
Bernstein, et al. Informational [Page 12] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[12ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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.
350の八重奏のデータグラムの長さ、28%のオーバーヘッドに結果をコード化する8B/10Bを使用するGigabitイーサネット(GbE)カプセル化の上のIP、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などのエラー修正能力(前進のError Correction)。 十分である、体力を要している同期(パケットの始まりを検出するために、それはいる)を許容するために情報を調節します。 また、関連シグナリングが使用されている(すなわち、どこで、コントロールとデータ飛行機topologiesは一致していますか)場合では、カプセル化はシグナリング、ルーティング、および管理メッセージを輸送する能力を提供するべきです、光学スイッチを制御するために。 むしろ、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とWDMネットワークの上のSDHの上の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インタフェース(SDHかSonetの上でイングレスと出口のインタフェースの間で輸送されるPDH信号)を通して接されます。 私たちがここで論争していることは全く切り換えか推進をする意味をこれらの層にするということです。
2. GMPLS Applied to SDH/SONET
2. SDH/Sonetに適用されたGMPLS
2.1. Controlling the SDH/SONET Multiplex
2.1. 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
SDH/Sonetの異なったスイッチできるコンポーネントのどれが多重送信されるかを決めて、GMPLSを使用することでSDH/Sonetマルチプレックスを制御するのが制御するつもりでありたいと思います。 本質的には、ポインタによって参照をつけられるあらゆるSDH/Sonet要素は切り換えることができます。 これらのコンポーネント信号は、SDH場合でVC-4と、VC-3と、VC-2と、VC-12と、VC-11です。 Sonet場合におけるバーモントとSTS SPEs。 中のSonetがそうしないSPEsはそうしました。
Bernstein, et al. Informational [Page 13] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[13ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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.
単にバーモント-N SPEsとそれらを呼ぶことができますが、個人名。 それらを含む構造、すなわち、STS-1、バーモント-6、バーモント-3バーモント-2、およびバーモント-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に対応しています、そして、バーモント-6SPEはVC2に対応しています、そして、バーモント-2SPEはVC-12に対応しています、そして、バーモント-1.5SPEはVC-11に対応しています。 Sonetバーモント-3SPEは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は、VC2mcを築き上げるためにVC-4-Xcを造るX隣接のAU-4とmの連結に隣接のTU-2を許容します。 その場合、GMPLSはVC-4XcかVC2mcを切り換えて、制御できます。 また、SDHはTU-2の仮想(非隣接の)の連結を定義します。 しかしながら、その場合、それぞれの構成しているVC-2は個別に切り換えられます。
2.2. SDH/SONET LSR and LSP Terminology
2.2. SDH/Sonet LSRとLSP用語
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 Terminal Multiplexer(TM)、Add-低下Multiplexer(ADM)、または十字接続(すなわち、スイッチ)をSDH/SONET LSRと呼ばせてください。 現在、2SDH/Sonet LSRsの間の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に対応するというわけではないと判明して、したがって、それらのすべてが特定されなければならないというわけではありません。 切り換えることができないそれらの信号しか識別を必要とします。
3. Decomposition of the GMPLS Circuit-Switching Problem Space
3. GMPLS回線交換問題スペースの分解
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、Frame Relayなど)のアプリケーションになじみ深いかもしれませんが、ここで、光学切り換え問題スペースに適用されると、私たちはすばやく分解を見直します。
Bernstein, et al. Informational [Page 14] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[14ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
(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) 経路を計算するのに必要である情報をネットワーク中でグローバルに利用可能にしなければなりません。 リンク州のルーティング・プロトコルでこれをするので、この種のどんな情報も既存のリンク州の広告(LSAs)にあるに違いありませんか、またはこの情報を伝えるためにLSAsを補わなければなりません。 サーキットが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.
分配に、2個の「隣接している」スイッチの間でコネクション確立の目的に必要であるだけである(ii)情報はラベル分配プロトコルの1つを通して適切です。 事実上、「仮想」のラベルとしてこの情報を考えることができます。 終わりから端へのSTS-1ネットワークを横断する経路に関してスイッチに情報を分配するとき、例えば、Sonetネットワークでは、隣接しているスイッチがこの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)情報は接続のエンドシステムだけを向けようとしました。 ペイロードタイプ情報のいくつかがこのカテゴリになるかもしれません。
4. GMPLS Routing for SDH/SONET
4. SDH/SonetのためのGMPLSルート設定
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]の相互運用性に優れています。 しかしながら、彼らはトポロジー発見かリソース状態の領域に共同利用しません。 そして、リンクですが、ルーティング・プロトコルを述べてください、あれほど、-、OSPF、しばらくIP世界で使用されていて、ルート(ルーティング輪のない)に次の目的地ベースのホップを計算してください、分配された方法によるタイムリーなトポロジーとネットワーク状態情報を前提としますそれらが特に貴重である、すなわち、どんなネットワーク・ノードでも。 リソース利用情報がリンク状態と共に広められるなら(ATMのPNNIルーティング・プロトコルでするように)、ネットワーク・オペレータにとって、ネットワーク状態の非常に完全な絵は計画、食糧を供給すること、および操作における使用に利用可能です。
Bernstein, et al. Informational [Page 15] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[15ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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場合では、以下に含んでいますが、この情報は限られていません。 ネットワークリンクの有効な容量、ノードとインタフェースの切り換えと終了能力、およびリンクの保護の特性。 これはGMPLS拡張子でIPルーティング・プロトコル[9]、[10]、[11]に提案されていることです。
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]に対してこの状況を比較して、対照するのは役に立ちます。 ルーティングデータグラムの場合では、輪と「ブラックホール」を避けるためにまさに同じようにすべてのノードの上のすべてのルートを計算しなければなりません。 回線交換では、ルートがサーキット単位で確立されて、そのサーキットに固定されているので、これはそうではありません。 したがって、データグラムケースと異なった、ルーティングはサーキットの切り換えられた場合で影響を与えるサービスではありません。 ルーティング・プロトコルが、光学層を収容するのに新情報が補われる必要があるので、これは役立っています、データグラムケースと比べて。 また、この情報も、異なったユーザサービスを実行するのに異なった方法で使用されそうです。 ルーティング・プロトコルで移された情報の増加のために、リンクに関して変化によく行くためになることがあるかもしれないものと比較的静的なパラメタを切り離すのは役に立つかもしれません。 [10] [11] しかしながら、現在のGMPLSが拡大[9]を発送して、そのような分離をしないでください。
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.
本当に、すべてのリンクの特性の最新の普及は、キャリヤーの見解から、不可欠であって、必要です、そして、この情報を分配するLinkState方式プロトコルの使用はタイムリーで効率的な配送を提供します。 GMPLSを拠点とするネットワークが帯域幅アップデートが非常に頻繁に起こるというポイントに着いたなら、効率観点から、アップデートのためにそれらを分離するのは理解できます。 この状況は実際のネットワークでまだ見られていません。 しかしながら、GMPLSシグナリングを普及使用に入れるなら、必要性は起こるかもしれません。
4.1. Switching Capabilities
4.1. スイッチング能力
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エンドシステムを特徴付けて、その結果リンク州のルーティング・プロトコルで広告を出す必要がある主なスイッチング能力は以下の通りです。 切り換え粒状、支持された形式の連結、および透明のレベル。
4.1.1. Switching Granularity
4.1.1. 切り換え粒状
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
参照[2]、[3]、およびSDH/Sonetの概観部から、私たちは、SDH/Sonet階層構造を構成する多くの異なった信号があるのがわかります。 ポインタ(すなわち、SDHのVCsとSonetにおけるSPEs)を通して参照をつけられるそれらの信号が実際にあるでしょう。
Bernstein, et al. Informational [Page 16] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[16ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
switched within an SDH/SONET network. These signals are subdivided into lower order signals and higher order signals as shown in Table 2.
SDH/Sonetネットワークの中で切り換えられます。 これらの信号はTable2に示されるように下層階級信号と、より高いオーダー信号に細分されます。
Table 2. SDH/SONET switched signal groupings.
2を見送ってください。 SDH/Sonetは信号組分けを切り換えました。
Signal Type SDH SONET
信号タイプSDH Sonet
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バーモント-1.5SPE、バーモント-2SPE、バーモント-3SPE、バーモント-6SPE
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(すなわち、基本枠の下側への)において上から始動する信号を切り換えますが(セクション5.1.2を連結に見てください)、それらは下層階級信号を切り換えません。 彼らの何人かがすなわち、16VC-4s、完全なSTM-16などの信号の全体の集合(連結される)、および何かよりすばらしいものの切り換えを許すだけではありません。 或るものはSDHのためにVC-3レベルに降ります。 最終的に、非常に統合された何らかの申し出がVC-3/STS-1レベルでそのスイッチを12VC-年代などの下層階級信号まで切り換えます。 ([4]に合図するすべてのメーカーとオペレータ、GMPLSの必要性を隠すために、[5])は、より高い注文と下層階級信号の両方をカバーしています。
4.1.2. Signal Concatenation Capabilities
4.1.2. 信号連結能力
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.
基本のSTM-1/STS-1信号を超えたレートで進貢している信号を輸送するためにSDH/Sonet概観で述べられているように、すなわち、にかわで接がれた状態でVCs/SPEsを一緒に連結できます。 異なったタイプの連結は定義されます: それらのサイズ、プレースメント、および結合に関する異なった規則による隣接の標準の連結、任意の連結、および仮想の連結。
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の連結は3、12、48、N、およびSTS-1がM<と共にSTS-N信号の中で合図するM x=M=192の連結(STS-mc)を許容します。 STS-mc記法は、SPEsが連結されたSTS-M信号について説明するための速記です。 参照[2]と[3]でそれぞれSDHとSonetのためのマルチプレクシング手順を与えます。 規制がSTS-mc信号のサイズに課されて、すなわち、それらは、3の倍数であり、彼らの始めの位置とインターリービングに関するそうでなければなりません。
Bernstein, et al. Informational [Page 17] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[17ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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の互換性で助けます(どんなSTS-1の同等な信号もSDHにありません)。 (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.
これらの損失のため、いくつかのSonetの喧嘩早い人メーカーが現在、「フレキシブルである」か任意の連結を支持します。 すなわち、彼らはSTS-mcのサイズで制限なしで連結を支持します、そして、(M<がNと等しい限り)STS-1 timeslotsにおけるどんな規制も以前はよくそれを運んでいませんでした、そして、すなわち、信号は使用可能時間スロットのどんな組み合わせも使用できます。
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]がCommittee T1によって承認されたSonetエンドSDH/システムサービスですが。 このサービスの本質は信号が単一の単位としてネットワークを通して運ばれるのが必要であるというよりもSDH/Sonetエンドシステムが別々の信号のVCsかSPEsを一緒にむしろ「にかわで接ぐこと」を持つことです。 仮想の連結に関する1つの例では、この特徴を支持する2台のエンドシステムは本質的には100Mbpsの効率的な輸送のためのSTS-1-2vへの「逆さのマルチプレックス」の2STS-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.
エンドシステムで仮想の連結を提供するので、それは既存のSDH/Sonetネットワークと互換性があります。 仮想の連結は、より高いオーダー信号と下位の信号の両方のために定義されます。 テーブル3は異なったより高いオーダー信号の中に含まれたいくつかの低いオーダーの実際には連結された信号のために用語体系と容量を示しています。
Bernstein, et al. Informational [Page 18] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[18ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
Table 3. Capacity of Virtually Concatenated VTn-Xv (9/G.707)
3を見送ってください。 実際には連結されたVTn-Xvの容量(9/G.707)
Carried In X Capacity In steps
of
In X Capacity In階段を運びます。
VT1.5/ STS-1/VC-3 1 to 28 1600kbit/s to 1600kbit/s
VC-11-Xv 44800kbit/s
1600kbit/s VC-11-Xv 44800kbit/sへの28 1600kbit/sへのVT1.5/STS-1/VC-3 1
VT2/ STS-1/VC-3 1 to 21 2176kbit/s to 2176kbit/s
VC-12-Xv 45696kbit/s
2176kbit/s VC-12-Xv 45696kbit/sへの21 2176kbit/sへのVT2/STS-1/VC-3 1
VT1.5/ STS-3c/VC-4 1 to 64 1600kbit/s to 1600kbit/s
VC-11-Xv 102400kbit/s
1600kbit/s VC-11-Xv 102400kbit/sへの64 1600kbit/sへのVT1.5/STS-3c/VC-4 1
VT2/ STS-3c/VC-4 1 to 63 2176kbit/s to 2176kbit/s
VC-12-Xv 137088kbit/s
2176kbit/s VC-12-Xv 137088kbit/sへの63 2176kbit/sへのVT2/STS-3c/VC-4 1
4.1.3. SDH/SONET Transparency
4.1.3. SDH/Sonet透明
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の目的は見え透いた方法によるペイロード信号を運ぶことになっています。 これはSonet自体のいくつかの層を含むことができます。 この例は経路オーバーヘッドに決して触れることができない状況です、それが実際にクライアントのものであるので。 これはSDH/Sonet経路オーバーヘッドで明白なラベルをコード化しない別の理由でした。 透明に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つの層がSonetオーバーヘッドに細かく分けられます: セクション、線、および経路。 それぞれのこれらの層は欠点と性能モニターに関係があります。 セクションオーバーヘッドは主として縁どりように関係がありますが、線オーバーヘッドは主としてマルチプレクシングと保護に関係があります。 (すなわち、50Mbpsか150のMbps塊のマルチプレクシング)、Sonetネットワーク要素を多重送信しながらパイプを実行するのは、線の終わりであるべきです。 しかしながら、すべてのSonet回線多重化装置/スイッチが、彼らを通り抜けながら、STS-1が、より高いオーダーSonet信号の中に含んだすべてにSonetのポインタ調整を実行するというわけではありません。 あるいはまた、彼らがポインタ調整を実行するなら、それらは線オーバーヘッドを終えません。 例えば、個々のSTS-1に標準の行指標調整を実行しないで、回線多重化装置は、4SONET STS-48に信号を連れて行って、それらをSTS-192に多重送信するかもしれません。 これは、Sonetを通過するのが望ましいかもしれないのでサービスが合図するように見られて、ネットワークを通して何らかのレベルの透明がある状態でSTS-12かSTS-48が好きであり、まだTDM技術を利用できます。 また、規制として透明なマルチプレクシングと切り換えを見なすことができます、いくつかの回線多重化装置とスイッチが他のものと同じくらいすばらしい粒状で切り替わらないかもしれないので。 テーブル4はSDH/Sonet透明のレベルをまとめます。
Bernstein, et al. Informational [Page 19] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[19ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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.
経路Layer(または、線のStandardの、より高いオーダーSonet経路Terminating)の切り換え。 線オーバーヘッドは、終えられるか、または変更されます。
Line Level (or Section Preserves line overhead and switches
Terminating) the entire line multiplex as a whole.
Section overhead is terminated or
modified.
全体で全体のLevel(または、セクションPreserves線オーバーヘッドとスイッチTerminating)線マルチプレックスを裏打ちしてください。 セクションオーバーヘッドは、終えられるか、または変更されます。
Section layer Preserves all section overhead,
Basically does not modify/terminate any
of the SDH/SONET overhead bits.
BasicallyはSDH/Sonet頭上のビットのいずれもすべてが頭上で区分する層のPreservesを区分してください、そして、変更するか、または終えません。
4.2. Protection
4.2. 保護
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/Sonet経路レベル[7]の両方([8])でさまざまな保護オプションを提供します。 平らな保護のテクニックが含む標準化されたSonet線: (APS)を切り換える1つの直線的な+1と直線的な1:N自動である保護とともに2ファイバーの、そして、4ファイバーの双方向の線はリング(BLSRs)を切り換えました。 経路層では、Sonetはuni方向の経路切り換えられたリング保護を提供します。 同様に、標準化されたSDHマルチプレックスセクション保護のテクニックは1の直線的な自動p保護の切り換えとともに2ファイバーの、そして、4ファイバーの双方向の+1と1:N MS-SPRingsを含んでいます(セクションによって共有されたProtectionリングスを多重送信してください)。
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線保護の両方が、「余分な交通」が保護線で運ばれるのを許容します、すなわち、失敗した作業工程の間交通を運ばないとき。 これらの保護方法はTable5にまとめられます。 これらの保護方法がどんなGMPLS層の保護や回復メカニズムからも完全に別々であることに注意されるべきです。
Bernstein, et al. Informational [Page 20] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[20ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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 サーキットの2つの端の間のコーディネートの+1 RequiresノーないUnidirectional。 専用保護線。
1+1 Bi- No Coordination via K byte
directional protocol. Lines must be
consistently configured.
Dedicated protection line.
1 Kバイトの方向のプロトコルを通した+1 両性愛者のノーCoordination。 一貫して線を構成しなければなりません。 専用保護線。
1:1 Yes Dedicated protection.
1:1はいDedicated保護。
1:N Yes One Protection line shared
by N working lines
1: N作業工程で共有されたNはいOne Protection線
4F-BLSR (4 Yes Dedicated protection, with
fiber bi- alternative ring path.
directional
line switched
ring)
4F-BLSR(ファイバーの両性愛者の代替のリング経路方向の線切り換えられたリングによる4はいDedicated保護)
2F-BLSR (2 Yes Dedicated protection, with
fiber bi- alternative ring path
directional
line switched
ring)
2F-BLSR(ファイバーの両性愛者の代替のリング経路方向の線切り換えられたリングによる2はいDedicated保護)
UPSR (uni- No Dedicated protection via
directional alternative ring path.
path switched Typically used in access
ring) networks.
UPSR(方向の代替のリング経路経路を通したuniいいえDedicated保護はアクセスリングで使用されるTypicallyを切り換えた)ネットワーク。
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
与えられたタイプの保護を支持する線の上に何人かの接続を発送するのは望ましいかもしれません、保護のない線の上、または、保護の上の「余分な交通」が立ち並んでいることときに他のものは発送されるかもしれませんが。 また、これらの様々な保護方法の構成を助けるために、そのままなルーティング・プロトコルのリンク保護属性の現在のGMPLSルーティング・プロトコルでしていた状態で広告を出すのも非常に貴重である場合があります。 例えば、1:N保護グループが2つのノードで構成されていると仮定してください。 利かせなければなりません。
Bernstein, et al. Informational [Page 21] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[21ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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.
線が接続の両端に関して「同じように付番されること」を確認していて、または、APS(K1/ケーツーバイト)プロトコルは正しく作動しないでしょう。
Table 6. Parameters defining protection mechanisms.
6を見送ってください。 保護メカニズムを定義するパラメタ。
Protection Comments
Related Link
Information
保護コメントはリンク情報について話しました。
Protection Type Indicates which of the protection types
delineated in Table 5.
Table5で図で表わされた状態で保護をタイプする保護Type Indicates。
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
または、数個保護Group Idを分類する保護Indicates、(直線的である、リング) そのaノードは属します。 ノードが参加するすべてのグループにユニークでなければなりません。
Working line Important in 1:N case and to differentiate
number between working and protection lines
1:Nの作業工程Importantがケースに入れる、働きと保護線の間の数を微分します。
Protection line Used to indicate if the line is a
number protection line.
線が数の防護物であるかどうかを示す保護線Usedは立ち並んでいます。
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.
Ifを層にしてください。この保護パラメタは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.
保護に関する未解決の問題は広めなければならない保護の情報の範囲です。 Table6のコンテンツは1つの極端を表します、簡単な列挙されたリストである間。(余分な交通/保護は立ち並んでいます、Unprotected、Shared(1:N)/作業工程、Dedicated、(1:1 1 +1) /働く線、Enhancedの(リング)/働く線) もう片方を表します。
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
[15] また、リンクバンドリング[13]のための潜在的含意があります、すなわち、各リンクに関して、ルーティング・プロトコルはそのリンクが働きかそれとも保護リンクであるか、そして、Table6からのことによるといくつかのパラメタの広告を出すかもしれません。 この計画の可能な欠点はルーティング・プロトコルが広告の特性で事実上、交通(例えば、専用保護リンク)を扱うルーティングに使用できなかったネットワークにおけるそれらの保護リンクにさえ負担されるだろうということです。 そして別法が働きを束ねるだろうことである。
Bernstein, et al. Informational [Page 22] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[22ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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.
保護を一緒にリンクします、そして、代わりにバンドルの広告を出してください。 今、それぞれの束ねられたリンクに関して、プロトコルは働くリンクで利用可能な帯域幅の量の広告を出さなければならないでしょう、バンドルの中の「余分な交通」を運ぶことができたそれらの保護リンクで利用可能な帯域幅の量と同様に。 これは、広告を出すために情報量を減少させるでしょう。 ここの問題は働きと保護リンクのどのタイプを一緒に束ねたらよいかを決めるだろうことです。 例えば、「共有される」リンク(彼らの対応する保護はリンクされる)が別々に保護されていた状態で「捧げられる」働くリンクから保護されたのは、バンドルの働きより望ましいかもしれません。
4.3. Available Capacity Advertisement
4.3. 利用可能な容量広告
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は1そのインタフェースに割り当てられるマルチプレックス構造の各信号を示すインタフェースあたり1個の内部のテーブルを維持しなければなりません。 この内部のテーブルはリンク用法と有効な容量の最も完全で正確な視点です。
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.
経路計算における使用のために、この情報は、同じドメインのすべての他のSDH/Sonet LSRsへの何らかの方法で広告を出す必要があります。 以下に関して達するように、オフである取り引きがあります。 リンク州のルーティング・プロトコルか頻度かこの情報がアップデートされる状態と、広告を出している情報の粒状による彼らの最初の試みのときに失敗の接続施設の割合と、範囲を通ってどのネットワーク資源に報告されるべきであるか利用可能な容量情報の詳細の量を最適化できます。 今日利用可能な容量情報のために考えられている総括の異なったレベルがあります。 1つの極端では、インタフェースに割り当てられるすべての信号は広告を出すことができました。 それとは正反対に、1リンクあたりの利用可能な帯域幅のただ一つの集められた値の広告を出すことができました。
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
最初に、Sonetの比較的簡単な構造とその最も一般的な現在の、そして、計画された用法を考えてください。 DS1sとDS3sはSONET STS-1の中でたいてい運ばれた信号です。 独身のDS3がSTS-1を占領するか、または最大28DS1s(それぞれ7つのバーモントグループの中の4)がSTS-1の中で運ばれます。 各ノードの中に合理的なVT1.5プレースメントアルゴリズムがある状態で、集合に関して全体のSTS-1(DS3sに捧げられる)の数に関する用法が使用した帯域幅とSTS-1の数がひたむきであるとこのために割り当てられたDS1sを運ぶのにただ報告するのは可能であるかもしれません。 この道、ネットワーク最適化プログラムは最小にするDS3sとDS1sの最適のプレースメントが転送ネットワークの中で様々な場所で半分空のSTS-1による帯域幅を浪費したことを決定しようとするかもしれません。 同様に最高のレートSonet信号(STS-Nc)のセットを考えてください。 2個のスイッチの間のリンクがフレキシブルな連結を支持するなら、報告は特にそうです。
Bernstein, et al. Informational [Page 23] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[23ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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].
簡単である、輸送されたSTS-Ncを包括するのにSTS-Mの中のSTS-1のどれかを使用できるので。 しかしながら、標準の連結だけが支持されるなら、STS-1を置くことができるところに規制があるので、報告は、より扱いにくくなります。 SDHには、まして、オプションと規制があります、したがって、どれがSDH/Sonetの帯域幅リソース有用性/用法の広告を出す最も良い方法であるかはまだ明確ではありません。 現在のところ、GMPLSルーティング・プロトコル拡張子は最小の、そして、最大の値を利用可能な帯域幅と定義します。(遠隔ノードはそれでいくつかの控除をリモートリンクに手があいている容量とそれが収容できる信号のタイプのおよそ量にすることができます)。 しかしながら、信号の多重送信された本質のためむしろただ一つの集合ビット伝送速度よりタイプに合図するために特定の帯域幅について報告するのは望ましいかもしれません。 これがそうであるかもしれない理由に関する詳細について、私たちはITU-T刊行物G.7715.1[16]と、そして、[17]の第12章に読者を差し向けます。
4.4. Path Computation
4.4. 経路計算
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のアルゴリズムは一度に、単独結合のためにリンク重りに関して最短パスを計算します。 これはネットワークリンク利用を最適化するために1セットの終点の間の接続のバッチをセットアップするという要求に対応して選択される経路と非常に異なっている場合があります。 人は時間内に、ネットワークのグローバルであるか地方の最適化の線に沿ってこれを考えることができます。
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と異なっている、-、すべてのノードが同じルーティング・アルゴリズムを走らせなければならない用法。
Bernstein, et al. Informational [Page 24] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[24ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
5. LSP Provisioning/Signaling for SDH/SONET
5. SDH/Sonetのために食糧を供給するか、または合図するLSP
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拡張子があるRSVPかCR-自由民主党などの一般的なシグナリングプロトコルは、回線交換アプリケーションのために適切に広がっていて、したがって、これらの相互運用性問題を解決するのを助けるかもしれません。このセクションで、私たちはSDH/Sonet LSPsの自動化された食糧を供給するのにかかわる様々なコンポーネントを調べます。
5.1. What Do We Label in SDH/SONET? Frames or Circuits?
5.1. 私たちはSDH/Sonetで何をラベルしますか? フレームですかそれともサーキットですか?
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.
初めはIPのような非同期な技術を制御するためにGMPLSを導入しました、IPパケットやFrame Relayフレームのように。そこでは、ラベルがそれぞれの個々のデータに取り付けられました。 しかしながら、SonetとSDHは私たちがSDH(または、Sonet)が多重送信すると呼んだマルチプレクシング構造(セクション3を見る)を定義する同期技術です。 このマルチプレックスは信号の階層構造にかかわって、下層階級信号は連続したより高いオーダーの中でものを埋め込みました(図1を参照してください)。 したがって、各信号は定期的に繰り返されるフレームから成って、階層構造でレベルによります、ある数の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「フレーム」にはそれ自身のラベルがある必要はなくて、それは個別にフレームを切り換えるのに必要でないのに続くことで見られるでしょう。 むしろ、切り換えられるユニットはフレームの与えられた位置に現れる時間帯の連続した系列から成る「流れ」です。 すなわち、私たちはSonetか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に適用されます。
Bernstein, et al. Informational [Page 25] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[25ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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つのノードの間に設立されるかもしれません、そして、後の下層階級LSPs(例えば、VC-12)はそのより高いオーダーLSPの中で作成されるかもしれません。 新しい(仮想の)リンクがForwarding Adjacency(FA)[14]を呼んだように、事実上、このVC-4 LSPをSDHネットワークにおける2つの非隣接している内部のノードの間に設立して、ルーティング・プロトコルは後で広告を出すことができます。
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.
Sonet SDH/LSRは、GMPLS操作を実現させるためにインタフェース単位で個別にそれぞれの可能な信号を特定しなければならないでしょう。 透明なままであるために、LSRは明らかにSDH/Sonetオーバーヘッドに触れるはずがありません。 これは明白なラベルがSDH/Sonetオーバーヘッドでコード化されない理由です。 むしろ、ラベルはそれぞれの個々の信号に関連しています。 このアプローチはλの切り換えのために考えられたものと同様です、それが、より複雑であるのを除いて、SonetとSDHが、より豊かなマルチプレクシング構造を定義するので。 したがって、ラベルは、各信号に関連していて、各インタフェースの各信号には、局所的にユニークです。 この信号は占領できました、そして、最もたぶん望んでください、そして、異なったインタフェースにおける異なった時間帯を占領してください。
5.2. Label Structure in SDH/SONET
5.2. SDH/Sonetのラベル構造
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 LSRsの間には、信号のためにラベルを割り当てる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
別の方法は命名木としてマルチプレックスを利用して、それぞれを割り当てる信号ナンバリングスキームについて工夫するために木を多重送信しながらSDH/Sonetの明確で有限な構造を使用することです。
Bernstein, et al. Informational [Page 26] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[26ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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].
エントリーのaユニークな関連価値を多重送信してください。 これはマルチプレックス木でそのタイプと位置に関してそれぞれのマルチプレックスエントリー(信号)のユニークな識別を許します。 ラベルとしてこのマルチプレックス入口値自体を使用することによって、私たちは自動的にSDH/Sonet意味論をラベルに加えます! したがって、単にラベルを調べることによって、人は現在直接、それが表す信号を推論できます、SDH/Sonetマルチプレックスの位置と同様に。 私たちはマルチプレックスのベースのラベリングにこれについて言及します。 これはSDH/Sonet[15]のためのGMPLSシグナリング仕様の法人組織である考えです。
5.3. Signaling Elements
5.3. シグナリング要素
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 REQUEST、([4]、3つの部品を含む[5])のように: タイプ、およびG-PIDを切り換えて、タイプをコード化するLSP。
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.
1番目は、LSPが表すSDH/Sonetマルチプレックスの中でLSPの自然/タイプか特定の信号に関する必要なSDH/Sonetチャンネル(または、信号の収集)を指定して、LSPの経路に沿ってすべてのノードによって使用されます。
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のように)はSENDERとして_TSPEC/FLOWSPECを使用しました:(TSPEC/FLOWSPECは7つの部品を含みます)。 タイプ、((RCC)(隣接のコンポーネント(NCC)の数)が付番する仮想のコンポーネント(NVC)の要求された隣接の連結)、乗数(MT)、透明、およびプロフィールに合図してください。
Bernstein, et al. Informational [Page 27] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[27ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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):
Signal Typeは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分野を使用するのによる)をElementary Signalに適用できます、近接して連結された信号をもたらして。
- Then, virtual concatenation (by using the NVC field) can be
optionally applied on the Elementary Signal, resulting in a
virtually concatenated signal.
- 次に、任意に、仮想の連結(NVC分野を使用するのによる)をElementary Signalに適用できます、実際には連結された信号をもたらして。
- 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ベースの信号よりむしろ信号としてフレームを要求するとき、3番目に、任意に、何らかの透明(Transparency分野を使用するのによる)を指定できます。
- 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番目に、任意に、Elementary Signalの直接上、または、第1段階から入手された近接して連結された信号の上、または、2番目のフェーズから入手された実際には連結された信号の上、または、何らかの透明に結合されたこれらの信号の上に乗法(Multiplier分野を使用するのによる)を適用できます。
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のもう一方の端で変更されていなくこれらのオーバーヘッドにおけるどの野原を届けなければならないかを正確に示します。 イングレスLSR要求透明は少しも変化なしで出口LSRに渡さなければならないこれらの頭上の野原を通り過ぎるでしょう。 LSRsが指す視点のイングレスと出口から、これらの分野を変更されないとみなさなければなりません。
Transparency is not applied at the interfaces with the initiating and terminating LSRs, but is only applied between intermediate LSRs.
透明は、開始とLSRsを終えるとのインタフェースで適用されませんが、中間的LSRsの間で適用されるだけです。
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のもののためにラベルする、([4]、[5])のように。
4. Local Link Selection, e.g., IF_ID_RSVP_HOP Object (as in [5]).
4. _例えば、_ID RSVP_HOP Objectであることでの地方のLink Selection、([5])のように。
Bernstein, et al. Informational [Page 28] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[28ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
6. Summary and Conclusions
6. 概要と結論
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.
私たちは、IP/MPLSメソッドの適用の2つの主な領域をすなわち、掘っていて合図しているTDMネットワークと考えて、Generalized MPLSルーティングとシグナリングがTDMネットワークの文脈でどう使用されるかについて議論しました。 私たちは詳細に、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が、ある信頼性を獲得するのに経路に沿った各ホップで使用したがっているリンクの特性に焦点を合わせて。
7. Security Considerations
7. セキュリティ問題
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ネットワークを通した支給の接続性への制御飛行機の使用は管理飛行機から制御飛行機にセキュリティ負担をかなり移動させます。 制御飛行機の導入の前に、管理局(要素Management SystemsかNetwork Management Systems)とネットワーク接続に参加したそれぞれのネットワーク要素の間には、保証されなければならなかったコミュニケーションがありました。 制御飛行機の導入の後に、機密保護される必要がある唯一の管理飛行機コミュニケーションは終わりから終わりとしてのギヤエンド(イングレス)のネットワーク・ノードに、サービスが要求されているということです。 他方では、制御飛行機はネットワーク飛行機の隣接しているノードの安全なシグナリングとルーティングコミュニケーションに新しい要件を紹介します。
Bernstein, et al. Informational [Page 29] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[29ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
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などのネットワーク管理プロトコルのunsecureバージョンが転送ネットワークでポピュラーな構成ツールであったところでは、制御飛行機の使用はデータ通信量の妨害か分裂を引き起こす場合があったネットワーク資源の悪意があって誤った課題のセキュリティリスクをかなり減少させるかもしれません。
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ルーティングとプロトコルに合図するためのそうです。
8. Acknowledgements
8. 承認
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.
私たちはTDMネットワークにおけるGMPLS問題に関する一定の調査がこのドキュメントの書くことを動機づけて、質問がコンテンツを形成するのを助けたMPLSとCCAMP WGsの参加者各位を承認します。 また、彼の彼のこのドキュメントの最後のバージョンの熟読、役に立つコメント、およびフィードバックのためのKireeti Kompellaと、そして、助ける多くの役に立つ入力がこのドキュメントが最後に通ったので規格evolutionsに従うためにドキュメントをアップデートするなら呼ぶルート設定Area Directorateを代表した彼のレビューのためのディミトリPapadimitriouをありがとうございます。
Bernstein, et al. Informational [Page 30] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[30ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
9. Informative References
9. 有益な参照
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] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換えアーキテクチャ」、RFC3031、2001年1月。
[2] G.707, Network Node Interface for the Synchronous Digital
Hierarchy (SDH), International Telecommunication Union, March
1996.
[2] G.707、1996年3月に同期デジタルハイアラーキ(SDH)、国際電気通信連合のためにノードインタフェースをネットワークでつないでください。
[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、Multiplex Structure、Rates、およびFormats、American National Standards Institutを含む同期式光通信網(Sonet)の基本的な記述。
[4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description", RFC 3471, January 2003.
[4] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、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] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、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] バーンスタイン、G.、イェイツ、J.、シャハ、「光学のIP中心のコントロールと経営者側はネットワークを輸送すること」が(IEEEコミュニケーション雑誌)(Vol.40)10、2000年10月を発行するD.。
[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 Institut。
[8] G.841, Types and Characteristics of SDH Network Protection
Architectures, ITU-T, July 1995.
[8] SDHのG.841、タイプ、および特性は1995年7月に保護アーキテクチャ、ITU-Tをネットワークでつなぎます。
[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.、エドY.Rekhter、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)を支持して拡大を発送すること」でのRFC4202(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.、エドY.Rekhter、「一般化されたマルチプロトコルラベルを支持したOSPF拡張子は(GMPLS)を切り換えること」でのRFC4203(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.、Y.Rekhter、エド、「中間システムへの中間システム、(-、)、一般化されたマルチプロトコルを支持した拡大が切り換え(GMPLS)をラベルする、」、RFC4205(2005年10月)
Bernstein, et al. Informational [Page 31] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[31ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
[12] Bernstein, G., Sharma, V., Ong, L., "Inter-domain Optical
Routing," OSA J. of Optical Networking, vol. 1, no. 2, pp. 80-
92.
[12] バーンスタイン、G.、シャルマ、V.、オング、L.、「相互ドメインの光のルート設定」、Optical NetworkingのOSA J.、vol.1、No.2、ページ 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.バーガー、「MPLS交通工学(Te)におけるリンクバンドリング」、RFC4201、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)を階層構造とラベルします」、RFC4206、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] マニー(E.とD.Papadimitriou)は、「同期式光通信網(Sonet)と同期デジタルハイアラーキ(SDH)コントロールのためのマルチプロトコルラベルスイッチング(GMPLS)拡大を一般化しました」、RFC3946、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] バーンスタイン、G.、Rajagopalan、R.、シャハ、D.、「光学ネットワークは以下を制御します」。 「プロトコル、アーキテクチャ、および規格」、アディソン・ウエスリー、7月2003日
Bernstein, et al. Informational [Page 32] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[32ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
10. Acronyms
10. 頭文字語
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--American National Standards Institut APS--自動保護切り換え気圧--非同期通信モードBLSR--双方向のライン・スイッチリングCPE--顧客前提設備DLCI--データリンク接続識別子ETSI--ヨーロッパの電気通信; 同等クラスGMPLS--一般化されたMPLS IP--インターネットプロトコルを進めて、規格がFECを設ける、-、--中間システム(RP)自由民主党への中間システム--ラベル分配プロトコルLSP--ラベルは経路LSRを切り換えました--切り換えルータMPLSをラベルしてください; - マルチプロトコルラベルスイッチングNMS--ネットワーク管理システムOSPF--開いている最短パス最初(RP)のPNNI--個人的なネットワーク・ノードインタフェースppp--ポイント・ツー・ポイントプロトコルQoS--サービスの質RP--ルーティング・プロトコルRSVP--予約プロトコルSDH--同期デジタルハイアラーキSNMP--簡単なネットワーク管理プロトコルSonet--同期光学ネットワークSPE--Sonet有効搭載量封筒STM--同期輸送モジュール(または、マルチプレクサ・ターミナル装置)STS--同期輸送信号TDM--時間事業部μltiplexer TE--トラフィックEngineering TMN--Management Network UPSR--Uni方向のPath Switch Ring VC--電気通信の仮想のContainer(SDH)かVirtual Circuit VCI--仮想のCircuit Identifier(ATM)VPI--仮想のPath Identifier(ATM)バーモント--仮想のTributary WDM--波長事業部Multiplexing
Bernstein, et al. Informational [Page 33] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[33ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
Author's Addresses
作者のアドレス
Greg Bernstein Grotto Networking
グレッグバーンスタイン洞窟ネットワーク
Phone: +1 510 573-2237 EMail: gregb@grotto-networking.com
以下に電話をしてください。 +1 510 573-2237 メールしてください: gregb@grotto-networking.com
Eric Mannie Perceval Rue Tenbosch, 9 1000 Brussels Belgium
エリックマニーPerceval悔悟Tenbosch、9 1000ブリュッセルベルギー
Phone: +32-2-6409194 EMail: eric.mannie@perceval.net
以下に電話をしてください。 +32-2-6409194はメールされます: eric.mannie@perceval.net
Vishal Sharma Metanoia, Inc. 888 Villa Street, Suite 500 Mountain View, CA 94041
VishalシャルマMetanoia, Inc.888Villa通り、Suite500マウンテンビュー、カリフォルニア 94041
Phone: +1 650 641 0082 Email: v.sharma@ieee.org
以下に電話をしてください。 +1 0082年の650 641メール: v.sharma@ieee.org
Eric Gray Marconi Corporation, plc 900 Chelmsford Street Lowell, MA 01851 USA
エリックグレーマルコニー社、plc900チェルムズフォード通りローウェル、MA01851米国
Phone: +1 978 275 7470 EMail: Eric.Gray@Marconi.com
以下に電話をしてください。 +1 7470年の978 275メール: Eric.Gray@Marconi.com
Bernstein, et al. Informational [Page 34] RFC 4257 GMPLS based Control of SDH/SONET December 2005
バーンスタイン、他 情報[34ページ]のRFC4257GMPLSは2005年12月にSDH/SonetのControlを基礎づけました。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bernstein, et al. Informational [Page 35]
バーンスタイン、他 情報[35ページ]
一覧
スポンサーリンク
