RFC2892 日本語訳
2892 The Cisco SRP MAC Layer Protocol. D. Tsiang, G. Suwala. August 2000. (Format: TXT=107645 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Tsiang
Request for Comments: 2892 G. Suwala
Category: Informational Cisco Systems
August 2000
Tsiangがコメントのために要求するワーキンググループD.をネットワークでつないでください: 2892年のG.Suwalaカテゴリ: 情報のシスコシステムズ2000年8月
The Cisco SRP MAC Layer Protocol
コクチマスSRP MAC層のプロトコル
Status of this Memo
この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 (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document specifies the MAC layer protocol, "Spatial Reuse Protocol" (SRP) for use with ring based media. This is a second version of the protocol (V2).
このドキュメントはMAC層のプロトコル、リングが基づいている使用のための「空間的な再利用プロトコル」(SRP)メディアを指定します。 これはプロトコル(V2)の第2のバージョンです。
The primary requirements for SRP are as follows:
SRPのための第一の要件は以下の通りです:
- Efficient use of bandwidth using:
spatial reuse of bandwidth
local reuse of bandwidth
minimal protocol overhead
- Support for priority traffic
- Scalability across a large number of nodes or stations attached to
a ring
- "Plug and play" design without a software based station management
transfer (SMT) protocol or ring master negotiation as seen in
other ring based MAC protocols [1][2]
- Fairness among nodes using the ring
- Support for ring based redundancy (error detection, ring wrap,
etc.) similar to that found in SONET BLSR specifications.
- Independence of physical layer (layer 1) media type.
- 帯域幅使用の効率的な使用: 帯域幅の最小量のプロトコルオーバーヘッドの帯域幅の地方の再利用の空間的な再利用--優先権交通のサポート--多くのノードかステーションの向こう側のスケーラビリティはリングに付きました--ソフトウェアのない「プラグアンドプレイ」デザインはステーション管理を基礎づけました; 転送(SMT)は議定書を作るか、または他のリングの見られるリングマスター交渉がMACプロトコル12--リングを使用するノードの中の公正--リングのベースの冗長のサポートを基礎づけました。(誤り検出、SONET BLSR仕様において見つけられたそれと同様のリング包装など。 - 物理的な層(層1)のメディアタイプからの独立。
This document defines the terminology used with SRP, packet formats, the protocol format, protocol operation and associated protocol finite state machines.
このドキュメントは有限州が機械加工するSRPと共に使用される用語、パケット・フォーマット、プロトコル書式、プロトコル操作、および関連プロトコルを定義します。
Tsiang & Suwala Informational [Page 1] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[1ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
Table of Contents
目次
1. Differences between SRP V1 and V2 ....................... 3
2. Terms and Taxonomy ...................................... 4
2.1. Ring Terminology .................................. 4
2.2. Spatial Reuse ..................................... 5
2.3. Fairness .......................................... 6
2.4. Transit Buffer .................................... 7
3. SRP Overview ............................................ 8
3.1. Receive Operation Overview ........................ 8
3.2. Transmit Operation Overview ....................... 8
3.3. SRP Fairness Algorithm (SRP-fa) Overview .......... 9
3.4. Intelligent Protection Switching (IPS) Protocol
Overview .......................................... 9
4. Packet Formats .......................................... 13
4.1. Overall Packet Format ............................. 13
4.2. Generic Packet Header Format ...................... 14
4.2.1. Time To Live (TTL) ......................... 14
4.2.2. Ring Identifier (R) ........................ 15
4.2.3. Priority Field (PRI) ....................... 15
4.2.4. MODE ....................................... 15
4.2.5. Parity Bit (P-bit) ......................... 16
4.2.6. Destination Address ........................ 16
4.2.7. Source Address ............................. 16
4.2.8. Protocol Type .............................. 16
4.3. SRP Cell Format ................................... 16
4.4. SRP Usage Packet Format ........................... 17
4.5. SRP Control Packet Format ......................... 18
4.5.1. Control Ver ................................ 19
4.5.2. Control Type ............................... 19
4.5.3. Control TTL ................................ 19
4.5.4. Control Checksum ........................... 19
4.5.5. Payload .................................... 20
4.5.6. Addressing ................................. 20
4.6. Topology Discovery ................................ 20
4.6.1. Topology Length ............................ 22
4.6.2. Topology Originator ........................ 22
4.6.3. MAC bindings ............................... 22
4.6.4. MAC Type Format ............................ 22
4.7. Intelligent Protection Switching (IPS) ............ 23
4.7.1. Originator MAC Address ..................... 23
4.7.2. IPS Octet .................................. 24
4.8. Circulating packet detection (stripping) .......... 24
5. Packet acceptance and stripping ......................... 25
5.1. Transmission and forwarding with priority ......... 27
5.2. Wrapping of Data .................................. 28
6. SRP-fa Rules Of Operation ............................... 28
6.1. SRP-fa pseudo-code ................................ 30
1. SRP V1とV2の違い… 3 2. 用語と分類学… 4 2.1. 用語を鳴らしてください… 4 2.2. 空間的な再利用… 5 2.3. 公正… 6 2.4. トランジットバッファ… 7 3. SRP概観… 8 3.1. 操作概観を受けてください… 8 3.2. 操作概観を伝えてください… 8 3.3. SRP公正アルゴリズム(SRP-ファ)概観… 9 3.4. 知的な保護切り換え(IPS)は概観について議定書の中で述べます… 9 4. パケット形式… 13 4.1. 総合的なパケット・フォーマット… 13 4.2. 一般的なパケットヘッダー形式… 14 4.2.1. 生きる時間(TTL)… 14 4.2.2. 識別子(R)を鳴らしてください… 15 4.2.3. 優先権分野(PRI)… 15 4.2.4. モード… 15 4.2.5. パリティビット(Pで噛み付いている)… 16 4.2.6. 送付先アドレス… 16 4.2.7. ソースアドレス… 16 4.2.8. タイプについて議定書の中で述べてください… 16 4.3. SRPセル形式… 16 4.4. SRP用法パケット・フォーマット… 17 4.5. SRPはパケット・フォーマットを制御します… 18 4.5.1. Verを制御してください… 19 4.5.2. タイプを監督してください… 19 4.5.3. TTLを制御してください… 19 4.5.4. チェックサムを制御してください… 19 4.5.5. 有効搭載量… 20 4.5.6. 記述します。 20 4.6. トポロジー発見… 20 4.6.1. トポロジーの長さ… 22 4.6.2. トポロジー創始者… 22 4.6.3. MAC結合… 22 4.6.4. MACは書式をタイプします… 22 4.7. 知的な保護の切り換え(IPS)… 23 4.7.1. 創始者マックーアドレス… 23 4.7.2. IPS八重奏… 24 4.8. パケット検出(剥取る)を循環させます… 24 5. パケット承認であって剥取ること… 25 5.1. 優先権があるトランスミッションと推進… 27 5.2. データのラッピング… 28 6. 操作のSRP-ファ規則… 28 6.1. SRP-ファ中間コード… 30
Tsiang & Suwala Informational [Page 2] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[2ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
6.2. Threshold settings ................................ 32
7. SRP Synchronization ..................................... 32
7.1. SRP Synchronization Examples ...................... 33
8. IPS Protocol Description ................................ 34
8.1. The IPS Request Types ............................. 35
8.2. SRP IPS Protocol States ........................... 36
8.2.1. Idle ....................................... 36
8.2.2. Pass-through ............................... 36
8.2.3. Wrapped .................................... 36
8.3. IPS Protocol Rules ................................ 36
8.3.1. SRP IPS Packet Transfer Mechanism .......... 36
8.3.2. SRP IPS Signaling and Wrapping Mechanism ... 37
8.4. SRP IPS Protocol Rules ............................ 38
8.5. State Transitions ................................. 41
8.6. Failure Examples .................................. 41
8.6.1. Signal Failure - Single Fiber Cut Scenario . 41
8.6.2. Signal Failure - Bidirectional Fiber Cut
Scenario ................................... 43
8.6.3. Failed Node Scenario ....................... 45
8.6.4. Bidirectional Fiber Cut and Node Addition
Scenarios .......................................... 47
9. SRP over SONET/SDH ...................................... 48
10. Pass-thru mode .......................................... 49
11. References .............................................. 50
12. Security Considerations ................................. 50
13. IPR Notice .. ........................................... 50
14. Acknowledgments ......................................... 50
15. Authors' Addresses ...................................... 51
16. Full Copyright Statement ................................ 52
6.2. 敷居設定… 32 7. SRP同期… 32 7.1. SRP同期の例… 33 8. IPSは記述について議定書の中で述べます… 34 8.1. IPSはタイプを要求します… 35 8.2. SRP IPSは州について議定書の中で述べます… 36 8.2.1. 怠けてください… 36 8.2.2. 通り抜けてください… 36 8.2.3. 包装されます… 36 8.3. IPSは規則について議定書の中で述べます… 36 8.3.1. SRP IPSパケットトランスファ・メカニズム… 36 8.3.2. メカニズムに…合図して、包装するSRP IPS 37 8.4. SRP IPSは規則について議定書の中で述べます… 38 8.5. 変遷を述べてください… 41 8.6. 失敗の例… 41 8.6.1. 失敗に合図してください--ただ一つのファイバーカットシナリオ. 41 8.6.2。 失敗に合図してください--双方向のファイバーカットシナリオ。 43 8.6.3. ノードシナリオに失敗します… 45 8.6.4. 双方向のファイバーカットとノード添加シナリオ… 47 9. Sonet/SDHの上のSRP… 48 10. 徹底的なパスモード… 49 11. 参照… 50 12. セキュリティ問題… 50 13. IPRは気付きます。 ........................................... 50 14. 承認… 50 15. 作者のアドレス… 51 16. 完全な著作権宣言文… 52
1. Differences between SRP V1 and V2
1. SRP V1とV2の違い
This document pertains to SRP V2. SRP V1 was a previously published draft specification. The following lists V2 feature differences from V1:
このドキュメントはSRP V2に関係します。 SRP V1は以前に広められた草稿仕様でした。 以下のリストV2はV1から違いを特徴とします:
- Reduction of the header format from 4 bytes to 2 bytes.
- ヘッダー形式の4バイトから2バイトまでの減少。
- Replacement of the keepalive packet with a new control packet that
carries usage information in addition to providing a keepalive
function.
- keepalive機能を提供することに加えて用法情報を運ぶ新しいコントロールパケットとのkeepaliveパケットの交換。
- Change bit value of inner ring to be 1 and outer to be 0.
- 内側の変更ビット値は1になるように鳴ります、そして、外側であることは、0です。
- Reduction in the number of TTL bits from 11 to 8.
- 11〜8までのTTLビットの数の減少。
- Removal of the DS bit.
- DSの解任に噛み付きました。
Tsiang & Suwala Informational [Page 3] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[3ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
- Change ordering of CRC transmission to be most significant octet
first (was least significant octet in V1). The SRP CRC is now the
same as in [5].
- CRCについて最初に(V1で最も重要でない八重奏であった)トランスミッションが最も重要な八重奏であるよう命令して、変化してください。 SRP CRCは現在、[5]と同じです。
- Addition of the SRP cell mode to carry ATM cells over SRP.
- SRPの上までATMセルを運ぶSRPセルモードの添加。
- Changes to the SRP-fa to increase the usage field width and to
remove the necessity of adding a fixed constant when propagating
usage messages.
- 用法欄の幅を増加させて、用法メッセージを伝播するとき固定定数を加えるという必要性を取り除くSRP-ファへの変化。
2. Terms and Taxonomy
2. 用語と分類学
2.1. Ring Terminology
2.1. リング用語
SRP uses a bidirectional ring. This can be seen as two symmetric counter-rotating rings. Most of the protocol finite state machines (FSMs) are duplicated for the two rings.
SRPは双方向のリングを使用します。 これを2個の左右対称のカウンタを回転させるリングと考えることができます。 プロトコル有限状態機械(FSMs)の大部分は2個のリングのためにコピーされます。
The bidirectional ring allows for ring-wrapping in case of media or station failure, as in FDDI [1] or SONET/SDH [3]. The wrapping is controlled by the Intelligent Protection Switching (IPS) protocol.
双方向のリングはFDDI[1]かSonet/SDH[3]のようにメディアかステーションの場合のリングラッピング故障を考慮します。 ラッピングはIntelligent Protection Switching(IPS)プロトコルによって制御されます。
To distinguish between the two rings, one is referred to as the "inner" ring, the other the "outer" ring. The SRP protocol operates by sending data traffic in one direction (known as "downstream") and it's corresponding control information in the opposite direction (known as "upstream") on the opposite ring. Figure 1 highlights this graphically.
2個のリングを見分けるために、1は「内側」のリングと呼ばれて、もう片方が「外側」のリングです。 SRPプロトコルは一方向(「川下」として、知られている)でのデータ通信量を送ることによって、作動します、そして、それは反対のリングの上の逆方向(「上流」として、知られている)への対応する制御情報です。 図1はグラフィカルにこれを強調します。
Tsiang & Suwala Informational [Page 4] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[4ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
FIGURE 1. Ring Terminology
図1 リング用語
{outer_data
----- inner_ctl}
---------------->| N |-----------------
| ---------------| 1 |<-------------- |
| | {inner_data ----- | |
| | outer_ctl} | |
----- -----
| N | | N |
| 6 | | 2 |
----- -----
^ | ^ |
o | | i | |
u | | n | |
t | | n | |
e | | e | |
r | | r | |
| v | v
----- -----
| N | | N |
| 5 | | 3 |
----- -----
| | | |
| | ----- | |
| -------------->| N |--------------- |
-----------------| 4 |<----------------
-----
外側の_データ、-、-、-、--内側の_がctlされる---------------->| N|----------------- | ---------------| 1 | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 内側の_データ、-、-、-、--| | | | 外側の_がctlされる| | ----- ----- | N| | N| | 6 | | 2 | ----- ----- ^ | ^ | o | | i| | u| | n| | t| | n| | e| | e| | r| | r| | | v| v----- ----- | N| | N| | 5 | | 3 | ----- ----- | | | | | | ----- | | | -------------->| N|--------------- | -----------------| 4 | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- -----
2.2. Spatial Reuse
2.2. 空間的な再利用
Spatial Reuse is a concept used in rings to increase the overall aggregate bandwidth of the ring. This is possible because unicast traffic is only passed along ring spans between source and destination nodes rather than the whole ring as in earlier ring based protocols such as token ring and FDDI.
空間的なReuseはリングの総合的な集合帯域幅を増加させるのにリングで使用される概念です。 リングが前でトークンリングやFDDIなどのプロトコルを基礎づけてユニキャスト交通が全体のリングよりむしろソースと目的地ノードの間のリングの長さに沿って流れるだけであるので、これは可能です。
Figure 2 below outlines how spatial reuse works. In this example, node 1 is sending traffic to node 4, node 2 to node 3 and node 5 to node 6. Having the destination node strip unicast data from the ring allows other nodes on the ring who are downstream to have full access to the ring bandwidth. In the example given this means node 5 has full bandwidth access to node 6 while other traffic is being simultaneously transmitted on other parts of the ring.
以下の図2は空間的な再利用がどう働いているかを概説します。 この例では、ノード1はノード4に交通を送ります、ノード3とノード2からノード5からノード6。 リング帯域幅に完全に近づく手段を持つために川下であることでリングからのデータがリングの上のそうする他のノードを許容する目的地ノード片ユニキャストを持っています。 出された例では、これは、他の交通が同時にリングの他の部分で伝えることにされるのである間ノード5が完全な帯域幅アクセスをノード6に持っていることを意味します。
Tsiang & Suwala Informational [Page 5] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[5ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
2.3. Fairness
2.3. 公正
Since the ring is a shared media, some sort of access control is necessary to ensure fairness and to bound latency. Access control can be broken into two types which can operate in tandem:
リングが共有されたメディアであることで、ある種のアクセス管理が、公正と制限された潜在に確実にするのに必要です。 2人乗り自転車で働くことができる2つのタイプにアクセス管理を始めることができます:
Global access control - controls access so that everyone gets a
fair share of the global bandwidth of the ring.
グローバルなアクセスは制御されます--アクセスを制御するので、皆はリングのグローバルな帯域幅の正当な分け前を得ます。
Local access control - grants additional access beyond that
allocated globally to take advantage of segments of the ring that
are less than fully utilized.
地方のアクセス管理--それを超えた追加アクセスが完全にそれほど利用されないというわけではないリングのセグメントを利用するためにグローバルに割り当てた交付金。
As an example of a case where both global and local access are required, refer again to Figure 2. Nodes 1, 2, and 5 will get 1/2 of the bandwidth on a global allocation basis. But from a local perspective, node 5 should be able to get all of the bandwidth since its bandwidth does not interfere with the fair shares of nodes 1 and 2.
グローバルなものと同様に地方のアクセスが必要であるケースに関する例に、もう一度図2を参照してください。 ノード1、2、および5はグローバルな配分基礎で1/2の帯域幅を手に入れるでしょう。 しかし、帯域幅がノード1と2の正当な分け前を妨げないので、ローカルの見解から、ノード5は帯域幅のすべてを得るはずであることができます。
Tsiang & Suwala Informational [Page 6] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[6ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
FIGURE 2. Global and Local Re-Use
図2 グローバルで地方の再使用
. . . . . . . . . . . . . . . . .
. .
----- .
---------------->| N |----------------- .
| ---------------| 1 |<-------------- | .
| | ----- | | .
| | | | .
----- ----- .
. .>| N | | N |. .. .
. | 6 | | 2 | . .
. ----- ----- . .
. ^ | ^ | . .
. o | | i | | . .
. u | | n | | . .
. t | | n | | . .
. e | | e | | . .
. r | | r | | . .
. | v | v . .
. ----- ----- . .
. . | N | | N |<. . .
| 5 | | 3 | .
----- ----- .
| | | | .
| | ----- | | .
| -------------->| N |--------------- | .
-----------------| 4 |<---------------- .
----- .
^ .
. .
. . . . .<. . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . ----- . ---------------->| N|----------------- . | ---------------| 1 | <、-、-、-、-、-、-、-、-、-、-、-、-、--、| . | | ----- | | . | | | | . ----- ----- . . . >| N| | N|. .. . . | 6 | | 2 | . . . ----- ----- . . . ^ | ^ | . . . o | | i| | . . . u| | n| | . . . t| | n| | . . . e| | e| | . . . r| | r| | . . . | v| v…----- ----- . . . . | N| | N|<。 . . | 5 | | 3 | . ----- ----- . | | | | . | | ----- | | . | -------------->| N|--------------- | . -----------------| 4 | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- . ----- . ^… <。 . . . . . . . . . . .
2.4. Transit Buffer
2.4. トランジットバッファ
To be able to detect when to transmit and receive packets from the ring, SRP makes use of a transit (sometimes referred as insertion) buffer as shown in Figure 3 below. High priority packets and low priority packets can be placed into separate fifo queues.
リングからパケットをいつ送受信するかを検出できるように、SRPは以下の図3に示されるようにトランジット(挿入として時々参照される)バッファを利用します。 高い優先権パケットと低い優先権パケットを別々のfifo待ち行列に置くことができます。
Tsiang & Suwala Informational [Page 7] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[7ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
FIGURE 3. Transit buffer
図3 トランジットバッファ
^^ ||
|| vv
|----| |----|
| | | |
|----|Rx |----|Tx
| |Buffer | |Buffer
|----| |----|
| | | |
|----| |----|
| | | |
|----| |----|
| | | |
|----| |----|
^^ Transit ||
|| Buffer ||
|| |------| vv
| H |
===========>|------|==========>
| L |
|------|
^^ || || vv|----| |----| | | | | |----|Rx|----|Tx| |バッファ| |バッファ|----| |----| | | | | |----| |----| | | | | |----| |----| | | | | |----| |----| ^^トランジット|| || バッファ|| || |------| vv| H| ===========>|、-、-、-、-、--、|==========>| L| |------|
3. SRP Overview
3. SRP概観
3.1. Receive Operation Overview
3.1. 操作概観を受けてください。
Receive Packets entering a node are copied to the receive buffer if a Destination Address (DA) match is made. If a DA matched packet is also a unicast, then the packet will be stripped. If a packet does not DA match or is a multicast and the packet does not Source Address (SA) match, then the packet is placed into the Transit Buffer (TB) for forwarding to the next node if the packet passes Time To Live and Cyclic Redundancy Check (CRC) tests.
ノードを入力して、Packetsを受けてください。(DA)が合っているDestination Addressが作られるなら、受信バッファにコピーされます。 また、DAの取り組んでいるパケットがユニキャストであるなら、パケットを剥取るでしょう。 パケットがどんなDAマッチもしないか、マルチキャストであり、パケットがTime To LiveとCyclic Redundancy Check(CRC)にテストに合格して、パケットが(SA)が合っているどんなSource Addressもしないなら、パケットは次のノードへの推進のためにTransit Buffer(TB)に置かれます。
3.2. Transmit Operation Overview
3.2. 操作概観を伝えてください。
Data sent from the node is either forwarded data from the TB or transmit data originating from the node via the Tx Buffer. High priority forwarded data always gets sent first. High priority transmit data may be sent as long as the Low Priority Transit Buffer (LPTB) is not full.
ノードから送られたデータはTBからデータを転送するか、またはTx Bufferを通してノードから発するデータを送ることです。 最初に、いつも高い優先権転送されたデータを送ります。 高い優先度はデータを送ります。Low Priority Transit Buffer(LPTB)が完全でない限り、送るかもしれません。
A set of usage counters monitor the rate at which low priority transmit data and forwarded data are sent. Low priority data may be sent as long as the usage counter does not exceed an allowed usage governed by the SRP-fa rules and the LPTB has not exceeded the low priority threshold.
1セットのそれの低い優先度がデータを送るカウンタがレートをモニターする用法と転送されたデータを送ります。 用法カウンタがSRP-ファ規則で支配された許容用法を超えていない限り、少ない優先権データを送るかもしれません、そして、LPTBは低優先権敷居を超えていません。
Tsiang & Suwala Informational [Page 8] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[8ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
3.3. SRP Fairness Algorithm (SRP-fa) Overview
3.3. SRP公正アルゴリズム(SRP-ファ)概観
If a node experiences congestion, then it will advertise to upstream nodes via the opposite ring the value of its transmit usage counter. The usage counter is run through a low pass filter function to stabilize the feedback. Upstream nodes will adjust their transmit rates so as not to exceed the advertised values. Nodes also propagate the advertised value received to their immediate upstream neighbor. Nodes receiving advertised values who are also congested propagate the minimum of their transmit usage and the advertised usage.
ノードが混雑になるなら正反対を通したノードが値を鳴らす上流に広告を出す、それ、用法カウンタを伝えてください。 用法カウンタは、フィードバックを安定させるためにローパスフィルタ機能を通って走ります。 上流のノードが適応する、それら、広告を出している値を超えないようにレートを伝えてください。 また、ノードは彼らの即座の上流の隣人に広告を出している対価領収を伝播します。 また、充血する広告を出している値を受けると最小限が伝播されるノード、それら、用法と広告を出している用法を伝えてください。
Congestion is detected when the depth of the low priority transit buffer reaches a congestion threshold.
少ない優先権トランジットバッファの深さが混雑敷居に達するとき、混雑は検出されます。
Usage messages are generated periodically and also act as keepalives informing the upstream station that a valid data link exists.
用法メッセージは、定期的に発生して、また、有効データリンクが存在することを上流のステーションに知らせるkeepalivesとして機能します。
3.4. Intelligent Protection Switching (IPS) Protocol Overview
3.4. 知的な保護の切り換え(IPS)プロトコル概観
An SRP Ring is composed of two counter-rotating, single fiber rings. If an equipment or fiber facility failure is detected, traffic going towards and from the failure direction is wrapped (looped) back to go in the opposite direction on the other ring (subject to the protection hierarchy). The wrap around takes place on the nodes adjacent to the failure, under control of the IPS protocol. The wrap re-routes the traffic away from the failed span.
SRP Ringは2個のカウンタを回転させて、単一のファイバーリングで構成されます。 設備かファイバー施設失敗が検出されるなら、指示と失敗指示から行く交通は、もう片方のリング(保護階層構造を条件とした)の上に逆コースを行くために包装し返されます(輪にされます)。 失敗に隣接しておよそ包装はノードの上でIPSプロトコルのコントロールの下で行われます。 包装は失敗した長さから遠くで交通を別ルートで送ります。
An example of the data paths taken before and after a wrap are shown in Figures 4 and 5. Before the fiber cut, N4 sends to N1 via the path N4->N5->N6->N1.
包装の前後に取られたデータ経路に関する例は図4と5に示されます。 以前ファイバーは切れて、経路N4を通って>N5->をN1に発信させているN4はN6->です。N1。
If there is a fiber cut between N5 and N6, N5 and N6 will wrap the inner ring to the outer ring. After the wraps have been set up, traffic from N4 to N1 initially goes through the non-optimal path N4->N5->N4->N3->N2->N1->N6->N1.
N5とN6の間には、ファイバーカットがあると、N5とN6は外側のリングにインナー・リングを包装するでしょう。 機密がセットアップされた後に、N4からN1までの交通が初めは非最適経路N4->を通る、N5、-、>N4->、N3、-、>N2->、N1、-、>N6->、N1。
Subsequently a new ring topology is discovered and a new optimal path is used N4->N3->N2-N1 as shown in Figure 6. Note that the topology discovery and the subsequent optimal path selection are not part of the IPS protocol.
次に、新しいリングトポロジーが発見されて、新しい最適経路が中古のN4->である、N3、-、図6で見せられる>N2-N1 トポロジー発見とその後の最適経路選択がIPSプロトコルの一部でないことに注意してください。
Tsiang & Suwala Informational [Page 9] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[9ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
FIGURE 4. Data path before wrap, N4 -> N1
図4 包装の前のデータ経路、N4->N1
-----
################>| N |-----------------
# ---------------| 1 |<-------------- |
# | ----- | |
# | | |
----- -----
| N | | N |
| 6 | | 2 |
----- -----
^ | ^ |
# | | |
# | | |
# | | |
# | | |
# | | |
# v | v
----- -----
| N | | N |
| 5 | | 3 |
----- -----
# | | |
# | ----- | |
# -------------->| N |--------------- |
#################| 4 |<----------------
-----
----- ################>| N|----------------- # ---------------| 1 | <、-、-、-、-、-、-、-、-、-、-、-、-、--、| # | ----- | | # | | | ----- ----- | N| | N| | 6 | | 2 | ----- ----- ^ | ^ | # | | | # | | | # | | | # | | | # | | | # v| v----- ----- | N| | N| | 5 | | 3 | ----- ----- # | | | # | ----- | | # -------------->| N|--------------- | #################| 4 | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- -----
The ring wrap is controlled through SONET BLSR [3][4] style IPS signaling. It is an objective to perform the wrapping as fast as in the SONET equipment or faster.
リング包装はSONET BLSR[3][4]スタイルIPSシグナリングを通して制御されます。 それは同じくらい速くSonet同じくらい設備か同じくらいより速くラッピングを実行する目的です。
The IPS protocol processes the following request types (in the order of priority, from highest to lowest):
IPSプロトコルは以下の要求タイプ(優先権の最も高いのから最も低くなるまでの注文における)を処理します:
1. Forced Switch (FS): operator originated, performs a protection
switch on a requested span (wraps at both ends of the span)
1. 無理矢理のスイッチ(FS): オペレータは、由来して、要求された長さに回線切替装置を実行します。(長さの両端の機密)
2. Signal Fail (SF): automatic, caused by a media Signal Failure
or SRP keep-alive failure - performs a protection switch on a
requested span
2. 信号は(SF)に失敗します: 自動であり、aによって引き起こされて、メディアSignal FailureかSRPが失敗を生かします--要求された長さに回線切替装置を実行します。
Tsiang & Suwala Informational [Page 10] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[10ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
FIGURE 5. Data path after the wrap, N4 -> N1
図5 包装、N4->N1の後のデータ経路
-----
################>| N |-----------------
# ###############| 1 |<############## |
# # ----- # |
# v # |
----- -----
| N | | N |
| 6 | | 2 |
----- -----
^ # wrap ^ |
### # |
_________ # |
fiber cut # |
--------- # |
### # |
# v wrap # v
----- -----
| N | | N |
| 5 | | 3 |
----- -----
# # # |
# # ----- # |
# ##############>| N |############### |
#################| 4 |<----------------
----- ################>| N|----------------- # ###############| 1 |<############## | # # ----- # | # #に対して| ----- ----- | N| | N| | 6 | | 2 | ----- ----- ^ #^を包装してください。| ### # | _________ # | ファイバーカット#| --------- # | ### # | # 包装#vに対して----- ----- | N| | N| | 5 | | 3 | ----- ----- # # # | # # ----- # | # ##############>| N|############### | #################| 4 | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--
3. Signal Degrade (SD): automatic, caused by a media Signal
Degrade (e.g. excessive Bit Error Rate) - performs a protection
switch on a requested span
3. 信号は(サウスダコタ)を下げます: オートマチック、メディアSignal Degrade(例えば、過度のBit Error Rate)によって引き起こされて、要求された長さに回線切替装置を実行します。
4. Manual Switch (MS): operator originated, like Forced Switched
but of a lower priority
4. 手動式スイッチ(MS): Forced Switchedにもかかわらず、低優先度などのように溯源されたオペレータ
5. Wait to Restore (WTR): automatic, entered after the working
channel meets the restoration criteria after SF or SD condition
disappears. IPS waits WTR period before restoring traffic in
order to prevent protection switch oscillations
5. (WTR)を回復するのを待ってください: 自動であり、働くチャンネルが会った後に入られて、SFかサウスダコタの後の評価基準が条件とさせる回復は見えなくなります。 IPSは回線切替装置振動を防ぐために交通を復元する前のWTRの期間に待ちます。
If a protection (either automatic or operator originated) is requested for a given span, the node on which the protection has been requested issues a protection request to the node on the other end of the span using both the short path (over the failed span, as the failure may be unidirectional) and the long path (around the ring).
保護(オートマチックかオペレータのどちらかが由来した)が当然のことの長さに要求されるなら、保護が要求されているノードは、長さのもう一方の端で短い経路(失敗としての失敗した長さの上、単方向があるかもしれない)と長い経路(リングの周りの)の両方を使用することで保護要求をノードに出します。
Tsiang & Suwala Informational [Page 11] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[11ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
FIGURE 6. Data path after the new topology is discovered
図6 新しいトポロジーの後のデータ経路は発見されます。
-----
-----------------| N |-----------------
| ---------------| 1 |<############## |
| | ----- # |
| v # |
----- -----
| N | | N |
| 6 | | 2 |
----- -----
^ | wrap ^ |
-- # |
_________ # |
fiber cut # |
--------- # |
-- # |
| v wrap # v
----- -----
| N | | N |
| 5 | | 3 |
----- -----
| | # |
| | ----- # |
| -------------->| N |############### |
-----------------| 4 |<----------------
-----
----- -----------------| N|----------------- | ---------------| 1 |<############## | | | ----- # | | #に対して| ----- ----- | N| | N| | 6 | | 2 | ----- ----- ^ | ^を包装してください。| -- # | _________ # | ファイバーカット#| --------- # | -- # | | 包装#vに対して----- ----- | N| | N| | 5 | | 3 | ----- ----- | | # | | | ----- # | | -------------->| N|############### | -----------------| 4 | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- -----
As the protection requests travel around the ring, the protection hierarchy is applied. If the requested protection switch is of the highest priority e.g. Signal Fail request is of higher priority than the Signal Degrade than this protection switch takes place and the lower priority switches elsewhere in the ring are taken down, as appropriate. If a lower priority request is requested, it is not allowed if a higher priority request is present in the ring. The only exception is multiple SF and FS switches, which can coexist in the ring.
保護要求がリングの周りを移動するとき、保護階層構造は適用されています。 要求された回線切替装置がこの回線切替装置が取るより高いSignal Degradeより優先度がある例えば、Signal Failが、要求する最優先のものであるなら、場所とリングのほかの場所の低優先度スイッチは降ろされます、適宜。 低優先度要求が要求されるなら、より高い優先権要求がリングに存在しているなら、それは許容されていません。 唯一の例外が、複数のSFとFSスイッチです。(そのスイッチはリングに共存できます)。
All protection switches are performed bidirectionally (wraps at both ends of a span for both transmit and receive directions, even if a failure is only unidirectional).
すべての回線切替装置が双方向に実行されます(両方のための長さの両端の機密は方向を送受信します、失敗が単方向にすぎなくても)。
Tsiang & Suwala Informational [Page 12] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[12ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
4. Packet Formats
4. パケット・フォーマット
This section describes the packet formats used by SRP. Packets can be sent over any point to point link layer (e.g. SONET/SDH, ATM, point to point ETHERNET connections). The maximum transfer unit (MTU) is 9216 octets. The minimum transfer unit for data packets is 55 octets. The maximum limit was designed to accommodate the large IP MTUs of IP over AAL5. SRP also supports ATM cells. ATM cells over SRP are 55 octets. The minimum limit corresponds to ATM cells transported over SRP. The minimum limit does not apply to control packets which may be smaller.
このセクションはSRPによって使用されたパケット・フォーマットについて説明します。 リンクレイヤを指すためにパケットを任意な点で移動できます(例えば、Sonet/SDH(ATM)はポイントイーサネット接続を示します)。 最大の移動単位数(MTU)は9216の八重奏です。 データ・パケットのための最小の移動単位数は55の八重奏です。 最大の限界は、AAL5の上にIPの大きいIP MTUsを収容するように設計されました。 また、SRPはATMにセルを支えます。 SRPの上のATMセルは55の八重奏です。 最小の限界はSRPの上で輸送されたATMセルに対応しています。 最小の限界は、より小さいかもしれないパケットを制御するのに申し込みません。
These limits include everything listed in Figure 7: but are exclusive of the frame delineation (e.g. for SRP over SONET/SDH, the flags used for frame delineation are not included in the size limits).
これらの限界は図7に記載されたすべてを含んでいます: しかし、フレーム輪郭描写(例えば、Sonet/SDHの上のSRPに関して、フレーム輪郭描写に使用される旗はサイズ限界に含まれていない)を除いて、あります。
The following packet and cell formats do not include any layer 1 frame delineation. For SRP over POS, there will be an additional flag that delineates start and end of frame.
以下のパケットとセル形式は少しの層の1個のフレームの輪郭描写も含んでいません。 POSの上のSRPのために、フレームの始めと端を図で表わす追加旗があるでしょう。
4.1. Overall Packet Format
4.1. 総合的なパケット・フォーマット
The overall packet format is show below in Figure 7:
総合的なパケット・フォーマットは図7で以下のショーです:
FIGURE 7. Overall Packet Format
図7 総合的なパケット・フォーマット
---------------------------------
| SRP Header |
---------------------------------
| Dest. Addr. |
---------------------------------
| Source Addr. |
---------------------------------
| Protocol Type |
---------------------------------
| Payload |
| |
| |
| |
---------------------------------
| FCS |
---------------------------------
--------------------------------- | SRPヘッダー| --------------------------------- | Dest。 Addr。 | --------------------------------- | ソースAddr。 | --------------------------------- | プロトコルタイプ| --------------------------------- | 有効搭載量| | | | | | | --------------------------------- | FCS| ---------------------------------
The frame check sequence (FCS) is a 32-bit cyclic redundancy check (CRC) as specified in RFC-1662 and is the same CRC as used in Packet Over SONET (POS - specified in RFC-2615). The generator polynomial is:
フレームチェックシーケンス(FCS)は、RFC-1662の指定されるとしての32ビットの周期冗長検査(CRC)であり、Packet Over Sonet(POS--RFC-2615では、指定される)に使用されるように同じCRCです。 ジェネレータ多項式は以下の通りです。
Tsiang & Suwala Informational [Page 13] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[13ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
CRC-32:
CRC-32:
x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1
The FCS is computed over the destination address, source address, protocol type and payload. It does not include the SRP header.
FCSは送付先アドレス、ソースアドレス、プロトコルタイプ、およびペイロードの上計算されます。 それはSRPヘッダーを含んでいません。
Note that the packet format after the SRP header is identical to Ethernet Version 2.
SRPヘッダーの後のパケット・フォーマットがイーサネットバージョン2と同じであることに注意してください。
4.2. Generic Packet Header Format
4.2. ジェネリックパケットヘッダー形式
Each packet has a fixed-sized header. The packet header format is shown in Figure 8.
各パケットには、修理サイズのヘッダーがあります。 パケットヘッダー形式は図8に示されます。
FIGURE 8. Detailed Packet Header Format
エイト環。 詳細なパケットヘッダー形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |R| MOD | PRI |P| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Payload |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生きる時間|R| モッズ| PRI|P| | +++++++++++++++++送付先アドレス| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ソースアドレス+++++++++++++++++| | プロトコルタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | 有効搭載量| . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are described below.
分野は以下で説明されます。
4.2.1. Time To Live (TTL)
4.2.1. 生きる時間(TTL)
This 8 bit field is a hop-count that must be decremented every time a node forwards a packet. If the TTL reaches zero it is stripped off the ring. This allows for a total node space of 256 nodes on a ring. However, due to certain failure conditions (e.g. when the ring is
この8ビットの分野はノードがパケットを進めるときはいつも、減少しなければならないホップカウントです。 TTLがゼロに達するなら、リングでそれを剥取ります。 これはリングの上の256のノードの総ノードスペースを考慮します。 しかしながら、ある失敗への支払われるべきものを条件とさせる、(例えば、リングはいつです。
Tsiang & Suwala Informational [Page 14] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[14ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
wrapped) the total number of nodes that are supported by SRP is 128. When a packet is first sent onto the ring the TTL should be set to at least twice the total number of nodes on the ring.
包装、)、SRPによってサポートされるノードの総数は128です。 最初にパケットをリングに送るとき、TTLは少なくともリングの上のノードの総数の2倍へのセットであるべきです。
4.2.2. Ring Identifier (R)
4.2.2. リング識別子(R)
This single bit field is used to identify which ring this packet is designated for. The designation is as follows:
このただ一つの噛み付いている分野は、このパケットがどのリングに関して指定されるかを特定するのに使用されます。 名称は以下の通りです:
TABLE 1. Ring Indicator Values
1を見送ってください。 リングインディケータ値
Outer Ring 0
Inner Ring 1
外側のリング0インナー・リング1
4.2.3. Priority Field (PRI)
4.2.3. 優先権分野(PRI)
This three bit field indicates the priority level of the SRP packet (0 through 7). The higher the value the higher the priority. Since there are only two queues in the transit buffer (HPTB and LPTB) a packet is treated as either low or high priority once it is on the ring. Each node determines the threshold value for determining what is considered a high priority packet and what is considered a low priority packet. However, the full 8 levels of priority in the SRP header can be used prior to transmission onto the ring (transmit queues) as well as after reception from the ring (receive queues).
この3ビットの分野はSRPパケット(0〜7)の優先順位を示します。 値が高ければ高いほど、優先度は、より高いです。 トランジットバッファ(HPTBとLPTB)における2つの待ち行列しかないので、リングの上にそれがいったんあると、パケットは低いか高い優先度として扱われます。 各ノードは、何が高い優先権パケットであると考えられるか、そして、何が低い優先権パケットであると考えられるかを決定するために閾値を決定します。 しかしながら、リング(待ち行列を伝える)とリングからのレセプションの後にトランスミッションの前にSRPヘッダーの完全な8つのレベルの優先権を使用できます(待ち行列を受けてください)。
4.2.4. MODE
4.2.4. モード
This three bit field is used to identify the mode of the packet. The following modes are defined in Table 2 below.
この3ビットの分野は、パケットのモードを特定するのに使用されます。 以下のモードは以下のTable2で定義されます。
TABLE 2. MODE Values
2を見送ってください。 最頻値
Value Description
値の記述
000 Reserved
001 Reserved
010 Reserved
011 ATM cell
100 Control Message (Pass to host)
101 Control Message (Locally Buffered for host)
110 Usage Message
111 Packet Data
000 予約された001Reserved010Reserved011ATMセル100Control Message(ホストに渡す)101Control Message(ホストのための局所的にBuffered)110Usage Message111Packet Data
These modes will be further explained in later sections.
これらのモードは後のセクションでさらに説明されるでしょう。
Tsiang & Suwala Informational [Page 15] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[15ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
4.2.5. Parity Bit (P-bit)
4.2.5. パリティビット(P-ビット)
The parity bit is used to indicate the parity value over the 15 bits of the SRP header to provide additional data integrity over the header. Odd parity is used (i.e. the number of ones including the parity bit shall be an odd number).
パリティビットは、追加データ保全をヘッダーの上に供給するためにパリティ価値をSRPヘッダーの15ビットの上示すのに使用されます。 奇数パリティは使用されています(すなわち、パリティビットを含むものの数は奇数になるでしょう)。
4.2.6. Destination Address
4.2.6. 送付先アドレス
The destination address is a globally unique 48 bit address assigned by the IEEE.
送付先アドレスはIEEEによって割り当てられたグローバルにユニークな48ビット・アドレスです。
4.2.7. Source Address
4.2.7. ソースアドレス
The source address is a globally unique 48 bit address assigned by the IEEE.
ソースアドレスはIEEEによって割り当てられたグローバルにユニークな48ビット・アドレスです。
4.2.8. Protocol Type
4.2.8. プロトコルタイプ
The protocol type is a two octet field like that used in EtherType representation. Current defined values relevant to SRP are defined in Table 3 below.
プロトコルタイプはEtherType表現に使用されるそのように2八重奏分野です。 SRPに関連している現在の定義された値は以下のTable3で定義されます。
TABLE 3. Defined Protocol Types
3を見送ってください。 定義されたプロトコルタイプ
Value Protocol Type
値のプロトコルタイプ
0x2007 SRP Control
0x0800 IP version 4
0x0806 ARP
0×2007 SRP Control0x0800IPバージョン4 0×0806ARP
4.3. SRP Cell Format
4.3. SRPセル形式
SRP also supports the sending of ATM cells. The detailed cell format is shown below:
また、SRPはATMセルの発信をサポートします。 詳細なセル書式は以下に示されます:
Tsiang & Suwala Informational [Page 16] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[16ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
FIGURE 9. SRP Cell Format
図9 SRPセル形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |R| MOD | PRI |P| VPI/VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCI | PTI |C| HEC | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. ATM Payload .
. ( 48 Bytes ) +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生きる時間|R| モッズ| PRI|P| VPI/VCI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VCI| PTI|C| HEC| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . 気圧有効搭載量(48バイト)+++++++++| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet nodes would typically ignore (never receive or strip) and always forward ATM-cells. The idea is that ATM switches and routers could coexist in a ring. Note that SRP cells do not contain an FCS. Data integrity is handled at the AAL layer.
または、パケットノードが通常無視するだろう、(決して受信しないでください、片) そして、いつも前進のATM-セル。 考えはATMスイッチとルータがリングに共存できたということです。 SRPセルがFCSを含まないことに注意してください。 データの保全はAAL層で扱われます。
4.4. SRP Usage Packet Format
4.4. SRP用法パケット・フォーマット
SRP usage packets are sent out periodically to propagate allowed usage information to upstream nodes. SRP usage packets also perform a keepalive function. SRP usage packets should be sent approximately every 106 usec.
許容用法情報を上流のノードに伝播するために定期的にSRP用法パケットを出します。 また、SRP用法パケットはkeepalive機能を実行します。 およそあらゆる106usecをSRP用法パケットに送るべきです。
If a receive interface has not seen a usage packet within the keepalive timeout interval it will trigger an L2 keepalive timeout interrupt/event. The IPS software will subsequently mark that interface as faulty and initiate a protection switch around that interface. The keepalive timeout interval should be set to 16 times the SRP usage packet transmission interval.
aが受信されるなら、インタフェースはそれがL2 keepaliveタイムアウト中断/イベントの引き金となるkeepaliveタイムアウト間隔中に用法パケットを見ていません。 IPSソフトウェアは、次に、不完全であるとしてそのインタフェースを示して、そのインタフェースの周りで回線切替装置を開始するでしょう。 keepaliveタイムアウト間隔はSRP用法パケット伝送間隔の16回に設定されるべきです。
FIGURE 10. Usage Packet Format
図10 用法パケット・フォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |R| MOD | PRI |P| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originator MAC Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Usage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生きる時間|R| モッズ| PRI|P| | +++++++++++++++++創始者マックーアドレス+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| 用法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A USAGE of all ones indicates a value of NULL.
すべてのもののUSAGEはNULLの値を示します。
Tsiang & Suwala Informational [Page 17] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[17ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
4.5. SRP Control Packet Format
4.5. SRPコントロールパケット・フォーマット
If the MODE bits are set to 10X (SRP control) then this indicates a control message. Control messages are always received and stripped by the adjacent node. They are by definition unicast, and do not need any addressing information. The destination address field for control packets should be set to 0's. The source address field for a control packet should be set to the source address of the transmitting node.
MODEビットが10X(SRPコントロール)に設定されるなら、これはコントロールメッセージを示します。 隣接しているノードはコントロールメッセージをいつも受け取って、剥取ります。 彼らは、定義上ユニキャストであり、少しのアドレス指定情報も必要としません。 コントロールパケットのための目的地アドレス・フィールドは0に設定されるべきです。 コントロールパケットのためのソースアドレス分野は伝えるノードのソースアドレスに設定されるべきです。
Two types of controls messages are defined : Pass to host and Locally buffered. Pass to host messages can be passed to the host software by whatever means is convenient. This is most often the same path used to transfer data packets to the host. Locally buffered control messages are usually reserved for protection messages. These are normally buffered locally in order to not contend for resources with data packets. The actual method of handling these messages is up to the implementor.
2つのタイプに関するコントロールメッセージは定義されます: ホストとバッファリングされたLocallyに通ってください。 いかなる便利な手段でもホストメッセージへのパスをホストソフトウェアに渡すことができます。 これはデータ・パケットをホストに移すのに使用されるたいてい同じ経路です。 通常、局所的にバッファリングされたコントロールメッセージは保護メッセージのために予約されます。 通常、これらは、データ・パケットでリソースを競争しないように局所的にバッファリングされます。 これらのメッセージを扱う実際のメソッドは作成者次第です。
The control packet format is shown in Figure 11.
コントロールパケット・フォーマットは図11に示されます。
FIGURE 11. Control Packet Format
図11 コントロールパケット・フォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |R| MOD | PRI |P| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Protocol Type = 0x2007 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Ver | Control Type | Control Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control TTL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Payload .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生きる時間|R| モッズ| PRI|P| | +++++++++++++++++送付先アドレス| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ソースアドレス+++++++++++++++++| | プロトコルタイプ=0x2007| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールVer| コントロールタイプ| コントロールチェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールTTL| | …++++++++++++++++++有効搭載量… +++++++++++++++++++++++++++++++++
The priority (PRI) value should be set to 0x7 (all one's) when sending control packets and should be queued to the highest priority transmit queue available. The Time to Live is not relevant since all
コントロールパケットを送るとき、0×7(人のすべてのもの)に設定されるべきであり、列に並ばせられるべきである(PRI)が最優先に評価する優先権は利用可能な待ち行列を伝えます。 すべて以来LiveへのTimeは関連していません。
Tsiang & Suwala Informational [Page 18] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[18ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
packets will be received and stripped by the nearest downstream neighbor and can be set to any value (preferably this should be set to 001).
パケットを受け取って、最も近い川下の隣人によって剥取られて、どんな値にも設定できます(望ましくは、これは001に設定されるべきです)。
4.5.1. Control Ver
4.5.1. コントロールVer
This one octet field is the version number associated with the control type field. Initially, all control types will be version 0.
この1つの八重奏分野がコントロールタイプ分野に関連しているバージョン番号です。 初めは、すべてのコントロールタイプがバージョンにな0るでしょう。
4.5.2. Control Type
4.5.2. コントロールタイプ
This one octet field represents the control message type. Table 4 contains the currently defined control types.
この1つの八重奏分野がコントロールメッセージタイプの代理をします。 テーブル4は現在定義されたコントロールタイプを含んでいます。
TABLE 4. Control Types
4を見送ってください。 コントロールはタイプされます。
Control Type Description
コントロール型記述
0x01 Topology Discovery
0×01 トポロジー発見
0x02 IPS message
0×02IPSメッセージ
0x03-
0xFF Reserved
0xFFが予約した0×03
4.5.3. Control TTL
4.5.3. コントロールTTL
The Control TTL is a control layer hop-count that must be decremented every time a node forwards a control packet. If a node receives a control packet with a control TTL <= 1, then it should accept the packet but not forward it.
Control TTLはノードがコントロールパケットを進めるときはいつも、減少しなければならないコントロール層のホップカウントです。 ノードがコントロールTTL<=1でコントロールパケットを受けるなら、それは、パケットを受け入れますが、それを進めるべきではありません。
Note that the control layer hop count is separate from the SRP L2 TTL which is always set to 1 for control messages.
コントロール層のホップカウントがコントロールメッセージのためにいつも1に用意ができているSRP L2 TTLから別々であることに注意してください。
The originator of the control message should set the initial value of the control TTL to the SRP L2 TTL normally used for data packets.
コントロールメッセージの創始者は通常、データ・パケットに使用されるSRP L2 TTLにコントロールTTLの初期の値を設定するべきです。
4.5.4. Control Checksum
4.5.4. コントロールチェックサム
The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words starting with the control version. If there are an odd number of octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros. This is the same checksum algorithm as that used for TCP. The checksum does not cover the 32 bit SRP FCS.
チェックサム分野はコントロールバージョンから始まるすべての16ビットの単語の1の補数合計の16ビットの1の補数です。 checksummedされるように八重奏の奇数にあれば、最後の八重奏は右でゼロで水増しされて、チェックサム目的に対する16ビットの単語を形成します。 パッドはセグメントの一部として送られません。 チェックサムを計算している間、チェックサム野原自体をゼロに取り替えます。 これはTCPに使用されるそれと同じチェックサムアルゴリズムです。 チェックサムは32噛み付いているSRP FCSをカバーしていません。
Tsiang & Suwala Informational [Page 19] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[19ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
4.5.5. Payload
4.5.5. 有効搭載量
The payload is a variable length field dependent on the control type.
ペイロードはコントロールタイプの上の可変長分野扶養家族です。
4.5.6. Addressing
4.5.6. アドレシング
All nodes must have a globally unique IEEE 48 bit MAC address. A multicast bit is defined using canonical addressing conventions i.e. the multicast bit is the least significant bit of the most significant octet in the destination address. It is acceptable but not advisable to change a node's MAC address to one that is known to be unique within the administrative layer 2 domain (that is the SRP ring itself along with any networks connected to the SRP ring via a layer 2 transparent bridge).
すべてのノードには、グローバルにユニークなIEEE48の噛み付いているMACアドレスがなければなりません。 マルチキャストビットは正準なアドレシングコンベンションを使用することで定義されます、すなわち、マルチキャストビットが送付先アドレスで最も重要な八重奏の最下位ビットです。 許容できますが、ノードのMACアドレスを管理層2のドメインの中で特有であることが知られているものに変えるのは、賢明ではありません(すなわち、どんなネットワークに伴うSRPリング自体も層で2の透明なブリッジをSRPリングに接続しました)。
FIGURE 12. Multicast bit position
図12 マルチキャストビット位置
Destination Address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |M| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
|----Multicast bit
送付先アドレス0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+++++++++++++++++++++++++++++++++| |M| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |----マルチキャストビット
Note that for SONET media, the network order is MSB of each octet first, so that as viewed on the line, the multicast bit will be the 8th bit of the destination address sent. (For SRP on Ethernet media, the multicast bit would be sent first).
Sonetメディアにおいて、ネットワークオーダーが最初にそれぞれの八重奏のMSBであることに注意してください、マルチキャストビットが系列で見られるようにアドレスが送った目的地の8番目のビットになるように。 (イーサネットメディアのSRPに関して、最初に、マルチキャストビットを送るでしょう。)
4.6. Topology Discovery
4.6. トポロジー発見
Each node performs topology discovery by sending out topology discovery packets on one or both rings. The node originating a topology packet marks the packet with the egressing ring id, appends the node's mac binding to the packet and sets the length field in the packet before sending out the packet. This packet is a point-to-point packet which hops around the ring from node to node. Each node appends its mac address binding, updates the length field and sends it to the next hop on the ring. If there is a wrap on the ring, the wrapped node will indicate a wrap when appending its mac binding and wrap the packet. When the topology packets travel on the wrapped section with the ring identifier being different from that of the topology packet itself, the mac address bindings are not added to the packet.
各ノードは、1かリングの両方にトポロジー発見パケットを出すことによって、トポロジー発見を実行します。 トポロジーパケットを溯源するノードは、egressingリングイドをパケットに付けて、ノードのmac結合をパケットに追加して、パケットを出す前に、長さの分野をパケットにはめ込みます。 このパケットはリングの周りをノードからノードまで跳ぶ二地点間パケットです。 各ノードは、リングの上の次のホップにmacアドレス結合を追加して、長さの分野をアップデートして、それを送ります。 リングの上に包装があると、包装されたノードは、mac結合を追加するとき、包装を示して、荷を包装するでしょう。 リング識別子がトポロジーパケット自体のものと異なっていた状態でトポロジーパケットが包装されたセクションを移動するとき、macアドレス結合はパケットに加えられません。
Tsiang & Suwala Informational [Page 20] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[20ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
Eventually the node that generated the topology discovery packet gets back the packet. The node makes sure that the packet has the same ingress and egress ring id before excepting the packet. A topology map is changed only after receiving two topology packets which indicate the same new topology (to prevent topology changes on transient conditions).
結局、トポロジー発見パケットを生成したノードはパケットを取り戻します。 ノードは、パケットを除く前に、パケットには同じイングレスと出口リングイドがあるのを確実にします。 同じ新しいトポロジー(一時的な条件でトポロジー変化を防ぐ)を示す2つのトポロジーパケットを受けた後にだけ、トポロジー地図を変えます。
Note that the topology map only contains the reachable nodes. It does not correspond to the failure-free ring in case of wraps and ring segmentations.
トポロジー地図が届いているノードを含むだけであることに注意してください。 それは機密とリング分割の場合に無失敗のリングに対応していません。
FIGURE 13. Topology Packet Format
図13 トポロジーパケット・フォーマット
Topology
トポロジー
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |R| MOD | PRI |P| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Protocol Type = 0x2007 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Ver=0 | Control Type=1| Control Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control TTL | Topology Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator's Globally Unique |
+ MAC Address (48 bits) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | MAC Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MAC Address (48 bits) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Other MAC bindings |
+-+-+-+-+-+-+-+-+ +
| |
+ +
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生きる時間|R| モッズ| PRI|P| | +++++++++++++++++送付先アドレス| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ソースアドレス+++++++++++++++++| | プロトコルタイプ=0x2007| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールVer=0| コントロールタイプ=1| コントロールチェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールTTL| トポロジーの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 創始者はグローバルにユニークです。| + マックーアドレス(48ビット)+++++++++++++++++| | MACはタイプします。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | マックーアドレス(48ビット)| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 他のMAC結合| +-+-+-+-+-+-+-+-+ + | | + +
Note that the Source address should be set to the source address of the TRANSMITTING node (which is not necessarily the ORIGINATING node).
SourceアドレスがTRANSMITTINGノード(必ずORIGINATINGノードであるというわけではない)のソースアドレスに設定されるべきであることに注意してください。
Tsiang & Suwala Informational [Page 21] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[21ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
4.6.1. Topology Length
4.6.1. トポロジーの長さ
This two octet field represents the length of the topology message in octets starting with the first MAC Type/MAC Address binding.
この2八重奏分野は付く最初のMAC Type/マックーアドレスから始まる八重奏における、トポロジーメッセージの長さを表します。
4.6.2. Topology Originator
4.6.2. トポロジー創始者
A topology discovery packet is determined to have been originated by a node if the originator's globally unique MAC address of the packet is that node's globally unique MAC address (assigned by the IEEE).
トポロジー発見パケットは創始者のパケットのグローバルにユニークなMACアドレスがそのノードのグローバルにユニークなMACアドレス(IEEEによって割り当てられる)であるならノードによって溯源されたと決心しています。
Because the mac addresses could be changed at a node, the IEEE MAC address ensures that a unique identifier is used to determine that the topology packet has gone around the ring and is to be consumed.
ノードでmacアドレスを変えることができたので、IEEE MACアドレスは、ユニークな識別子がトポロジーパケットがリングを回ったことを決定するのに使用されて、消費されることであることを確実にします。
4.6.3. MAC bindings
4.6.3. MAC結合
Each MAC binding shall consist of a MAC Type field followed by the node's 48 bit MAC address. The first MAC binding shall be the MAC binding of the originator. Usually the originator's MAC address will be it's globally unique MAC Address but some implementations may allow this value to be overridden by the network administrator.
それぞれのMAC結合はノードの48ビットのMACアドレスがあとに続いたMAC Type分野から成るものとします。 最初のMAC結合は創始者のMAC結合になるでしょう。 通常、創始者のMACアドレスはそれがグローバルにユニークなマックーアドレスであるのにもかかわらずの、いくつかの実装が、この値がネットワーク管理者によってくつがえされるのを許容するかもしれないということでしょう。
4.6.4. MAC Type Format
4.6.4. MACは書式をタイプします。
This 8 bit field is encoded as follows:
この8ビットの分野は以下の通りコード化されます:
TABLE 5. MAC Type Format
5を見送ってください。 MACは書式をタイプします。
Bit Value
噛み付いている値
0 Reserved
1 Ring ID (1 or 0)
2 Wrapped Node (1) / Unwrapped Node (0)
3-7 Reserved
0 予約された1個のリングのID(1か0)2は3-7が予約したノード(1)/開けられたノード(0)を包装しました。
Determination of whether a packet's egress and ingress ring ID's are a match should be done by using the Ring ID found in the MAC Type field of the last MAC binding as the ingress ring ID rather than the R bit found in the SRP header. Although they should be the same, it is better to separate the two functions as some implementations may not provide the SRP header to upper layer protocols.
パケットの出口とイングレスがIDのものを鳴らすかどうかに関する決断はRビットよりむしろIDがSRPヘッダーで見つけたイングレスリングとして付く最後のMACのMAC Type野原で発見されるRing IDを使用することによってマッチをするべきであるということです。 それらは同じであるべきですが、いくつかの実装が上側の層のプロトコルにSRPヘッダーを提供しないかもしれないのに従って、2つの機能を切り離すほうがよいです。
The topology information is not required for the IPS protection mechanism. This information can be used to calculate the number of nodes in the ring as well as to calculate hop distances to nodes to determine the shortest path to a node (since there are two counter- rotating rings).
トポロジー情報はIPS保護メカニズムに必要ではありません。 リングでのノードの数について計算して、最短パスをノードに決定するためにホップ距離についてノードに計算するのにこの情報を使用できます(2個のカウンタ回転リングがあるので)。
Tsiang & Suwala Informational [Page 22] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[22ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
The implementation of the topology discovery mechanism could be a periodic activity or on "a need to discover" basis. In the periodic implementation, each node generates the topology packet periodically and uses the cached topology map until it gets a new one. In the need to discover implementation, each node generates a topology discovery packet whenever they need one e.g., on first entering a ring or detecting a wrap.
トポロジー発見メカニズムの実現が周期的な活動か「発見する必要性」ベースにあるかもしれません。 周期的な実現では、新しいものを得るまで、各ノードは、トポロジーパケットを定期的に発生させて、キャッシュされたトポロジー地図を使用します。 実現を発見する必要性では、彼らがリングを入れるか、または包装を検出しながら最初に例えば、1を必要とするときはいつも、各ノードはトポロジー発見パケットを発生させます。
4.7. Intelligent Protection Switching (IPS)
4.7. 知的な保護の切り換え(IPS)
IPS is a method for automatically recovering from various ring failures and line degradation scenarios. The IPS packet format is outlined in Figure 14 below.
IPSは、様々なリングの故障と線退行シナリオから自動的に回復するための方法です。 IPSパケット・フォーマットは以下の図14に概説されています。
FIGURE 14. IPS Packet Format
図14 IPSパケット・フォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |R| MOD | PRI |P| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Protocol Type = 0x2007 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Ver=0 | Control Type=2| Control Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control TTL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Originator MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ips Octet | Rsvd Octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生きる時間|R| モッズ| PRI|P| | +++++++++++++++++送付先アドレス| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ソースアドレス+++++++++++++++++| | プロトコルタイプ=0x2007| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールVer=0| コントロールタイプ=2| コントロールチェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールTTL| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 創始者マックーアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ips八重奏| Rsvd八重奏| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPS specific fields are detailed below.
IPSの特定の分野は以下で詳細です。
4.7.1. Originator MAC Address
4.7.1. 創始者マックーアドレス
This is the MAC address of the originator of the IPS message. It is not necessarily the same as the SRP Header Source Address as a node may be simply propagating an IPS message (see the section "SRP IPS Protocol Rules" Rule P.8 as an example).
これはIPSメッセージの創始者のMACアドレスです。 それは必ずノードとしてのSRP Header Source Addressが単にIPSメッセージを伝播しているかもしれないのと(「SRP IPSプロトコル規則」というセクションRule P.8を例と考えてください)同じであるというわけではありません。
Tsiang & Suwala Informational [Page 23] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[23ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
4.7.2. IPS Octet
4.7.2. IPS八重奏
The IPS octet contains specific protection information. The format of the IPS octet is as follows:
IPS八重奏は特異的予防情報を含んでいます。 IPS八重奏の形式は以下の通りです:
FIGURE 15. IPS Octet Format:
図15 IPS八重奏形式:
Bits Values (values not listed are reserved)
ビット値(記載されなかった値は予約されています)
0-3 IPS Request Type
0-3 IPSはタイプを要求します。
1101 - Forced Switch (FS)
1011 - Signal Fail (SF)
1000 - Signal Degrade (SD)
0110 - Manual Switch (MS)
0101 - Wait to Restore (WTR)
0000 - No Request (IDLE)
1101--信号が(SF)1000に失敗するという1011が示す無理矢理のスイッチ(FS)は(サウスダコタ)0110--手動式スイッチ(MS)0101--(WTR)0000を回復するのを待っています--要求を全く下がらせません。(活動していません)です。
4 Path indicator
4経路インディケータ
0 - short (S)
1 - long (L)
0(短い(S)1)は切望されます。(L)
5-7 Status Code
5-7 ステータスコード
010 - Protection Switch Completed - traffic Wrapped (W)
000 - Idle (I)
010--保護Switch Completed(交通Wrapped(W)000)は怠けます。(I)
The currently defined request types with values, hierarchy and interpretation are as used in SONET BLSR [3], [4], except as noted.
値、階層構造、および解釈がある現在定義された要求タイプはSONET BLSR[3]で使用されています、[4]、注意されるのを除いて。
4.8. Circulating packet detection (stripping)
4.8. パケット検出を循環させます。(ストリップ)
Packets continue to circulate when transmitted packets fail to get stripped. Unicast packets are normally stripped by the destination station or by the source station if the destination station has failed. Multicast packets are only stripped by the source station. If both the source and destination stations drop out of the ring while a unicast packet is in flight, or if the source node drops out while its multicast packet is in flight, the packet will rotate around the ring continuously.
伝えられたパケットが剥取られないとき、パケットは、循環し続けています。 目的地ステーションが行き詰まったなら、通常、目的地ステーションか発信局はユニキャストパケットを剥取ります。 発信局はマルチキャストパケットを剥取るだけです。 ユニキャストパケットが飛行である間、ソースと目的地ステーションの両方がリングを脱落するか、マルチキャストパケットが飛行でありますが、またはソースノードが落ちると、パケットはリングの周りで絶え間なく回転するでしょう。
The solution to this problem is to have a TTL or Time To Live field in each packet that is set to at least twice the number of nodes in the ring. As each node forwards the packet, it decrements the TTL. If the TTL reaches zero it is stripped off of the ring.
この問題の解決はリングに少なくともノードの数の2倍に設定される各パケットのTTLかTime To Live分野を持つことです。 各ノードがパケットを進めるのに従って、それはTTLを減少させます。 TTLがゼロに達するなら、リングからそれを剥取ります。
Tsiang & Suwala Informational [Page 24] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[24ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
The ring ID is used to qualify all stripping and receive decisions. This is necessary to handle the case where packets are being wrapped by some node in the ring. The sending node may see its packet on the reverse ring prior to reaching its destination so must not source strip it. The exception is if a node is in wrap. Logically, a node in wrap "sees" the packet on both rings. However the usual implementation is to receive the packet on one ring and to transmit it on the other ring. Therefore, a node that is in the wrap state ignores the ring ID when making stripping and receiving decisions.
リングIDは、すべてのストリップに資格を与えて、決定を受けるのに使用されます。 これが、荷がリングでの何らかのノードによって包装されているケースを扱うのに必要です。 送付ノードが目的地に到着する前に逆のリングの上のパケットを見るかもしれないので、ソースはそれを剥取ってはいけませんか? 例外はノードが包装であるということです。 論理的に、包装の中のノードは両方のリングの上のパケットを「見ます」。 しかしながら、普通の実現は、1個のリングの上にパケットを受けて、もう片方のリングの上にそれを伝えることです。 したがって、ストリップを作るとき、包装の中では、州がリングIDを無視するということであるノードと決定を受けること。
A potential optimization would be to allow ring ID independent destination stripping of unicast packets. One problem with this is that packets may be delivered out of order during a transition to a wrap condition. For this reason, the ring ID should always be used as a qualifier for all strip and receive decisions.
潜在的最適化はユニキャストパケットのリングID独立者目的地ストリップを許すだろうことです。 これに関する1つの問題は包装状態への変遷の間故障していた状態でパケットを届けるかもしれないということです。 この理由で、リングIDは、すべての片に資格を与える人としていつも使用されて、決定を受けるべきです。
5. Packet acceptance and stripping
5. パケット承認とストリップ
A series of decisions based on the type of packet (mode), source and destination addresses are made on the MAC incoming packets. Packets can either be control or data packets. Control packets are stripped once the information is extracted. The source and destination addresses are checked in the case of data packets. The rules for reception and stripping are given below as well as in the flow chart in Figure 16.
パケット(モード)のタイプに基づく一連の決定、ソース、および送付先アドレスはMACの入って来るパケットの上で作られています。 パケットは、コントロールかデータ・パケットのどちらかであるかもしれません。 情報がいったん抜粋されると、コントロールパケットは剥取られます。 ソースと送付先アドレスはデータ・パケットのケースでチェックされます。 フローチャートと図16のフローチャートでレセプションとストリップのための規則を与えます。
1. Decrement TTL on receipt of a packet, discard if it gets to
zero; do not forward.
1. パケットを受け取り次第TTLを減少させてください、そして、ゼロを始めるなら、捨ててください。 前方にそうしないでください。
2. Strip unicast packets at the destination station. Accept and
strip "control" packets.
2. 目的地ステーションでユニキャストパケットを剥取ってください。 「コントロール」パケットを受け入れて、剥取ってください。
3. Do not process packets other than for TTL and forwarding if
they have the "wrong" ring_id for the direction in which they
are received unless the node is in wrap. If the node is in
wrap then ignore the ring_id.
3. それらにノードが包装でない場合それらが受け取られている方向のための「間違った」リング_イドがあるなら、TTLと推進以外のパケットを処理しないでください。 ノードが包装であるなら、リング_イドを無視してください。
4. Do not process packets other than for TTL and forwarding if the
mode is not supported by the node (e.g. reserved modes, or ATM
cell mode for packet nodes).
4. ノード(例えば、パケットノードのためにモード、またはATMセルモードを予約する)によってモードが支持されないなら、TTLと推進以外のパケットを処理しないでください。
5. Packets accepted by the host because of the destination address
should be discarded at the upper level if there is CRC error.
5. CRC誤りがあれば、送付先アドレスのためにホストによって受け入れられたパケットは上側のレベルで捨てられるべきです。
6. Control messages are point to point between neighbors and
should always be accepted and stripped.
6. いつもコントロールメッセージを隣人の間のポイント・ツー・ポイントであり、受け入れて、剥取るべきです。
Tsiang & Suwala Informational [Page 25] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[25ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
7. Packets whose source address is that of the receiving station
and whose ring_id matches should be stripped. If a node is in
wrap then ignore the ring_id.
7. ソースアドレスが受入れステーションのものであり、リング_イドが合っているパケットを剥取るべきです。 ノードが包装であるなら、リング_イドを無視してください。
FIGURE 16. SRP Receive Flowchart (Packet node)
図16 SRPはフローチャートを受けます。(パケットノード)
if (MODE == 4,5)-------------------------------->[to host]--->|
| |
v |
if (MODE == 6)---------------------------------->[strip]----->|
| |
v |
if (!WRAPPED |
& WRONG_RING_ID)-------------------------------------------|--->|
| | |
v | |
if (MODE == 0,1,2,3)------------------------------------------|--->|
| | |
v | |
if (DA MATCH)--------------->if !(SA MATCH)----->[to host]--->| |
| | | |
| v | |
| if (unicast)------->[to host]--->| |
| | | |
| v | |
if (SA MATCH)-------------------->[strip]-------------------->| |
| | |
| | v
|--------------------------->|<-----------------------|----|
| |
v |
if (ttl < 2)------->[strip]----->|
| |
v |
[decrement ttl] |
| |
[fwd pkt to tb] |
| v
|<-----------------------|
v
[back to top]
(4、モード=5)です。-------------------------------->[接待する]--->|、|、| v| (モード=6)です。---------------------------------->[片]----->|、|、| v| (包装、| 間違った_RING_ID)-------------------------------------------|、-、--、>|、|、|、| v| | (0、1、2、モード=3)です。------------------------------------------|、-、--、>|、|、|、| v| | (DAマッチ)です。--------------->、(SAマッチ)です。----->[接待する]--->|、|、|、|、|、|、| v| | | (ユニキャスト)です。------->[接待する]--->|、|、|、|、|、|、| v| | (SAマッチ)です。-------------------->[片]-------------------->|、|、|、|、|、|、| v|--------------------------->|<-----------------------|----| | | v| (ttl<2)です。------->[片]----->|、|、| v| [減少ttl]| | | [Tbへのfwd pkt]| | v| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| v[最初に戻る]
Notes: Host is responsible for discarding CRC errored packets.
Conditionals (if statements) branch to the right if true
and branch down if false.
注意: ホストはCRC erroredパケットを捨てるのに責任があります。 Conditionals(声明であるなら)は本当であるなら右に分岐して、誤っているなら、分岐します。
Tsiang & Suwala Informational [Page 26] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[26ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
5.1. Transmission and forwarding with priority
5.1. 優先権があるトランスミッションと推進
A node can transmit four types of packets:
ノードは4つのタイプのパケットを伝えることができます:
1. High priority packets from the high priority transit
buffer.
1. 高い優先権トランジットバッファからの高い優先権パケット。
2. Low priority packets from the low priority transit buffer.
2. 少ない優先権トランジットバッファからの低い優先権パケット。
3. High priority packets from the host Tx high priority fifo.
3. ホスト高Tx優先度fifoからの高い優先権パケット。
4. Low priority packets from the host Tx low priority fifo.
4. ホストTxの低い優先度fifoからの低い優先権パケット。
High priority packets from the transit buffer are always sent first. High priority packets from the host are sent as long as the low priority transit buffer is not full. Low priority packets are sent as long as the transit buffer has not crossed the low priority threshold and the SRP-fa rules allow it (my_usage < allowed_usage). If nothing else can be sent, low priority packets from the low priority transit buffer are sent.
最初に、いつもトランジットバッファからの高い優先権パケットを送ります。 少ない優先権トランジットバッファが完全でない限り、ホストからの高い優先権パケットを送ります。 トランジットバッファが低優先権敷居に交差しなかった限り、低い優先権パケットを送ります、そして、SRP-ファ規則はそれを許容します(私の_用法<は_用法を許容しました)。 他に何もを送ることができるなら、少ない優先権トランジットバッファからの低い優先権パケットを送ります。
This decision tree is shown in Figure 17.
この意思決定の樹状図は図17で見せられます。
Tsiang & Suwala Informational [Page 27] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[27ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
FIGURE 17. SRP transmit flowchart
図17 SRPはフローチャートを伝えます。
if (TB_High has pkt)----------->[send pkt from TB_high]-->|
| |
v |
if (TB_Low full)------------------------------------------|---->|
| | |
v | |
if (Tx_High has pkt)----------->[send pkt from Tx_high]-->| |
| | |
v | |
if (TB_Low > Hi threshold)--------------------------------|---->|
| | |
v | |
if (my_usage >= allowed_usage)----------------------------|---->|
| | |
v | |
if (Tx_Low has pkt)------------>[send pkt from Tx_low]--->| |
| | |
| | v
|<------------------------------------------------|-----|
| |
v |
if (TB_Low has pkt)------------>[send pkt from TB_low]--->|
| v
|<------------------------------------------------|
|
v
[Go to Top]
(TB_Highには、pktがあります)----------->[TBからpktを_高く送る]-->|、|、| v| (TB_Low満)です。------------------------------------------|、-、-、--、>|、|、|、| v| | (Tx_Highには、pktがあります)----------->[Txからpktを_高く送る]-->|、|、|、|、| v| | (TB_Low>Hi敷居)です。--------------------------------|、-、-、--、>|、|、|、| v| | (_用法が許容された私の_用法>=)です。----------------------------|、-、-、--、>|、|、|、| v| | (Tx_Lowには、pktがあります)------------>[Txからpktを_低く送ります]--->|、|、|、|、|、|、| v|<------------------------------------------------|-----| | | v| (TB_Lowには、pktがあります)------------>[TBからpktを_低く送ります]--->|、| v|<------------------------------------------------| | v[先端に行きます]
Notes: Conditionals (if statements) branch to the right if true
and branch down if false.
注意: Conditionals(声明であるなら)は本当であるなら右に分岐して、誤っているなら、分岐します。
5.2. Wrapping of Data
5.2. データのラッピング
Normally, transmitted data is sent on the same ring to the downstream neighbor. However, if a node is in the wrapped state, transmitted data is sent on the opposite ring to the upstream neighbor.
通常、川下の隣人への同じリングに伝えられたデータを送ります。 しかしながら、ノードが包装された状態にあるなら、上流の隣人への反対のリングに伝えられたデータを送ります。
6. SRP-fa Rules Of Operation
6. 操作のSRP-ファ規則
The SRP-fa governs access to the ring. The SRP-fa only applies to low priority traffic. High priority traffic does not follow SRP-fa rules and may be transmitted at any time as long as there is sufficient transit buffer space.
SRP-ファはリングへのアクセスを治めます。 SRP-ファは低い優先権交通に適用されるだけです。 高い優先権交通は、SRP-ファ規則に従わないで、十分なトランジットバッファ領域がある限り、いつでも、伝えられるかもしれません。
Tsiang & Suwala Informational [Page 28] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[28ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
The SRP-fa requires three counters which control the traffic forwarded and sourced on the SRP ring. The counters are my_usage (tracks the amount of traffic sourced on the ring), forward_rate (amount of traffic forwarded on to the ring from sources other than the host) and allowed_usage (the current maximum transmit usage for that node).
SRP-ファは交通整理するSRPリングの上に進められて、出典を明示された3台のカウンタを必要とします。 カウンタは、私の_用法(リングの上に出典を明示された交通の量の道)と、前進の_レート(ホスト以外のソースからリングに送られた交通の量)と許容_用法(現在の最大はそのノードのために用法を伝える)です。
With no congestion all nodes build up allowed usage periodically. Each node can send up to max_usage. Max_usage is a per node parameter than limits the maximum amount of low priority traffic a node can send.
混雑がなければ、すべてのノードが許容用法を定期的に確立します。 各ノードは最大_用法まで発信できます。 マックス_用法はノードが送ることができる低い優先権交通の最大の量を制限するよりノードパラメタあたりaです。
When a node sees congestion it starts to advertise its my_usage which has been low pass filtered (lp_my_usage).
ノードがそれが広告を出し始める混雑を見るとき、それはフィルターにかけられた(_私の_用法をlpします)低いパスである私の_用法です。
Congestion is measured by the transit buffer depth crossing a congestion threshold.
混雑は混雑敷居に交差するトランジットバッファの深さによって測定されます。
A node that receives a non-null usage message (rcvd_usage) will set its allowed usage to the value advertised. However, if the source of the rcvd_usage is the same node that received it then the rcvd_usage shall be treated as a null value. When comparing the rcvd_usage source address the ring ID of the usage packet must match the receiver's ring ID in order to qualify as a valid compare. The exception is if the receive node is in the wrap state in which case the usage packet's ring ID is ignored.
非ヌル用法メッセージ(rcvd_用法)を受け取るノードは広告に掲載された値に許容用法を設定するでしょう。 しかしながら、rcvd_用法の源がそれを受けたのと同じノードであるなら、rcvd_用法はヌル値として扱われるものとします。 rcvd_用法ソースアドレスを突き合わせた用法パケット必須マッチ受信機のリングIDのリングIDであるときには、aの有効な状態で資格を得るために比較してください。 受信してください。例外がそう、ノードが包装状態にあって、その場合、用法パケットのリングIDは無視されます。
Nodes that are not congested and that receive a non-null rcvd_usage generally propagate rcvd_usage to their upstream neighbor else propagate a null value of usage (all 1's). The exception is when an opportunity for local reuse is detected. Additional spatial reuse (local reuse) is achieved by comparing the forwarded rate (low pass filtered) to allow_usage. If the forwarded rate is less than the allowed usage, then a null value is propagated to the upstream neighbor.
混雑していなくて、ほかに一般に、rcvd_用法が伝播する非ヌルrcvd_用法を彼らの上流の隣人に受けるノードが用法(すべての1)のヌル値を伝播します。 例外は地方の再利用の機会が検出される時です。 追加空間的な再利用(地方の再利用)は、_用法を許容するために、進められたレート(フィルターにかけられた低いパス)を比較することによって、達成されます。 進められたレートが許容用法より少ないなら、ヌル値は上流の隣人に伝播されます。
Nodes that are congested propagate the smaller of lp_my_usage and rcvd_usage.
鬱血したノードは伝播します。lpでは、_私の_用法とrcvd_用法は、より小さいです。
Convergence is dependent upon number of nodes and distance. Simulation has shown simulation convergence within 100 msec for rings of several hundred miles.
集合はノードと距離の数に依存しています。 シミュレーションは数100マイルの響きのために100msecの中にシミュレーション集合を示しました。
Tsiang & Suwala Informational [Page 29] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[29ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
6.1. SRP-fa pseudo-code
6.1. SRP-ファ中間コード
A more precise definition of the fairness algorithm is shown below:
公正アルゴリズムの、より正確な定義は以下に示されます:
Variables:
変数:
lo_tb_depth low priority transit buffer depth
最低気温_Tbの深さの低優先権トランジットバッファの_深さ
my_usage count of octets transmitted by host lp_my_usage my_usage run through a low pass filter my_usage_ok flag indicating that host is allowed to transmit
私の八重奏の_用法カウントは_ホストlpによるそのホストを示す私の_用法_OKが旗を揚げさせるローパスフィルタを通した私の_用法走行が伝えることができる私の_用法を伝えました。
allow_usage the fair amount each node is allowed to transmit
各ノードが伝えることができる公正な量を_用法に許容してください。
fwd_rate count of octets forwarded from upstream lp_fwd_rate fwd_rate run through a low pass filter
上流のlp_fwd_レートfwd_レート走行からローパスフィルタまで進められた八重奏のfwd_レートカウント
congested node cannot transmit host traffic without the TB buffer
filling beyond its congestion threshold point.
鬱血したノードは混雑敷居ポイントを超えていっぱいになるTBバッファなしでホスト交通を伝えることができません。
rev_usage the usage value passed along to the upstream neighbor
用法値が上流の隣人に回した回転_用法
Constants:
定数:
MAX_ALLOWANCE = configurable value for max allowed usage for this node
マックス_ALLOWANCEはこのノードのための用法が許容された最大のために構成可能な値と等しいです。
DECAY_INTERVAL = 8000 octet times @ OC-12, 32,000 octet times @ OC-48
DECAY_INTERVALは8000年の八重奏回@OC-12、3万2000八重奏回@OC-48と等しいです。
AGECOEFF = 4 // Aging coeff for my_usage and fwd_rate
私の_用法とfwd_レートのためのAGECOEFF=4//老朽化しているcoeff
LP_FWD = 64 // Low pass filter for fwd_rate LP_MU = 512 // Low pass filter for my usage LP_ALLOW = 64 // Low pass filter for allow usage auto increment
fwd_レートLP_MU=のための私の用法LP_ALLOWのための512//ローパスフィルタが64//ローパスフィルタと等しいLP_FWD=64//ローパスフィルタは用法オートインクリメントを許容します。
NULL_RCVD_INFO = All 1's in rcvd_usage field
rcvd_用法によるすべてのINFO=1がさばくNULL_RCVD_
TB_LO_THRESHOLD // TB depth at which no more lo-prio host traffic
// can be sent
より多くの最低気温-prioホスト交通//を全く送ることができないTB_LO_THRESHOLD // TBの深さ
MAX_LRATE = AGECOEFF * DECAY_INTERVAL = 128,000 for OC-48, 32000 for
OC-12
OC-48のための12万8000、OC-12のためのAGECOEFF*腐敗_マックス_LRATE=間隔=32000
Tsiang & Suwala Informational [Page 30] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[30ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
THESE ARE UPDATED EVERY CLOCK CYCLE: =====================================
あらゆる時計サイクルこれらをアップデートします: =====================================
my_usage is incremented by 1 for every octet that is
transmitted by the host (does not include data
transmitted from the Transit Buffer).
私の_用法はホスト(Transit Bufferから送られたデータを含んでいない)によって伝えられる各八重奏あたり1つ増加されます。
fwd_rate is incremented by 1 for every octet that enters the
Transit Buffer
fwd_レートはTransit Bufferに入る各八重奏あたり1つ増加されます。
if ((my_usage < allow_usage) &&
!((lo_tb_depth > 0) && (fwd_rate < my_usage)) &&
(my_usage < MAX_ALLOWANCE))
// true means OK to send host packets
my_usage_ok = true;
(私の_用法<は_用法を許容します)、(最低気温_Tb_深さ>0)、(fwd_は、<が私の_用法であると評定します))、(私の_用法<マックス_ALLOWANCE)) = 本当に私の_用法_OKをホストパケットに送るためにOKの//本当の手段。
UPDATED WHEN USAGE_PKT IS RECEIVED: ===================================
用法_PKTが受け取られているとき、アップデートします: ===================================
if (usage_pkt.SA == my_SA) &&
[(usage_pkt.RI == my_RingID) || (node_state == wrapped)]
rcvd_usage = NULL_RCVD_INFO;
else
rcvd_usage = usage_pkt.usage;
(私の_用法_pkt.SA=SA)である、(私の_用法_pkt.RI=RingID)| | (=が包装したノード_状態)] rcvd_用法はNULL_RCVD_INFOと等しいです。 ほかのrcvd_用法は用法_pkt.usageと等しいです。
THE FOLLOWING IS CALCULATED EVERY DECAY_INTERVAL: ==================================================
以下はあらゆる腐敗_間隔計算されます: ==================================================
congested = (lo_tb_depth > TB_LO_THRESHOLD/2)
混雑している=(最低気温_Tb_深さ>Tb_最低気温_敷居/2)
lp_my_usage = ((LP_MU-1) * lp_my_usage + my_usage) / LP_MU
lp、_私の_用法=(LP_MU-1)*は_私の_用法+ 私の_用法) /LP_MUをlpします。
my_usage is decremented by min(allow_usage/AGECOEFF, my_usage/AGECOEFF)
私の_用法は分までに減少します。(_用法/AGECOEFF、私の_用法/AGECOEFFを許容します)
lp_fwd_rate = ((LP_FWD-1) * lp_fwd_rate + fwd_rate) / LP_FWD
lp_fwd_レート=((LP_FWD-1)*lp_fwd_レート+fwd_レート)/LP_FWD
fwd_rate is decremented by fwd_rate/AGECOEFF
fwd_レートはfwd_レート/AGECOEFFによって減少します。
(Note: lp values must be calculated prior to decrement of non-lp values).
(注意: 非lp値の減少の前にlp値について計算しなければなりません)。
if (rcvd_usage != NULL_RCVD_INFO)
allow_usage = rcvd_usage;
else
allow_usage += (MAX_LRATE - allow_usage) / (LP_ALLOW);
(rcvd_用法!=NULL_RCVD_INFO)が_を許容するなら、用法はrcvd_用法と等しいです。 ほか、_用法+=(マックス_LRATE--_用法を許容してください)/(LP_ALLOW)を許容してください。
Tsiang & Suwala Informational [Page 31] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[31ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
if (congested)
{
if (lp_my_usage < rcvd_usage)
rev_usage = lp_my_usage;
else
rev_usage = rcvd_usage;
}
else if ((rcvd_usage != NULL_RCVD_INFO) &&
(lp_fwd_rate > allow_usage)
rev_usage = rcvd_usage;
else
rev_usage = NULL_RCVD_INFO
混雑..用法..用法..回転..用法..用法..ほか..回転..用法..等しい..用法..ほか..用法..レート..許容..用法..回転..用法..等しい..用法..ほか..回転..用法..等しい
if (rev_usage > MAX_LRATE)
rev_usage = NULL_RCVD_INFO;
(回転_用法>マックス_LRATE)が_を回転させるなら、用法はNULL_RCVD_INFOと等しいです。
6.2. Threshold settings
6.2. 敷居設定
The low priority transit buffer (TB_LO_THRESHOLD) is currently sized to about 4.4 msec or 320 KB at OC12 rates. The TB_HI_THRESHOLD is set to about 870 usec higher than the TB_LO_THRESHOLD or at 458 KB at OC12 rates.
少ない優先権トランジットバッファ(TB_LO_THRESHOLD)は現在、OC12レートでおよそ4.4msecか320KBに大きさで分けられます。 TB_HI_THRESHOLDはTB_LO_THRESHOLDより高いおよそ870usecかOC12レートにおける458KBで用意ができています。
The high priority transit buffer needs to hold 2 to 3 MTUs or about 30KB.
高い優先権トランジットバッファは、2〜3MTUsかおよそ30KBを持つ必要があります。
7. SRP Synchronization
7. SRP同期
Each node operates in "free-run" mode. That is, the receive clock is derived from the incoming receive stream while the transmit clock is derived from a local oscillator. This eliminates the need for expensive clock synchronization as required in existing SONET networks. Differences in clock frequency are accommodated by inserting a small amount of idle bandwidth at each nodes output.
各ノードは「フリーラン」モードで作動します。 すなわち、受信、時計による引き出されて、入来から、流れが受信されているということである、局部発振器から派生していた状態で時計を送ってください。 これは必要に応じて既存のSonetネットワークで高価な時計同期の必要性を排除します。 クロック周波数の違いは、少量の活動していない帯域幅をそれぞれのノード出力に挿入することによって、設備されます。
The clock source for the transmit clock shall be selected to deviate by no more than 20 ppm from the center frequency. The overall outgoing rate of the node shall be rate shaped to accommodate the worst case difference between receive and transmit clocks of adjacent nodes. This works as follows:
時計を送ってください。時計ソース、中心周波数から20ppm未満逸脱するのが選択されるでしょう。 ノードの総合的な外向的なレートは最悪の場合差を収容する形成されたレートが隣接しているノードの時計を受けて、送るということでしょう。 これは以下の通り働いています:
A transit buffer slip count (tb_cnt) keeps track of the amount of octets inserted into the TB minus the amount of octets transmitted and is a positive integer.
トランジットバッファメモ用紙カウント(Tb_cnt)は、八重奏の量が伝えたTBマイナスに挿入された八重奏の量の動向をおさえて、正の整数です。
Tsiang & Suwala Informational [Page 32] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[32ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
To account for a startup condition where a packet is being inserted into an empty TB and the node was otherwise idle the tb_cnt is reset if the transmit interface is idle. Idle is defined as no data being sent even though there is opportunity to send (i.e. the transmit interface is not prohibited from transmitting by the physical layer).
伝わってください。パケットが空のTBに挿入されていてそうでなければノードが無駄であった始動状態を説明するために、Tb_cntがリセットされる、インタフェースは活動していません。 すなわち、活動していないのが、そこですが、送られないデータと全く定義されているのが、発信する機会であるということである、(伝える、身体検査で伝わるのから禁じられなかったインタフェース層)
An interval counter defines the sample period over which rate shaping is performed. This number should be sufficiently large to get an accurate rate shaping.
間隔カウンタはレート形成が実行されるサンプルの期間を定義します。 この数は正確なレートを形成させることができるくらい大きいはずです。
A token_bucket counter implements the rate shaping and is a signed integer. We increment this counter by one of two fixed values called quantums each sample period. Quantum1 sets the rate at (Line_rate - Delta) where delta is the clock inaccuracy we want to accommodate.
象徴_バケツカウンタは、レート形成を実行して、サインされた整数です。 私たちはこのカウンタをそれぞれのサンプルの期間にquantumsと呼ばれた2つの一定の価値の1つ増加します。 Quantum1はデルタが収容したいと思う時計不正確であるところに(線_レート--デルタ)におけるレートを設定します。
Quantum2 sets the rate at (Line_rate + Delta). If at the beginning of a sample period, tb_cnt >= sync_threshold, then we set the rate to Quantum2. This will allow us to catch up and causes the TB slip count to eventually go < sync_threshold. If tb_cnt is < sync_threshold then we set the rate to Quantum1.
Quantum2は(線_レート+デルタ)にレートを設定します。 Tb_cnt>がサンプルの期間の始めに同時性_敷居と等しいなら、私たちはQuantum2にレートを設定します。 これは、私たちが追いつくのを許容して、メモ用紙が結局行くために数えるTBに<同時性_敷居を引き起こします。 Tb_cntが<同時性_敷居であるなら、私たちはQuantum1にレートを設定します。
When the input rate and output rates are exactly equal, the tb_cnt will vary between sync_threshold > tb_cnt >= 0. This will vary for each implementation dependent upon the burst latencies of the design. The sync_threshold value should be set so that for equal transmit and receive clock rates, the transmit data rate is always Line_rate-Delta and will be implementation dependent.
入力率と出力が評価するとき、ちょうど同輩、cntが異なるTb_は同時性_敷居>Tb_cnt>=0です。 これは各実現単位でデザインの炸裂潜在に依存していた状態で異なるでしょう。 データ信号速度を伝えてください。同時性_閾値が設定しているべきであるので同輩のためのそれがクロックレートを送受信する、いつも線_レートデルタであり、実現に依存するでしょう。
The token_bucket is decremented each time data is transmitted. When token_bucket reaches a value <= 0, a halt_transmit flag is asserted which halts further transmission of data (halting occurs on a packet boundary of course which can cause token_bucket to become a negative number).
データが送られるたびに象徴_バケツは減少します。 停止_が伝える象徴_バケツ範囲値の<=0、aがいつ示されるかは断言されます(データのさらなる伝達を止めます)(停止は象徴_バケツがもちろんそれの缶によって負数になるパケット境界に起こります)。
7.1. SRP Synchronization Examples
7.1. SRP同期の例
Assume an interval of 2^^18 or 262144 clock cycles. A Quantum1 value must be picked such that the data rate will = (LINE_RATE - DELTA). A Quantum2 value must be picked and used if the tb_cnt shows that the incoming rate is greater than the outgoing rate and is = (LINE_RATE + DELTA). Assume that the source of the incoming and outgoing rate clocks are +/- 100 ppm.
2^^18クロック周期か262144クロック周期の間隔を仮定してください。 データ信号速度が等しいそのようなもの(線_RATE--デルタ)をQuantum1値に選ばなければなりません。 Tb_cntが入って来るレートが外向的なレートよりすばらしく、=(線_RATE+デルタ)であることを示すなら、Quantum2値を選ばれて、使用しなければなりません。 送受信のレート時計の源が+/-100ppmであると仮定してください。
For an OC12c SPE rate of 600 Mbps and a system clock rate of 800 Mbps (16 bits @ 50 Mhz). The system clock rate is the rate at which the system transmits bytes to the framer (in most cases the framer transmit rate is asynchronous from the rate at which the system transfers data to the framer).
600MbpsのOC12c SPEレートとシステムには、800Mbps(16ビットの@50Mhz)のレートの時間を計ってください。 システムクロックレートがシステムがバイトを喧嘩早い人に伝えるレートである、(多くの場合、喧嘩早い人が伝わる、レートがシステムがデータを移すレートから喧嘩早い人まで非同期である、)
Tsiang & Suwala Informational [Page 33] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[33ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
Quantum1/Interval * 800 Mbps = 600 Mbps(1 - Delta)
Quantum1 = Interval * (600/800) * (1 - Delta)
Quantum1 = Interval * (600/800) * (1 - 1e-4) = 196588
800Mbps=600Mbps(1--デルタ)のQuantum1/間隔*Quantum1=間隔*(600/800)*(1--デルタ)Quantum1は間隔*(600/800)*(1--1e-4)=196588と等しいです。
Quantum2/Interval * 800 Mbps = 600 Mbps(1 + Delta)
Quantum2 = Interval * (600/800) * (1 + Delta)
Quantum2 = Interval * (600/800) * (1 + 1e-4) = 196628
Quantum2/間隔*800Mbps=600Mbps(1+デルタ)のQuantum2=間隔*(600/800)*(1+デルタ)Quantum2は間隔*(600/800)*(1+1e-4)=196628と等しいです。
Note: The actual data rate for OC-12c is 599.04 Mbps.
以下に注意してください。 OC-12cのための実際のデータ信号速度は599.04Mbpsです。
8. IPS Protocol Description
8. IPSプロトコル記述
An SRP ring is composed of two counter-rotating, single fiber rings. If an equipment or fiber facility failure is detected, traffic going towards and from the failure direction is wrapped (looped) back to go in the opposite direction on the other ring. The wrap around takes place on the nodes adjacent to the failure, under software control. This way the traffic is re-routed from the failed span.
SRPリングは2個のカウンタを回転させて、単一のファイバーリングで構成されます。 設備かファイバー施設失敗が検出されるなら、指示と失敗指示から行く交通は、もう片方のリングの上に逆コースを行くために包装し返されます(輪にされます)。 失敗に隣接しておよそ包装はノードの上でソフトウェア制御装置の下で行われます。 このように、交通は失敗した長さから別ルートで送られます。
Nodes communicate between themselves using IPS signaling on both inner and outer ring.
ノードは、自分たちの間で内側の、そして、外側の両方のリングの上にIPSシグナリングを使用することで交信します。
The IPS octet contains specific protection information. The format of the IPS octet is as follows:
IPS八重奏は特異的予防情報を含んでいます。 IPS八重奏の形式は以下の通りです:
FIGURE 18. IPS Octet format:
図18 IPS Octet形式:
0-3 IPS Request Type
0-3 IPSはタイプを要求します。
1101 - Forced Switch (FS)
1011 - Signal Fail (SF)
1000 - Signal Degrade (SD)
0110 - Manual Switch (MS)
0101 - Wait to Restore (WTR)
0000 - No Request (IDLE)
1101--信号が(SF)1000に失敗するという1011が示す無理矢理のスイッチ(FS)は(サウスダコタ)0110--手動式スイッチ(MS)0101--(WTR)0000を回復するのを待っています--要求を全く下がらせません。(活動していません)です。
4 Path indicator
4経路インディケータ
0 - short (S)
1 - long (L)
0(短い(S)1)は切望されます。(L)
5-7 Status Code
5-7 ステータスコード
010 - Protection Switch Completed -traffic Wrapped (W)
000 - Idle (I)
回線切替装置が交通の包装された(W)000を完成したという010は怠けます。(I)
Tsiang & Suwala Informational [Page 34] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[34ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
The IPS control messages are shown in this document as:
IPSコントロールメッセージは本書では以下として示されます。
{REQUEST_TYPE, SOURCE_ADDRESS, WRAP_STATUS, PATH_INDICATOR}
_タイプ(ソース_アドレス)が_状態、経路_インディケータを包装するよう要求してください。
8.1. The IPS Request Types
8.1. IPSはタイプを要求します。
The following is a list of the request types, from the highest to the lowest priority. All requests are signaled using IPS control messages.
↓これは最も高い優先度から最も低い優先度までの要求タイプのリストです。 IPSコントロールメッセージを使用することですべての要求が合図されます。
1. Forced Switch (FS - operator originated)
1. 無理矢理のスイッチ(FS--溯源されたオペレータ)
This command performs the ring switch from the working channel
to the protection, wrapping the traffic on the node at which
the command is issued and at the adjacent node to which the
command is destined. Used for example to add another node to
the ring in a controlled fashion.
このコマンドは働くチャンネルから保護までリングスイッチを実行します、コマンドが発行されるノードの上と、そして、コマンドが運命づけられている隣接しているノードにおいて交通を包装して。 例えば管理された方法で別のノードをリングに加えるのにおいて、使用されています。
2. Signal Fail (SF - automatic)
2. 信号は失敗します。(SF--オートマチック)
Protection caused by a media "hard failure" or SRP keep- alive
failure. SONET examples of SF triggers are: Loss of Signal
(LOS), Loss of Frame (LOF), Line Bit Error Rate (BER) above a
preselected SF threshold, Line Alarm Indication Signal (AIS).
Note that the SRP keep-alive failure provides end-to-end
coverage and as a result SONET Path triggers are not necessary.
保護は「困難な失敗」かSRPが生きているように維持するメディアで失敗を引き起こしました。 SF引き金に関するSonetの例は以下の通りです。 Signal(LOS)の損失、Frame(LOF)、前選択されたSF敷居(線Alarm Indication Signal(AIS))を超えた線Bit Error Rate(BER)のLoss。 SRPが失敗を生かすというメモは終わりから端への適用範囲を提供します、そして、その結果、Sonet Path引き金は必要ではありません。
3. Signal Degrade (SD - automatic)
3. 信号は退行します。(サウスダコタ--オートマチック)
Protection caused by a media "soft failure". SONET example of a
SD is Line BER or Path BER above a preselected SD threshold.
保護はメディアで「柔らかい失敗」を引き起こしました。 サウスダコタに関するSonetの例は、前選択されたサウスダコタ敷居を超えた線BERかPath BERです。
4. Manual Switch (MS - operator originated)
4. 手動式スイッチ(MS--溯源されたオペレータ)
Like the FS, but of lower priority. Can be used for example to
take down the WTR.
FSにもかかわらず、低優先度について。 例えばWTRを降ろすのに使用できます。
5. Wait to Restore (WTR - automatic)
5. 復元する待ち(WTR--オートマチック)
Entered after the working channel meets the restoration
threshold after an SD or SF condition disappears. IPS waits WTR
timeout before restoring traffic in order to prevent protection
switch oscillations.
サウスダコタかSF状態が見えなくなった後に働くチャンネルが回復敷居を満たした後に入られます。 回線切替装置振動を防ぐために交通を復元する前に、IPSはWTRタイムアウトを待ちます。
Tsiang & Suwala Informational [Page 35] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[35ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
8.2. SRP IPS Protocol States
8.2. SRP IPSプロトコル州
Each node in the IPS protocol is in one of the following states for each of the rings:
IPSプロトコルの各ノードがそれぞれのリングのための以下の州の1つにあります:
8.2.1. Idle
8.2.1. 怠けてください。
In this mode the node is ready to perform the protection switches and
it sends to both neighboring nodes "idle" IPS messages, which include
"self" in the source address field {IDLE, SELF, I, S}
このモードで、ノードは回線切替装置を実行する準備ができています、そして、それは「活動していません、な」IPSメッセージを両方の隣接しているノードに送ります。(メッセージはソースアドレス・フィールドに「自己」を含んでいます)。活動していなさ、自己、I、S
8.2.2. Pass-through
8.2.2. 通り抜けてください。
Node participates in a protection switch by passing the wrapped traffic and long path signaling through itself. This state is entered based on received IPS messages. If a long path message with not null request is received and if the node does not strip the message (see Protocol Rules for stripping conditions) the node decrements the TTL and retransmits the message without modification. Sending of the Idle messages is stopped in the direction in which the message with not null request is forwarded.
それ自体を通して包装された交通と長い経路にシグナリングを向かわせることによって、ノードは回線切替装置に参加します。 この状態は受信されたIPSメッセージに基づいて入られます。 ヌル要求でないのがある長い経路メッセージが受信されていて、ノードがメッセージを剥取らないなら(状態を剥取るためにプロトコルRulesを見てください)、ノードは、TTLを減少させて、変更なしでメッセージを再送します。 Idleメッセージの発信はヌル要求でないのがあるメッセージが転送される方向に止められます。
8.2.3. Wrapped
8.2.3. 包装されます。
Node participates in a protection switch with a wrap present. This state is entered based on a protection request issued locally or based on received IPS messages.
包装が存在していた状態で、ノードは回線切替装置に参加します。 この状態は受信されたIPSメッセージに局所的に出されるか、または基づく保護要求に基づいて入られます。
8.3. IPS Protocol Rules
8.3. IPSプロトコル規則
8.3.1. SRP IPS Packet Transfer Mechanism
8.3.1. SRP IPSパケットトランスファ・メカニズム
R T.1:
R T.1:
IPS packets are transferred in a store and forward mode between adjacent nodes (packets do not travel more than 1 hop between nodes at a time). Received packet (payload portion) is passed to software based on interrupts.
店と前進のモードで隣接しているノードの間にIPSパケットを移します(パケットは一度に、ノードの間を1つ以上のホップを旅行しません)。 容認されたパケット(ペイロード部分)は中断に基づくソフトウェアに通過されます。
R T.2:
R T.2:
All IPS messages are sent to the neighboring nodes periodically on both inner and outer rings. The timeout period is configurable 1-600 sec (default 1 sec). It is desirable (but not required) that the timeout is automatically decreased by a factor of 10 for the short path protection requests.
内側の、そして、外側の両方のリングで定期的にすべてのIPSメッセージを隣接しているノードに送ります。 タイムアウト時間は1-600秒(1秒のデフォルト)構成可能です。 タイムアウトは短い経路保護要求のために10の要素によって自動的に静まらされるのが、望ましいです(しかし、必要ではありません)。
Tsiang & Suwala Informational [Page 36] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[36ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
8.3.2. SRP IPS Signaling and Wrapping Mechanism
8.3.2. メカニズムに合図して、包装するSRP IPS
R S.1:
R S.1:
IPS signaling is performed using IPS control packets as defined in Figure 14 "IPS Packet Format".
IPSシグナリングは、「IPSパケット・フォーマット」という図14で定義されるようにIPSコントロールパケットを使用することで実行されます。
R S.2:
R S.2:
Node executing a local request signals the protection request on both short (across the failed span) and long (around the ring) paths after performing the wrap.
包装を実行した後に、ローカルの要求を実行するノードが短い(失敗した長さの向こう側の)ものと同様に長い(リングの周りの)経路に関する保護要求を示します。
R S.3:
R S.3:
Node executing a short path protection request signals an idle request with wrapped status on the short (across the failed span) path and a protection request on the long (around the ring) path after performing the wrap.
包装を実行した後に、短い経路保護要求を実行するノードが短い(失敗した長さの向こう側の)経路の包装された状態と長い(リングの周りの)経路に関する保護要求で無駄な要求を示します。
R S.4:
R S.4:
A node which is neither executing a local request nor executing a short path request signals IDLE messages to its neighbors on the ring if there is no long path message passing through the node on that ring.
そのリングの上のノードを通してどんな長い経路メッセージ・パッシングもなければ、ローカルの要求を実行しないで、また短い経路要求を実行していないノードはリングの上にIDLEメッセージを隣人に示します。
R S.5:
R S.5:
Protection IPS packets are never wrapped.
保護IPS荷は決して包装されません。
R S.6:
R S.6:
If the protocol calls for sending both short and long path requests on the same span (for example if a node has all fibers disconnected), only the short path request should be sent.
プロトコルが、短いものと同様に長い経路要求を同じ長さに送るように求めるなら(例えば、ノードですべてのファイバーを外すなら)、短い経路要求だけを送るべきです。
R S.7:
R S.7:
A node wraps and unwraps only on a local request or on a short path request. A node never wraps or unwraps as a result of a long path request. Long path requests are used only to maintain protection hierarchy. (Since the long path requests do not trigger protection, there is no need for destination addresses and no need for topology maps)
ノードは、ローカルの要求かオンであるところだけで短い経路要求を包装して、開けます。 ノードは、長い経路要求包装するか、または決して開けません。 長い経路要求は使用されますが、保護階層構造を維持します。 (長い経路要求が保護の引き金とならないので、送付先アドレスの必要性がなくてトポロジー地図の必要は全くありません)
Tsiang & Suwala Informational [Page 37] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[37ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
In Figure 19, Node A detects SF (local request/ self-detected
request) on the span between Node A and Node B and starts sourcing
{SF, A, W, S} on the outer ring and {SF, A, W, L} on the inner ring.
Node B receives the protection request from Node A (short path
request) and starts sourcing {IDLE, B, W, S} on the inner ring and
{SF, B, W, L} on the outer ring.
図19では、Node AはNode AとNode Bの間の長さの上にSF(自己によってローカルの要求/検出された要求)を検出して、SF、A、W、Sの外側のリングの出典を明示し始めます、そして、SF、A、W、Lは内側で鳴ります。 ノードBは、Node A(短い経路要求)から保護要求を受け取って、IDLE、B、W、Sのインナー・リングの出典を明示し始めます、そして、SF、B、W、Lは外側で鳴ります。
FIGURE 19. SRP IPS Signaling
図19 SRP IPSシグナリング
{SF,A,W,S}
-------------------------------
| -----X--------------------- |
| | fiber | |
| v cut {IDLE,B,W,S}| v
----- -----
| A | | B |
| | | |
----- -----
^ | {SF,A,W,L} i ^ | o {SF,B,W,L}
| | n | | u
| | n | | t
| | e | | e
| v r | v r
SF、A、W、S------------------------------- | -----X--------------------- | | | ファイバー| | | vはIDLE、B、W、Sを切りました。| v----- ----- | A| | B| | | | | ----- ----- ^ | SF、A、W、L、i^| o SF、B、W、L| | n| | u| | n| | t| | e| | e| rに対して| rに対して
8.4. SRP IPS Protocol Rules
8.4. SRP IPSプロトコル規則
R P.1:
R P.1:
Protection Request Hierarchy is as follows (Highest priority to the lowest priority). In general a higher priority request preempts a lower priority request within the ring with exceptions noted as rules. The 4 bit values below correspond to the REQUEST_TYPE field in the IPS packet.
保護Request Hierarchyは以下の通りです(最も低い優先度への最優先)。 一般に、例外が規則として注意されている状態で、より高い優先権要求はリングの中に低優先度要求を先取りします。 以下の4ビットの値はIPSパケットのREQUEST_TYPE分野に対応しています。
1101 - Forced Switch (FS)
1011 - Signal Fail (SF)
1000 - Signal Degrade (SD)
0110 - Manual Switch (MS)
0101 - Wait to Restore (WTR)
0000 - No Request (IDLE): Lowest priority
1101--信号が(SF)1000に失敗するという1011が示す無理矢理のスイッチ(FS)は(活動していません)で(サウスダコタ)0110--手動式スイッチ(MS)0101--(WTR)0000を回復するのを待っています--要求を全く下がらせません: 最も低い優先度
R P.2:
R P.2:
Requests >= SF can coexist.
要求>=SFは共存できます。
Tsiang & Suwala Informational [Page 38] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[38ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
R P.3:
R P.3:
Requests < SF can not coexist with other requests.
<SFが他の要求と共存できないよう要求します。
R P.4:
R P.4:
A node always honors the highest of {short path request, self
detected request} if there is no higher long path message passing
through the node.
ノードを通してどんなより高い長い経路メッセージ・パッシングもなければ、ノードはいつも短い経路要求、最も高い自己検出された要求を光栄に思います。
R P.5:
R P.5:
When there are more requests of priority < SF, the first request to complete long path signaling will take priority.
優先権<SFの、より多くの要求があるとき、長い経路シグナリングを完成するという最初の要求は優先するでしょう。
R P.6:
R P.6:
A Node never forwards an IPS packet received by it which was originally generated by the node itself (it has the node's source address).
Nodeはそれによって受け取られたIPSパケットを決して進めません(元々、ノード自体で発生しました)(それには、ノードのソースアドレスがあります)。
R P.7:
R P.7:
Nodes never forward packets with the PATH_INDICATOR set to SHORT.
ノードはINDICATORがSHORTに設定するPATH_があるパケットを決して進めません。
R P.8:
R P.8:
When a node receives a long path request and the request is >= to the
highest of {short path request, self detected request}, the node
checks the message to determine if the message is coming from its
neighbor on the short path. If that is the case then it does not
enter pass-thru and it strips the message.
ノードが長い経路要求を受け取って、要求が短い経路要求、最も高い自己検出された要求の>=であるときに、ノードはメッセージが短い経路で隣人から来るかどうか決定するメッセージをチェックします。 それがそうであるなら、徹底的なパスに入りません、そして、メッセージを剥取ります。
R P.9:
R P.9:
When a node receives a long path request, it strips (terminates) the request if it is a wrapped node with a request >= than that in the request; otherwise it passes it through and unwraps.
ノードが長い経路要求を受け取るとき、要求におけるそれより要求>=がある包装されたノードであるなら要求を剥取ります(終えます)。 さもなければ、それは、通じてそれを通過して、開けられます。
R P.10:
R P.10:
Each node keeps track of the addresses of the immediate neighbors (the neighbor node address is gleaned from the short path IPS messages).
各ノードはすぐ隣の人のアドレスの動向をおさえます(隣人ノードアドレスは短い経路IPSメッセージから収集されます)。
Tsiang & Suwala Informational [Page 39] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[39ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
R P.11:
R P.11:
When a wrapped node (which initially detected the failure) discovers disappearance of the failure, it enters WTR (user-configurable WTR time-period). WTR can be configured in the 10-600 sec range with a default value of 60 sec.
包装されたノード(初めは、失敗を検出した)が失敗の消滅を発見するとき、それはWTR(ユーザ構成可能なWTRの期間)に入ります。 10-600秒の範囲で60秒のデフォルト値でWTRを構成できます。
R P.12:
R P.12:
When a node is in WTR mode, and detects that the new neighbor (as identified from the received short path IPS message) is not the same as the old neighbor (stored at the time of wrap initiation), the node drops the WTR.
aであるときに、ノードは、WTRモードであって、それを検出します。新しい隣人(受信された短い経路IPSメッセージから特定されるように)が年取った隣人(包装開始の時代、格納される)と同じでない、ノードはWTRを落とします。
R P.13:
R P.13:
When a node is in WTR mode and long path request Source is not equal to the neighbor Id on the opposite side (as stored at the time of wrap initiation), the node drops the WTR.
ノードがWTRモードであって、長い経路要求Sourceが反対側の隣人Idと等しくないときに(包装開始の時代格納されるように)、ノードはWTRを落とします。
R P.14:
R P.14:
When a node receives a local protection request of type SD or SF and it cannot be executed (according to protocol rules) it keeps the request pending. (The request can be kept pending outside of the protection protocol implementation).
ノードがタイプサウスダコタかSFのローカルの保護要求を受け取って、実行できないとき(プロトコル規則に従って)、それは未定の要求を保ちます。 (保護プロトコル実現の外で要求を未定に保つことができます。)
R P.15:
R P.15:
If a local non-failure request (WTR, MS, FS) clears and if there are no other requests pending, the node enters idle state.
ローカルの非失敗要求(WTR、MS FS)がクリアされて、他のどんな未定の要求もなければ、ノードは活動していない状態に入ります。
R P.16:
R P.16:
If there are two failures and two resulting WTR conditions on a single span, the second WTR to time out brings both the wraps down (after the WTR time expires a node does not unwrap automatically but waits till it receives idle messages from its neighbor on the previously failed span)
ただ一つの長さの上に2つの失敗と2つの結果として起こるWTR状態があれば、タイムアウトへの第2WTRは両方の機密を降ろします。(WTR時間が期限が切れた後に、ノードは、自動的に開けませんが、以前に失敗した長さの上に隣人から無駄なメッセージを受け取るまで、待ちます)
R P.17:
R P.17:
If a short path FS request is present on a given side and a SF/SD condition takes place on the same side, accept and process the SF/SD condition ignoring the FS. Without this rule a single ended wrap condition could take place. (Wrap on one end of a span only).
FSが要求する短い経路が与える側に存在していて、SF/サウスダコタ状態が同じ側で行われるなら、FSを無視しながら、SF/サウスダコタ状態を受け入れて、処理してください。 シングルが終わらせたこの規則がなければ、包装状態は行われるかもしれません。 (長さの片端だけでは、包装します。)
Tsiang & Suwala Informational [Page 40] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[40ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
8.5. State Transitions
8.5. 状態遷移
Figure 20 shows the simplified state transition diagram for the IPS protocol:
図20はIPSプロトコルのために簡易型の状態遷移ダイヤグラムを示しています:
FIGURE 20. Simplified State Transitions Diagram
図20 変遷が図解する簡易型の状態
Local FS,SF,SD,MS req.
--------- or Rx{REQ,SRC,W,S} from mate
| IDLE |-------------------------------------------
| |<---------------------------------------- |
--------- Local REQ clears | |
^ | or Rx{IDLE,SRC,I,S} | |
| | | |
| | | |
| | | |
| | | |
Rx{IDLE,SRC,I,S}| | Rx{REQ,SRC,W,L} | |
| | | |
| | | |
| v Local FS,SF,SD,MS REQ > Active req. | v
--------- or Rx{REQ,SRC,W,S},REQ > Active req. ---------
| PASS |------------------------------------>| WRAPPED |
| THRU |<------------------------------------| |
--------- ---------
Forwards Tx{REQ,SELF,W,S} for local REQ
{REQ,SRC,W,L} Tx{IDLE,SELF,W,S} for mate REQ
& Tx{REQ,SELF,W,L}
地方のFS、SF、サウスダコタMS req。 --------- Rx、REQ、SRC、W、S、仲間| 怠けてください。|------------------------------------------- | |<---------------------------------------- | --------- 地方のREQはクリアします。| | ^ | Rx、活動していなさ、SRC、I、S| | | | | | | | | | | | | | | | | | Rx、活動していなさ、SRC、I、S| | REQ、SRC、W、LをRxします。| | | | | | | | | | | Local FS、SF、サウスダコタMS REQ>Active reqに対して。 | v--------- Rx、REQ、SRC、W、S、REQ>Active req。 --------- | パス|------------------------------------>| 包装されます。| | 徹底的に|<------------------------------------| | --------- --------- 地方のREQのためにREQ、SELF、W、SをTxに送る、REQ、SRC、W、L、Tx、IDLE、SELF、W、S、仲間REQ&TxREQ、自己、W、L
Legend: Mate = node on the other end of the affected span
REQ = {FS | SF | SD | MS}
伝説: 影響を受ける長さREQ=のもう一方の端に=ノードを噛み合わせてください。FS|SF|サウスダコタ| さん
8.6. Failure Examples
8.6. 失敗の例
8.6.1. Signal Failure - Single Fiber Cut Scenario
8.6.1. 信号の故障--ただ一つのファイバーカットシナリオ
Sample scenario in a ring of four nodes A, B, C and D, with unidirectional failure on a fiber from A to B, detected on B. Ring is in the Idle state (all nodes are Idle) prior to failure.
AからBまでのファイバーの上に単方向の失敗がある状態でA、B、C、およびDがB.Ringに検出した4つのノードの響きでのサンプルシナリオが失敗の前にIdle状態(すべてのノードがIdleである)にあります。
Signal Fail Scenario
信号はシナリオに失敗します。
1. Ring in Idle, all nodes transmit (Tx) {IDLE, SELF, I, S} on both
rings (in both directions)
1. Idleを迎え入れてください、そして、すべてのノードが両方のリングの上にIDLE、SELF、I、Sを伝えます(Tx)。(両方の方向への)
Tsiang & Suwala Informational [Page 41] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[41ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
FIGURE 21. An SRP Ring with outer ring fiber cut
図21 外側のリングファイバーカットがあるSRP Ring
fiber cut
---------X-----------------------------
| ----------------------------------- |
| | | |
| v | v
----- -----
| A | | B |
| | | |
----- -----
^ | ^ |
o | | i | |
u | | n | |
t | | n | |
e | | e | |
r | | r | |
| v | v
----- -----
| D | | C |
| | | |
----- -----
| | | |
| | | |
| ----------------------------------- |
---------------------------------------
ファイバーカット---------X----------------------------- | ----------------------------------- | | | | | | v| v----- ----- | A| | B| | | | | ----- ----- ^ | ^ | o | | i| | u| | n| | t| | n| | e| | e| | r| | r| | | v| v----- ----- | D| | C| | | | | ----- ----- | | | | | | | | | ----------------------------------- | ---------------------------------------
2. B detects SF on the outer ring, transitions to Wrapped state
(performs a wrap), Tx towards A on the inner ring/short path:
{SF, B, W, S} and on the outer ring/long path: Tx {SF, B, W, L}
2. Bは外側のリングの上にSFを検出します、Wrapped状態(包装を実行する)への変遷、インナー・リング/短い経路のAに向かったTx: そして、SF、B、W、S、外側のリング/長い経路で: TxSF、B、W、L
3. Node A receives protection request on the short path,
transitions to Wrapped state, Tx towards B on short path:
{IDLE, A, W, S} (message does not go through due to the
failure) and on the long path: Tx {SF, A, W, L}
3. ノードAは短い経路で短い経路に関する保護要求、Wrapped状態、Txへの変遷をBに向かって受けます: そして、IDLE、A、W、S(メッセージは失敗のため通られない)、長い経路で: TxSF、A、W、L
4. As the nodes D and C receive a switch request, they enter a
pass-through mode (in each direction) which mean they stop
sourcing the Idle messages and start passing the messages
between A an B
4. ノードDとCがスイッチ要求を受け取るのに従って、それらは、それらがIdleメッセージの出典を明示するのをそれの平均を止める通じて通りモード(各方向への)に入って、Aの間のメッセージにBを通過し始めます。
5. Steady state is reached
5. 定常状態に達しています。
Tsiang & Suwala Informational [Page 42] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[42ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
Signal Fail Clears
信号やり損ないはクリアされます。
1. SF on B clears, B does not unwrap, sets WTR timer, Tx {WTR, B,
W, S} on inner and Tx {WTR, B, W, L}
1. Tx、BのSFがクリアして、Bが開けられないで、セットがWTRタイマである、WTR、B、W、S、内側、TxWTR、B、W、L
2. Node A receives WTR request on the short path, does not unwrap,
Tx towards B on short path: {IDLE, A, W, S} (message does not
go through due to the failure) and on the long path: Tx {WTR,
A, W, L}
2. ノードAは、短い経路に関するWTR要求を受け取って、開けないで、劣るところのBに向かったTxは経路です: そして、IDLE、A、W、S(メッセージは失敗のため通られない)、長い経路で: TxWTR、A、W、L
3. Nodes C and D relay long path messages without changing the IPS
octet
3. IPS八重奏を変えないで、ノードCとDは長い経路メッセージをリレーします。
4. Steady state is reached
4. 定常状態に達しています。
5. WTR times out on B. B transitions to idle state (unwraps) Tx
{IDLE, B, I, S} on both inner and outer rings
5. IDLE、B、I、Sがともに内側と外側で州(開ける)のTxを空費するB.B変遷の外では、鳴るというWTR回
6. A receives Rx {IDLE, B, I, S} and transitions to Idle
6. AがRxを受ける、IDLE、B、I、S、Idleへの変遷
7. As idle messages reach C and D the nodes enter the idle state
(start sourcing the Idle messages)
7. 無駄なメッセージがCとDに達するのに従って、ノードは活動していない状態に入ります。(Idleメッセージの出典を明示し始めます)
8. Steady state it reached
8. それが達した定常状態
8.6.2. Signal Failure - Bidirectional Fiber Cut Scenario
8.6.2. 信号の故障--双方向のファイバーカットシナリオ
Sample scenario in a ring of four nodes A, B, C and D, with a bidirectional failure between A and B. Ring is in the Idle state (all nodes are Idle) prior to failure.
A、B、C、およびAとB.の間には、双方向の失敗はあるDが鳴らす4つのノードの響きでのサンプルシナリオが失敗の前にIdle状態(すべてのノードがIdleである)にあります。
Signal Fail Scenario
信号はシナリオに失敗します。
1. Ring in Idle, all nodes transmit (Tx) {IDLE, SELF, I, S} on
both rings (in both directions)
1. Idleを迎え入れてください、そして、すべてのノードが両方のリングの上にIDLE、SELF、I、Sを伝えます(Tx)。(両方の方向への)
2. A detects SF on the outer ring, transitions to Wrapped state
(performs a wrap), Tx towards B on the inner ring/short path:
{SF, A, W, S} and on the outer ring/long path: Tx {SF, A, W, L}
2. Aは外側のリングの上にSFを検出します、Wrapped状態(包装を実行する)への変遷、インナー・リング/短い経路のBに向かったTx: そして、SF、A、W、S、外側のリング/長い経路で: TxSF、A、W、L
3. B detects SF on the outer ring, transitions to Wrapped state
(performs a wrap), Tx towards A on the inner ring/short path:
{SF, B, W, S} and on the outer ring/long path: Tx {SF, B, W, L}
3. Bは外側のリングの上にSFを検出します、Wrapped状態(包装を実行する)への変遷、インナー・リング/短い経路のAに向かったTx: そして、SF、B、W、S、外側のリング/長い経路で: TxSF、B、W、L
Tsiang & Suwala Informational [Page 43] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[43ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
FIGURE 22. An SRP Ring with bidirectional fiber cut
図22 双方向のファイバーカットがあるSRP Ring
fiber cut
---------X-----------------------------
| -------X--------------------------- |
| | fiber cut | |
| v | v
----- -----
| A | | B |
| | | |
----- -----
^ | ^ |
o | | i | |
u | | n | |
t | | n | |
e | | e | |
r | | r | |
| v | v
----- -----
| D | | C |
| | | |
----- -----
| | | |
| | | |
| ----------------------------------- |
---------------------------------------
ファイバーカット---------X----------------------------- | -------X--------------------------- | | | ファイバーカット| | | v| v----- ----- | A| | B| | | | | ----- ----- ^ | ^ | o | | i| | u| | n| | t| | n| | e| | e| | r| | r| | | v| v----- ----- | D| | C| | | | | ----- ----- | | | | | | | | | ----------------------------------- | ---------------------------------------
4. As the nodes D and C receive a switch request, they enter a
pass-through mode (in each direction) which mean they stop
sourcing the Idle messages and start passing the messages
between A an B
4. ノードDとCがスイッチ要求を受け取るのに従って、それらは、それらがIdleメッセージの出典を明示するのをそれの平均を止める通じて通りモード(各方向への)に入って、Aの間のメッセージにBを通過し始めます。
5. Steady state is reached
5. 定常状態に達しています。
Signal Fail Clears
信号やり損ないはクリアされます。
1. SF on A clears, A does not unwrap, sets WTR timer, Tx {WTR, A,
W, S} towards B and Tx {WTR, A, W, L} on the long path
1. AのSFはクリアして、Aは開けられないで、セットはWTRタイマです、Tx、WTR、A、W、S、BとTx、WTR、A、W、L、長い経路
2. SF on B clears, B does not unwrap. Since it now has a short
path WTR request present from A it acts upon this request. It
keeps the wrap, Tx {IDLE, B, W, S} towards A and Tx {WTR, B, W,
L} on the long path
2. BのSFはクリアして、Bは開けられません。 現在、Aから現在の短い経路WTR要求があるので、それはこの要求に作用します。 それが、包装、TxがIDLE、B、W、SであることをAとTxに向かって保つ、WTR、B、W、L、長い経路
Tsiang & Suwala Informational [Page 44] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[44ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
3. Nodes C and D relay long path messages without changing the IPS
octet
3. IPS八重奏を変えないで、ノードCとDは長い経路メッセージをリレーします。
4. Steady state is reached
4. 定常状態に達しています。
5. WTR times out on A. A enters the idle state (drops wraps) and
starts transmitting idle in both rings
5. A.AのWTR回は、活動していない状態(機密を落とす)に入って、両方のリングで活動していない状態で伝わり始めます。
6. B sees idle request on short path and enters idle state
6. Bは、短い経路に関する無駄な要求を見て、活動していない状態に入力します。
7. Remaining nodes in the ring enter the idle state
7. リングでの残っているノードは活動していない状態に入ります。
8. Steady state is reached
8. 定常状態に達しています。
8.6.3. Failed Node Scenario
8.6.3. 失敗したノードシナリオ
FIGURE 23. An SRP Ring with a failed node
図23 失敗したノードのSRP Ring
---------------------------------------
| ----------------------------------- |
| | | |
| v | v /
----- ----/
| A | | C/| failed
| | | / | node C
----- -/---
^ | /^ |
o | | i | |
u | | n | |
t | | n | |
e | | e | |
r | | r | |
| v | v
----- -----
| D | | B |
| | | |
----- -----
| | | |
| | | |
| ----------------------------------- |
---------------------------------------
--------------------------------------- | ----------------------------------- | | | | | | v| /に対して----- ----/ | A| | C/| 失敗されます。| | | / | ノードC----- -/--- ^ | /^ | o | | i| | u| | n| | t| | n| | e| | e| | r| | r| | | v| v----- ----- | D| | B| | | | | ----- ----- | | | | | | | | | ----------------------------------- | ---------------------------------------
Sample scenario in a ring where node C fails. Ring is in the Idle state (all nodes are Idle) prior to failure.
ノードCが失敗するリングでシナリオを抽出してください。 リングが失敗の前にIdle状態(すべてのノードがIdleである)にあります。
Tsiang & Suwala Informational [Page 45] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[45ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
Node Failure (or fiber cuts on both sides of the node)
ノード障害(または、ノードの両側におけるファイバーカット)
1. Ring in Idle, all nodes transmit (Tx) {IDLE, SELF, I, S} on
both rings (in both directions)
1. Idleを迎え入れてください、そして、すべてのノードが両方のリングの上にIDLE、SELF、I、Sを伝えます(Tx)。(両方の方向への)
2. Based on the source field of the idle messages, all nodes
identify the neighbors and keep track of them
2. 無駄なメッセージのソースフィールドに基づいて、すべてのノードが、隣人を特定して、彼らの動向をおさえます。
3. B detects SF on the outer ring, transitions to Wrapped state
(performs a wrap), Tx towards C on the inner ring/short path:
{SF, B, W, S} and on the outer ring/long path: Tx {SF, B, W, L}
3. Bは外側のリングの上にSFを検出します、Wrapped状態(包装を実行する)への変遷、インナー・リング/短い経路のCに向かったTx: そして、SF、B、W、S、外側のリング/長い経路で: TxSF、B、W、L
4. A detects SF on the inner ring, transitions to Wrapped state
(performs a wrap), Tx towards C on the outer ring/short path:
{SF, A, W, S} and on the inner ring/long path: Tx {SF, A, W, L}
4. Aはインナー・リングの上にSFを検出します、Wrapped状態(包装を実行する)への変遷、外側のリング/短い経路のCに向かったTx: そして、SF、A、W、S、インナー・リング/長い経路で: TxSF、A、W、L
5. As the nodes on the long path between A and B receive a SF
request, they enter a pass-through mode (in each direction),
stop sourcing the Idle messages and start passing the messages
between A an B
5. 長い経路のノードがAとBとの間にSF要求を受け取るのに従って、それらは、通じて通りモード(各方向への)に入って、Idleメッセージの出典を明示するのを止めて、Aの間のメッセージにBを通過し始めます。
6. Steady state is reached
6. 定常状態に達しています。
Failed Node and One Span Return to Service
調整する失敗したノードと1つの長さリターン
Note: Practically the node will always return to service with one span coming after the other (with the time delta potentially close to 0). Here, a node is powered up with the fibers connected and fault free.
以下に注意してください。 1つの長さが次々と来ていて、実際にノードはいつもサービスに戻るでしょう(時間デルタで、潜在的に0に引けてください)。 ここで、ファイバーが接続されて、欠点が無料でノードは動かされます。
1. Node C and a span between A and C return to service (SF between
A and C disappears)
1. ノードCとAとCの間の長さはサービスに戻ります。(AとCの間のSFは見えなくなります)
2. Node C, not seeing any faults starts to source idle messages
{IDLE, C, I, S} in both directions.
2. どんな欠点も見るのではなく、ノードCが両方の指示のソースの無駄なメッセージIDLE、C、I、Sに始まります。
3. Fault disappears on A and A enters a WTR (briefly)
3. 欠点はAで見えなくなります、そして、AはWTRに入ります。(簡潔に)
4. Node A receives idle message from node C. Because the long path
protection request {SF, B, W, L} received over the long span is
not originating from the short path neighbor (C), node A drops
the WTR and enters a PassThrough state passing requests between
C and B
4. ノードAは、ノードC.BecauseからのSF、B、W、長い長さにわたって受け取られていているLが背の低い経路隣人(C)から発していないという長い経路保護要求であり、ノードAがWTRを落とすという無駄なメッセージを受け取って、CとBの間に要求に合格しながら、PassThrough状態に入力します。
5. Steady state is reached
5. 定常状態に達しています。
Tsiang & Suwala Informational [Page 46] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[46ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
Second Span Returns to Service
第2長さはサービスに戻ります。
The scenario is like the Bidirectional Fiber Cut fault clearing scenario.
シナリオはBidirectional Fiber Cut欠点開拓地シナリオに似ています。
8.6.4. Bidirectional Fiber Cut and Node Addition Scenarios
8.6.4. 双方向のファイバーカットとノード添加シナリオ
FIGURE 24. An SRP Ring with a failed node
図24 失敗したノードのSRP Ring
wrap
----->|--------------------------------
| -<--|------------------------------ |
| | | |
| v | v
----- ----
| A | | C | Added
| | | | node
----- -----
^ | ^ |
o | | i | |
u | | n | |
t | | n | |
e | | e --- wrap
r | | r ^ |
| v | v
----- -----
| D | | B |
| | | |
----- -----
| | | |
| | | |
| ----------------------------------- |
---------------------------------------
包装----->|-------------------------------- | -<--|------------------------------ | | | | | | v| v----- ---- | A| | C| 加えられます。| | | | ノード----- ----- ^ | ^ | o | | i| | u| | n| | t| | n| | e| | e--- rを包装してください。| | r^| | v| v----- ----- | D| | B| | | | | ----- ----- | | | | | | | | | ----------------------------------- | ---------------------------------------
Sample scenario in a ring where initially nodes A and B are connected. Subsequently fibers between the nodes A and B are disconnected and a new node C is inserted.
初めはノードAとBが接続されているリングでシナリオを抽出してください。 次に、ノードAとBの間のファイバーは外されます、そして、新しいノードCは挿入されます。
Bidirectional Fiber Cut
双方向のファイバーカット
1. Ring in Idle, all nodes transmit (Tx) {IDLE, SELF, I, S} on
both rings (in both directions)
1. Idleを迎え入れてください、そして、すべてのノードが両方のリングの上にIDLE、SELF、I、Sを伝えます(Tx)。(両方の方向への)
2. Fibers are removed between nodes A and B
2. ファイバーはノードAとBの間に移されます。
3. B detects SF on the outer ring, transitions to Wrapped state
(performs a wrap), Tx towards A on the inner ring/short path:
{SF, B, W, S} and on the outer ring/long path: Tx {SF, B, W, L}
3. Bは外側のリングの上にSFを検出します、Wrapped状態(包装を実行する)への変遷、インナー・リング/短い経路のAに向かったTx: そして、SF、B、W、S、外側のリング/長い経路で: TxSF、B、W、L
Tsiang & Suwala Informational [Page 47] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[47ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
4. A detects SF on the inner ring, transitions to Wrapped state
(performs a wrap), Tx towards B on the inner ring/short path:
{SF, A, W, S} and on the outer ring/long path: Tx {SF, A, W, L}
4. Aはインナー・リングの上にSFを検出します、Wrapped状態(包装を実行する)への変遷、インナー・リング/短い経路のBに向かったTx: そして、SF、A、W、S、外側のリング/長い経路で: TxSF、A、W、L
5. As the nodes on the long path between A and B receive a SF
request, they enter a pass-through mode (in each direction),
stop sourcing the Idle messages and start passing the messages
between A an B
5. 長い経路のノードがAとBとの間にSF要求を受け取るのに従って、それらは、通じて通りモード(各方向への)に入って、Idleメッセージの出典を明示するのを止めて、Aの間のメッセージにBを通過し始めます。
6. Steady state is reached
6. 定常状態に達しています。
Node C is Powered Up and Fibers Between Nodes A and C are Reconnected
ノードCはPowered Upです、そして、Fibers Between Nodes AとCはReconnectedです。
This scenario is identical to the returning a Failed Node to Service scenario.
このシナリオはServiceシナリオへの戻っているa Failed Nodeと同じです。
Second Span Put Into Service
サービスに入れられた第2長さ
Nodes C and B are connected. The scenario is identical to Bidirectional Fiber Cut fault clearing scenario.
ノードCとBは接続されています。 シナリオはBidirectional Fiber Cut欠点開拓地シナリオと同じです。
9. SRP over SONET/SDH
9. Sonet/SDHの上のSRP
Although SRP is media independent it is worth noting how SRP is used with a layer 1 media type. SRP over SONET/SDH is the first media type perceived for SRP applications.
SRPはメディア独立者ですが、SRPが層1のメディアタイプでどう使用されるように注意するか価値があります。 Sonet/SDHの上のSRPはタイプがSRPアプリケーションのために知覚した最初のメディアです。
Flag delimiting on SONET/SDH uses the octet stuffing method defined for POS. The flags (0x7E) are packet delimiters required for SONET/SDH links but may not be necessary for SRP on other media types. End of a packet is delineated by the flag which could also be the same as the next packet's starting flag. If the flag (0x7E) or an escape character (0x7D) are present anywhere inside the packet, they have to be escaped by the escape character when used over SONET/SDH media.
Sonet/SDH用途のときにPOSのために定義された方法を詰める八重奏を区切って、弛んでください。 旗(0x7E)は、Sonet/SDHリンクに必要であるパケットデリミタですが、他のメディアタイプでSRPに必要でないかもしれません。 パケットの端はまた、次のパケットの始めの旗と同じであるかもしれない旗で図で表わされます。 旗(0x7E)か拡張文字(0x7D)が存在しているなら、パケットの中でどこでも、Sonet/SDHメディアの上で使用されると、それら拡張文字によって逃げられなければなりません。
SONET/SDH framing plus POS packet delimiting allows SRP to be used directly over fiber or through an optical network (including WDM equipment).
そのうえ、POSパケットの区切りを縁どるSonet/SDHは、SRPがファイバーの直接上、または、光学ネットワークを通して使用されるのを許容します(WDM設備を含んでいて)。
SRP may also connect to a SONET/SDH ring network via a tributary connection to a SONET/SDH ADM (Add Drop Multiplexor). The two SRP rings may be mapped into two STS-Nc connections. SONET/SDH networks typically provide fully redundant connections, so SRP mapped into two STS-Nc connections will have two levels of protection. The SONET/SDH network provides layer 1 protection, and SRP provides layer 2 protection. In this case it is recommended to hold off the SRP Signal Fail IPS triggers (which correspond to failures which can be
また、SRPはSonet/SDH ADMとの進貢している接続でSonet/SDHリングネットワークに接続するかもしれません(Drop Multiplexorを加えてください)。 2個のSRPリングが2つのSTS-Nc接続に写像されるかもしれません。 Sonet/SDHネットワークが完全に余分な接続を通常提供するので、2つのSTS-Nc接続に写像されたSRPは2つのレベルの保護を持つでしょう。 Sonet/SDHネットワークは層1の保護を提供します、そして、SRPは層2の保護を提供します。 この場合SRP Signal Fail IPS引き金を食い止めるのがお勧めである、(そうすることができる失敗に対応します。
Tsiang & Suwala Informational [Page 48] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[48ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
protected by SONET/SDH) for about 100 msec in order to allow the SONET/SDH network to protect. Only if a failure persists for over 100 msec (indicating SONET/SDH protection failure) should the IPS protection take place.
Sonet/SDHによって保護される、)、100msecに関して、Sonet/SDHを許容するには、保護するのをネットワークでつないでください。 失敗が100以上msecのために持続している場合にだけ(Sonet/SDH保護の故障を示して)、IPS保護は行われるべきですか?
Since multiple protection levels over the same physical infrastructure are not very desirable, an alternate way of connecting SRP over a SONET/SDH network is configuring SONET/SDH without protection. Since the connection is unprotected at layer 1, SRP would be the sole protection mechanism.
同じ物的なインフラの上の多重防護レベルがそれほど望ましくないのでSonet/SDHネットワークの上にSRPを接続する交互の方法は保護がなければSonet/SDHを構成することです。 接続が層1で保護がないので、SRPは唯一の保護メカニズムでしょう。
Hybrid SRP rings may also be built where some parts of the ring traverse over a SONET/SDH network while other parts do not.
また、ハイブリッドSRPリングは他の部品である間のSonet/SDHネットワークの上のリング横断のいくつかの部品が組立てられないところで組立てられるかもしれません。
Connections to a SONET/SDH network would have to be synchronized to network timing by some means. This can be accomplished by locking the transmit connection to the frequency of the receive connection (called loop timing) or via an external synchronization technique.
Sonet/SDHネットワークへのコネクションズはどうでもネットワークタイミングと同期しなければならないでしょう。 ロックすることによってこれを達成できる、頻度との接続を伝える、接続(輪のタイミングと呼ばれる)か外部同期のテクニックで、受信してください。
Connections made via dark fiber or over a WDM optical network should utilize internal timing as clock synchronization is not necessary in this case.
時計同期はこの場合必要でないので、ダークファイバを通してWDMの光学ネットワークの上で作られたコネクションズは内部のタイミングを利用するべきです。
10. Pass-thru mode
10. 徹底的なパスモード
An optional mode of operation is pass-thru mode. In pass-thru mode, a node transparently forwards data. The node does not source packets, and does not modify any of the packets that it forwards. Data should continue to be sorted into high and low priority transit buffers with high priority transit buffers always emptied first. The node does not source any control packets (e.g. topology discovery or IPS) and basically looks like a signal regenerator with delay (caused by packets that happened to be in the transit buffer when the transition to pass-thru mode occurred).
任意の運転モードは徹底的なパスモードです。 徹底的なパスモードで、ノードは透明にデータを転送します。 ノードは、どんなソースにもパケットをしないで、またそれが進めるパケットのいずれも変更しません。 データは、高い優先権トランジットバッファが最初にいつも空にされている上下の優先権トランジットバッファに分類され続けるべきです。 ノードは、どんなコントロールパケット(例えば、トポロジー発見かIPS)も出典を明示しないで、基本的に遅れがある信号再生器に似ています(徹底的なパスモードへの変遷が起こったときトランジットバッファにたまたまあったパケットで、引き起こされます)。
A node can enter pass-thru mode because of an operator command or due to a error condition such as a software crash.
ノードはオペレータコマンドのためソフトウェアクラッシュなどのエラー条件のため徹底的なパスモードを入れることができます。
Tsiang & Suwala Informational [Page 49] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[49ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
11. References
11. 参照
[1] ANSI X3T9 FDDI Specification
[1] ANSI X3T9 FDDI仕様
[2] IEEE 802.5 Token Ring Specification
[2] IEEE802.5トークンリング仕様
[3] Bellcore GR-1230, Issue 4, Dec. 1998, "SONET Bidirectional
Line-Switched Ring Equipment Generic Criteria".
[3] Bellcore GR-1230、「設備のSonet双方向の線で切り換えられたリングジェネリック評価基準」を4、1998年12月に発行してください。
[4] ANSI T1.105.01-1998 "Synchronous Optical Network (SONET)
Automatic Protection Switching"
[4] 「同期式光通信網(Sonet)の自動保護の切り換えANSI T1.105.01-1998」
[5] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June
1999.
[5]MalisとA.とW.シンプソン、「Sonet/SDHの上のppp」、RFC2615、1999年6月。
[6] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July
1994.
[6] シンプソン、W.、「HDLCのような縁どりにおけるppp」、STD51、RFC1662、1994年7月。
12. Security Considerations
12. セキュリティ問題
As in any shared media, packets that traverse a node are available to that node if that node is misconfigured or maliciously configured. Additionally, it is possible for a node to not only inspect packets meant for another node but to also prevent the intended node from receiving the packets due to the destination stripping scheme used to obtain spatial reuse. Topology discovery should be used to detect duplicate MAC addresses.
どんな共有されたメディアのようにも、そのノードがmisconfiguredされるか、または陰湿に構成されるなら、ノードを横断するパケットはそのノードに利用可能です。 さらに、別のノードのために意味されたパケットを点検するだけではないノードには、それは可能ですが、また、意図しているノードが目的地のため計画を剥取りながらパケットを受けるのを防ぐのが以前はよく空間的な再利用を得ていました。 トポロジー発見は、写しMACアドレスを検出するのに使用されるべきです。
13. IPR Notice
13. IPR通知
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
14. Acknowledgments
14. 承認
The authors would like to acknowledge Hon Wah Chin who came up with the original version of the SRP-fa. Besides the authors, the original conceivers of SRP include Hon Wah Chin, Graeme Fraser, Tony Bates, Bruce Wilford, Feisal Daruwalla, and Robert Broberg.
作者はSRP-ファのオリジナルバージョンを思いついたHonバーチンを承認したがっています。 作者以外に、SRPのオリジナルのconceiversはHonバーチン、グレーム・フレーザ、トニー・ベイツ、ブルース・ウィルフォード、Feisal Daruwalla、およびロバートBrobergを含んでいます。
Tsiang & Suwala Informational [Page 50] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[50ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
15. Authors' Addresses
15. 作者のアドレス
Comments should be sent to the authors at the following addresses:
以下のアドレスの作者にコメントを送るべきです:
David Tsiang Cisco Systems 170 W. Tasman Drive San Jose, CA 95134
デヴィッド・Tsiangシスコシステムズ170w.タスマン・Driveサンノゼ、カリフォルニア 95134
Phone: (408) 526-8216 EMail: tsiang@cisco.com
以下に電話をしてください。 (408) 526-8216 メールしてください: tsiang@cisco.com
George Suwala Cisco Systems 170 W. Tasman Drive San Jose, CA 95134
ジョージ・Suwalaシスコシステムズ170w.タスマン・Driveサンノゼ、カリフォルニア 95134
Phone: (408) 525-8674 EMail: gsuwala@cisco.com
以下に電話をしてください。 (408) 525-8674 メールしてください: gsuwala@cisco.com
Tsiang & Suwala Informational [Page 51] RFC 2892 The Cisco SRP MAC Layer Protocol August 2000
Tsiang&Suwalaの情報[51ページ]のRFC2892コクチマスSRP MAC層のプロトコル2000年8月
16. Full Copyright Statement
16. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Tsiang & Suwala Informational [Page 52]
Tsiang&Suwala情報です。[52ページ]
一覧
スポンサーリンク
