[要約] RFC 2892は、Cisco SRP MAC Layer Protocolに関する仕様を提供しており、SRPネットワークでのデータリンク層の動作を定義しています。このRFCの目的は、SRPネットワークの効率的な運用と相互運用性の向上を促進することです。
Network Working Group D. Tsiang
Request for Comments: 2892 G. Suwala
Category: Informational Cisco Systems
August 2000
The Cisco SRP MAC Layer Protocol
Cisco SRP MACレイヤープロトコル
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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レイヤープロトコル「Spatial Reuse Protocol」（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プロトコル[1] [2]に見られるプロトコルまたはリングマスターネゴシエーション - リングを使用したノード間の公平性 - リングベースの冗長性（エラー検出、リングラップなど）のサポートと同様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、パケット形式、プロトコル形式、プロトコル操作、および関連するプロトコル有限状態マシンで使用される用語を定義します。
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
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
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.
- TTLビット数の11から8に減少します。
- Removal of the DS bit.
- DSビットの削除。
- 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-FAを変更して、使用フィールド幅を増やし、使用法を伝播するときに固定定数を追加する必要性を削除します。
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つの対称的な逆回転リングと見ることができます。プロトコル有限状態マシン（FSM）のほとんどは、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]のように、メディアやステーションの故障の場合にリングを巻き付けることができます。ラッピングは、インテリジェント保護スイッチング（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つは「内側」リングと呼ばれ、もう1つは「外側」リングと呼ばれます。SRPプロトコルは、データトラフィックを一方向（「下流」と呼ばれる）で送信することで動作し、反対のリングで対応する制御情報（「上流」と呼ばれる）です。図1は、これをグラフィカルに強調しています。
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 |<----------------
-----
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.
Spatial 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、ノード2へのノード3、ノード5にトラフィックを送信しています。リングから宛先ノードストリップユニキャストデータを使用すると、下流のリング上の他のノードを使用できます。リング帯域幅。この例では、これはノード5がノード6への完全な帯域幅アクセスを持っていることを意味し、他のトラフィックはリングの他の部分に同時に送信されます。
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つのタイプに分割できます。
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はすべての帯域幅を取得できるはずです。
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 |<---------------- .
----- .
^ .
. .
. . . . .<. . . . . . . . . . . .
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キューに配置できます。
FIGURE 3. Transit buffer
図3.トランジットバッファー
^^ ||
|| vv
|----| |----|
| | | |
|----|Rx |----|Tx
| |Buffer | |Buffer
|----| |----|
| | | |
|----| |----|
| | | |
|----| |----|
| | | |
|----| |----|
^^ Transit ||
|| Buffer ||
|| |------| vv
| H |
===========>|------|==========>
| L |
|------|
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.
宛先アドレス（DA）の一致が作成された場合、ノードを入力する受信パケットは、受信バッファーにコピーされます。DAマッチングされたパケットもユニキャストである場合、パケットは剥がれます。パケットが一致しない、またはマルチキャストでなく、パケットがアドレス（SA）の一致をセースにしない場合、パケットがライブと周期に時間が経過する場合、パケットはトランジットバッファー（TB）に次のノードに転送するために配置されます冗長チェック（CRC）テスト。
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バッファーを介してノードから発信されるデータを送信します。優先度の高い転送データが常に最初に送信されます。優先度の高い送信データは、優先度の低いトランジットバッファー（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.
一連の使用カウンターは、優先度の低い送信データと転送データが送信されるレートを監視します。使用法カウンターがSRP-FAルールによって支配されている許可された使用法を超えない限り、LPTBが低い優先度のしきい値を超えていない限り、低優先度データを送信できます。
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.
使用法は定期的に生成され、有効なデータリンクが存在することを上流のステーションに通知するキープライブとしても機能します。
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リングは、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はパスN4-> N5-> N6-> N1を介して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.
その後、図6に示すように、新しいリングトポロジが発見され、新しい最適パスがN4-> N3-> N2-N1が使用されます。トポロジの発見とその後の最適パス選択はIPSプロトコルの一部ではないことに注意してください。
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 |<----------------
-----
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シグナリングを介して制御されます。ソネットの機器と同じ速度でラッピングを実行するか、より速く実行することは目的です。
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）：メディア信号障害またはSRPの維持障害によって引き起こされる自動 - 要求されたスパンで保護スイッチを実行します
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 |<----------------
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. 信号分解（SD）：メディア信号の分解によって引き起こされる自動（例：過剰なビットエラー率） - 要求されたスパンで保護スイッチを実行します
4. Manual Switch (MS): operator originated, like Forced Switched but of a lower priority
4. マニュアルスイッチ（MS）：オペレーターは、強制スイッチのように発生しましたが、優先度が低い
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またはSD条件が消えた後、作業チャネルが修復基準を満たした後に自動化されます。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).
特定のスパンに対して保護（自動または演算子が発生する）が要求された場合、保護が要求されたノードは、両方の短いパスを使用してスパンの反対側のノードへの保護要求を発行します（故障したスパンで、障害は一方向である可能性があるため）と長い経路（リングの周り）。
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 |<----------------
-----
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.
保護要求がリングの周りを移動すると、保護階層が適用されます。要求された保護スイッチが最優先事項の場合信号障害要求は、この保護スイッチよりも信号分解よりも優先度が高く、必要に応じてリング内の他の場所での優先度の低いスイッチが削除されます。優先度の低い要求が要求されている場合、リングにより高い優先度リクエストが存在する場合は許可されません。唯一の例外は、リング内で共存できる複数の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).
すべての保護スイッチは双方向に実行されます（障害が単方向であっても、送信および受信方向の両方でスパンの両端でラップします）。
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 MTUに対応するように設計されています。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の場合、フレームの開始と終了を描写する追加のフラグがあります。
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 |
---------------------------------
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: CRC-32:
フレームチェックシーケンス（FCS）は、RFC-1662で指定されている32ビット環状冗長チェック（CRC）であり、SONET上のパケットで使用されるのと同じCRCです（RFC-2615で指定）。発電機多項式は次のとおりです。CRC-32：
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と同じであることに注意してください。
Each packet has a fixed-sized header. The packet header format is shown in Figure 8.
各パケットには固定サイズのヘッダーがあります。パケットヘッダー形式を図8に示します。
FIGURE 8. Detailed Packet Header Format
図8.詳細なパケットヘッダー形式
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 |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are described below.
フィールドを以下に説明します。
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 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.
この8ビットフィールドは、ノードがパケットを転送するたびに減少する必要があるホップカウントです。TTLがゼロに達すると、リングから剥がれます。これにより、リング上の256ノードの総ノードスペースが可能になります。ただし、特定の障害条件（例：リングが包まれている場合）のために、SRPによってサポートされるノードの総数は128です。リングのノード。
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
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レベルの優先度は、リングに送信する前に（送信キュー）、およびリングからの受信後（キューを受信）使用できます。
This three bit field is used to identify the mode of the packet. The following modes are defined in Table 2 below.
この3つのビットフィールドは、パケットのモードを識別するために使用されます。以下のモードを以下の表2に示します。
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予約001予約済み010予約済み011 ATMセル100コントロールメッセージ（ホストへのパス）101コントロールメッセージ（ホスト用にローカルバッファリング）110使用メッセージ111パケットデータ
These modes will be further explained in later sections.
これらのモードについては、後のセクションでさらに説明します。
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ビットにわたってパリティ値を示すために使用され、ヘッダーよりも追加のデータの整合性を提供します。奇数のパリティが使用されます（つまり、パリティビットを含むものの数は奇数数です）。
The destination address is a globally unique 48 bit address assigned by the IEEE.
宛先アドレスは、IEEEによって割り当てられたグローバルにユニークな48ビットアドレスです。
The source address is a globally unique 48 bit address assigned by the IEEE.
ソースアドレスは、IEEEによって割り当てられたグローバルにユニークな48ビットアドレスです。
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つのOctetフィールドです。SRPに関連する現在の定義値は、以下の表3に定義されています。
TABLE 3. Defined Protocol Types
表3.定義されたプロトコルタイプ
Value Protocol Type
値プロトコルタイプ
0x2007 SRP Control 0x0800 IP version 4 0x0806 ARP
0x2007 SRPコントロール0x0800 IPバージョン4 0x0806 ARP
SRP also supports the sending of ATM cells. The detailed cell format is shown below: FIGURE 9. SRP Cell Format
SRPは、ATMセルの送信もサポートしています。詳細なセル形式を以下に示します。図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 ) +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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層で処理されます。
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機能を実行します。SRP使用パケットは、約106 USECごとに送信する必要があります。
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.
受信インターフェイスがKeepAlive Timeoutインターバル内に使用パケットを見なかった場合、L2 KeepAlive Timeout割り込み/イベントをトリガーします。その後、IPSソフトウェアはそのインターフェイスを故障としてマークし、そのインターフェイスの周りに保護スイッチを開始します。KeepAlive Timeout間隔は、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A USAGE of all ones indicates a value of NULL.
すべての使用法は、nullの値を示します。
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.
モードビットが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種類のコントロールメッセージが定義されています。ホストへのパスとローカルバッファーです。ホストへのパスは、どんな手段でも便利なものでホストソフトウェアに渡すことができます。これはほとんどの場合、データパケットをホストに転送するために使用される同じパスです。通常、局所的にバッファリングされたコントロールメッセージは、保護メッセージのために予約されています。これらは通常、データパケットを使用してリソースを争わないためにローカルにバッファリングされます。これらのメッセージを処理する実際の方法は、実装者次第です。
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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).
コントロールパケットを送信するときは、優先度（PRI）値を0x7（すべて）に設定し、利用可能な最優先の送信キューにキューに掲載する必要があります。すべてのパケットが受信され、最も近い下流の隣人によって剥がされ、任意の価値に設定できるため、ライブの時間は関連性がありません（できれば001に設定する必要があります）。
This one octet field is the version number associated with the control type field. Initially, all control types will be version 0.
この1つのオクテットフィールドは、制御型フィールドに関連付けられたバージョン番号です。最初は、すべての制御タイプがバージョン0になります。
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
0x01トポロジの発見
0x02 IPS message
0x02 IPSメッセージ
0x03- 0xFF Reserved
0x03-0xff予約
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.
コントロール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.
コントロールメッセージのオリジネーターは、コントロールTTLの初期値を、通常データパケットに使用するSRP L2 TTLに設定する必要があります。
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ビットすべての単語すべての16ビットの補完の補完です。チェックサムに奇数のオクテットがある場合、最後のオクテットはゼロで右側にパッドで埋められて、チェックサムの目的で16ビットワードを形成します。パッドはセグメントの一部として送信されません。チェックサムの計算中、チェックサムフィールド自体はゼロに置き換えられます。これは、TCPに使用されているものと同じチェックサムアルゴリズムです。チェックサムは、32ビットSRP FCをカバーしていません。
The payload is a variable length field dependent on the control type.
ペイロードは、制御タイプに依存する可変長さフィールドです。
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).
すべてのノードには、グローバルに一意のIEEE 48ビットMACアドレスが必要です。マルチキャストビットは、標準的なアドレス指定規則を使用して定義されます。つまり、マルチキャストビットは、宛先アドレスの最も重要なオクテットの最も重要なビットです。ノードのMacアドレスを管理層2ドメイン内で一意であることが知られているものにノードのMacアドレスを変更することは許容されますが、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
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の場合、マルチキャストビットが最初に送信されます）。
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.
各ノードは、一方または両方のリングでトポロジディスカバリーパケットを送信することにより、トポロジの発見を実行します。トポロジーパケットを発信するノードは、脱出リングIDでパケットをマークし、ノードのMacバインディングをパケットに追加し、パケットを送信する前にパケットに長さフィールドを設定します。このパケットは、ノードからノードまでリングの周りにホップするポイントツーポイントパケットです。各ノードはMACアドレスバインディングを追加し、長さフィールドを更新し、リングの次のホップに送信します。リングにラップがある場合、ラップノードは、MACバインディングを追加するときにラップを示し、パケットをラップします。トポロジーパケットがラップセクションで移動すると、リング識別子がトポロジパケット自体とは異なる場合、MACアドレスバインディングはパケットに追加されません。
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).
最終的に、トポロジディスカバリーパケットを生成したノードがパケットを取り戻します。ノードは、パケットを除いて、パケットが同じイングレスと出口リングIDを確実に持っていることを確認します。トポロジマップは、同じ新しいトポロジーを示す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 |
+-+-+-+-+-+-+-+-+ +
| |
+ +
Note that the Source address should be set to the source address of the TRANSMITTING node (which is not necessarily the ORIGINATING node).
ソースアドレスは、送信ノードのソースアドレスに設定する必要があることに注意してください（必ずしも発信ノードではありません）。
This two octet field represents the length of the topology message in octets starting with the first MAC Type/MAC Address binding.
この2つのOctetフィールドは、最初のMACタイプ/MACアドレスバインディングから始まるオクテットのトポロジメッセージの長さを表します。
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アドレスは一意の識別子を使用して、トポロジパケットがリングの周りに出て消費されることを判断することを保証します。
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バインディングは、MACタイプフィールドに続いてノードの48ビットMACアドレスで構成されます。最初のMACバインディングは、オリジネーターのMACバインディングです。通常、OriginatorのMACアドレスはグローバルに一意の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ラップノード（1） /ラップノード（0）3-7予約
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が一致するかどうかの決定は、SRPヘッダーで見つかったRビットではなく、最後のMACバインディングのMACタイプフィールドに侵入リングIDとして見つかったリング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つの反転リングがあるため）。
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.
トポロジ発見メカニズムの実装は、定期的なアクティビティまたは「発見する必要性」に基づいている可能性があります。定期的な実装では、各ノードはトポロジーパケットを定期的に生成し、新しいトポロジマップを新しいものになるまで使用します。実装を発見する必要があるため、各ノードは、最初にリングに入ったり、ラップを検出したりするときに、必要なときにトポロジディスカバリーパケットを生成します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPS specific fields are detailed below.
IPS固有のフィールドを以下に詳しく説明します。
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アドレスです。ノードが単にIPSメッセージを伝播するだけであるため、SRPヘッダーソースアドレスと必ずしも同じではありません（例として「SRP IPSプロトコルルール」ルールP.8セクションを参照）。
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-強制スイッチ（FS）1011-信号失敗（SF）1000-信号分解（SD）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-保護スイッチ完了 - トラフィックラップ（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]で使用されているとおりです。
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またはライブフィールドを持つことです。各ノードがパケットを転送すると、TTLが減少します。TTLがゼロに達すると、リングから剥がれます。
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つのリングでパケットを受信し、もう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は常にすべてのストリップの予選として使用され、決定を受信する必要があります。
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および転送以外のパケットを処理しないでください。ノードがラップにある場合、ring_idを無視します。
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. モードがノードによってサポートされていない場合は、TTLおよび転送以外のパケットを処理しないでください（例：予約モード、またはパケットノードのATMセルモードなど）。
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. コントロールメッセージは、隣人間のポイントトゥポイントであり、常に受け入れられ、剥奪されるべきです。
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. ソースアドレスが受信ステーションのパケットであり、ring_idマッチを剥がす必要があります。ノードがラップである場合、ring_idを無視します。
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]
Notes: Host is responsible for discarding CRC errored packets. Conditionals (if statements) branch to the right if true and branch down if false.
注：ホストは、CRCエラーパケットの破棄を担当します。条件（声明の場合）は真の場合は右に分岐し、偽の場合は分岐します。
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-FAルールが許可されている限り、低優先度パケットは送信されます（my_usage <aotad_usage）。他に何も送信できない場合、低優先度のトランジットバッファーからの低い優先度パケットが送信されます。
This decision tree is shown in Figure 17.
この決定ツリーを図17に示します。
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]
Notes: Conditionals (if statements) branch to the right if true and branch down if false.
注：条件（IF Statementの場合）は、Trueの場合は右に分岐し、Falseの場合は分岐します。
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.
通常、送信されたデータは、同じリングで下流の隣人に送信されます。ただし、ノードがラップされた状態にある場合、送信されたデータは反対側のリングで上流の隣接に送信されます。
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-FAはリングへのアクセスを管理します。SRP-FAは、優先度の低いトラフィックにのみ適用されます。優先度の高いトラフィックは、SRP-FAルールに従わず、十分な輸送バッファースペースがある限り、いつでも送信される場合があります。
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-FAには、SRPリングに転送および調達されたトラフィックを制御する3つのカウンターが必要です。カウンターは、my_usage（リングに供給されたトラフィックの量を追跡）、forward_rate（ホスト以外のソースからリングに転送されるトラフィックの量）、およびavation_usage（そのノードの現在の最大送信使用量）です。
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.
うっ血がない場合、すべてのノードが蓄積していると、定期的に使用が許可されました。各ノードはmax_usageに送信できます。max_usageは、ノードが送信できる低優先度トラフィックの最大量を制限するよりもノードごとのパラメーターです。
When a node sees congestion it starts to advertise its my_usage which has been low pass filtered (lp_my_usage).
ノードが輻輳を見ると、ローパスフィルター（lp_my_usage）であるmy_usageを宣伝し始めます。
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_usage）を受信するノードは、許可された使用量を宣伝された値に設定します。ただし、RCVD_USAGEのソースが受信したのと同じノードである場合、RCVD_USAGEはヌル値として扱われます。RCVD_USAGEソースアドレスを比較する場合、有効な比較として認定するために、使用法パケットのリングIDが受信機のリングIDと一致する必要があります。例外は、受信ノードがラップ状態にある場合です。その場合、使用パケットのリング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_USAGEを受け取るノードは、一般に、上流の隣人にRCVD_USAGEを伝播します。例外は、地元の再利用の機会が検出されたときです。追加の空間再利用（ローカル再利用）は、転送レート（ローパスフィルタリング）をAlow_Usageと比較することにより実現されます。転送されたレートが許可された使用法よりも少ない場合、null値は上流の隣人に伝播されます。
Nodes that are congested propagate the smaller of lp_my_usage and rcvd_usage.
混雑したノードは、LP_MY_USAGEとRCVD_USAGEの小さいものを伝播します。
Convergence is dependent upon number of nodes and distance. Simulation has shown simulation convergence within 100 msec for rings of several hundred miles.
収束は、ノードの数と距離に依存します。シミュレーションでは、数百マイルのリングの100ミリ秒以内にシミュレーション収束が示されています。
A more precise definition of the fairness algorithm is shown below:
公平性アルゴリズムのより正確な定義を以下に示します。
Variables:
変数：
lo_tb_depth low priority transit buffer depth
lo_tb_depth低優先度トランジットバッファー深度
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
ホストによって送信されたオクテットのmy_usageカウントlp_my_usage my_usageローパスフィルターを介してrun hostが送信できることを示すフラグ
allow_usage the fair amount each node is allowed to transmit
low_usage各ノードが送信できる公正な量
fwd_rate count of octets forwarded from upstream lp_fwd_rate fwd_rate run through a low pass filter
上流のlp_fwd_rate fwd_rateから転送されたオクテットのfwd_rateカウントローパスフィルターを介して実行されます
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
rev_usage上流の隣人に渡された使用値
Constants:
定数：
MAX_ALLOWANCE = configurable value for max allowed usage for this node
max_allowance = maxの構成可能な値このノードの使用許可の使用
DECAY_INTERVAL = 8000 octet times @ OC-12, 32,000 octet times @ OC-48
AGECOEFF = 4 // Aging coeff for my_usage and fwd_rate
agecoeff = 4 // my_usageおよびfwd_rateの老化係数
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
NULL_RCVD_INFO = All 1's in rcvd_usage field
null_rcvd_info = rcvd_usageフィールドのすべての1
TB_LO_THRESHOLD // TB depth at which no more lo-prio host traffic // can be sent
TB_LO_THRESHOLD // TB深さは、これ以上lo-prioホストトラフィック//を送信できない深さ
MAX_LRATE = AGECOEFF * DECAY_INTERVAL = 128,000 for OC-48, 32000 for OC-12
max_lrate = agecoeff * decay_interval = 128,000 oc-48の場合は128,000、oc-12の場合は32000
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).
My_Usageは、ホストによって送信されるオクテットごとに1ずつ増加します（トランジットバッファーから送信されたデータは含まれません）。
fwd_rate is incremented by 1 for every octet that enters the Transit Buffer
FWD_RATEは、トランジットバッファーに入るオクテットごとに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;
UPDATED WHEN USAGE_PKT IS RECEIVED:
===================================
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;
THE FOLLOWING IS CALCULATED EVERY DECAY_INTERVAL:
==================================================
congested = (lo_tb_depth > TB_LO_THRESHOLD/2)
lp_my_usage = ((LP_MU-1) * lp_my_usage + my_usage) / LP_MU
my_usage is decremented by min(allow_usage/AGECOEFF, my_usage/AGECOEFF)
my_usageはminによって減少します（appro_usage/agecoeff、my_usage/agecoeff）
lp_fwd_rate = ((LP_FWD-1) * lp_fwd_rate + fwd_rate) / LP_FWD
fwd_rate is decremented by fwd_rate/AGECOEFF
FWD_RATEはFWD_RATE/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);
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;
if（rev_usage> max_lrate）rev_usage = null_rcvd_info;
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.4ミリ秒または320 kBにサイズになっています。TB_HI_THRESHOLDは、TB_LO_THRESHOLDよりも約870 USEC高く、OC12レートで458 kbに設定されています。
The high priority transit buffer needs to hold 2 to 3 MTUs or about 30KB.
優先度の高いトランジットバッファーは、2〜3 MTUまたは約30kbを保持する必要があります。
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.
各ノードは「フリーラン」モードで動作します。つまり、受信クロックは着信の受信ストリームから派生し、送信クロックはローカル発振器から派生します。これにより、既存のソネットネットワークで必要な高価な時計同期が必要になります。クロック周波数の違いは、各ノード出力に少量のアイドル帯域幅を挿入することで対応します。
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:
送信クロックのクロックソースは、中心周波数から20 ppm以内で逸脱するように選択するものとします。ノードの全体的な発信速度は、隣接するノードの受信クロックと送信クロックの間の最悪の違いに対応するために、速度形成されなければなりません。これは次のように機能します。
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から挿入されたオクテットの量を除去して送信されるオクテットの量を追跡し、正の整数です。
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.
token_bucketカウンターはレートの形成を実装し、署名された整数です。このカウンターは、各サンプル期間と呼ばれる2つの固定値のいずれかで増加します。Quantum1は、レートを（line_rate -delta）に設定します。ここで、デルタは私たちが収容したい時計の不正確さです。
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は、（line_rate delta）でレートを設定します。サンプル期間の開始時にTB_CNT> = sync_thresholdの場合、Quantum2にレートを設定します。これにより、追いつくことができ、結核カウントが最終的に<sync_thresholdになります。tb_cntが<sync_thresholdである場合、レートを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.
入力レートと出力率が正確に等しい場合、TB_CNTはsync_threshold> tb_cnt> = 0によって異なります。これは、デザインのバーストレイテンシに依存する各実装に対して異なります。sync_threshold値は、等しい送信および受信クロックレートの場合、送信データレートは常にline_rate-deltaであり、実装に依存するように設定する必要があります。
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).
Token_Bucketは、データが送信されるたびに減少します。token_bucketが値<= 0に達すると、HALT_TRANSMITフラグが主張され、データのさらなる送信が停止します（もちろん、Packet境界で停止が発生し、token_bucketが負の数になります）。
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.
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).
600 MbpsのOC12C SPEレートと800 Mbpsのシステムクロックレート（16ビット @ 50 MHz）の場合。システムクロックレートは、システムがフレーマーにバイトを送信するレートです（ほとんどの場合、フレイマー送信速度は、システムがデータをフレーマーに転送するレートから非同期です）。
Quantum1/Interval * 800 Mbps = 600 Mbps(1 - Delta)
Quantum1 = Interval * (600/800) * (1 - Delta)
Quantum1 = Interval * (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
Note: The actual data rate for OC-12c is 599.04 Mbps.
注：OC-12Cの実際のデータレートは599.04 Mbpsです。
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オクテット形式：
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-強制スイッチ（FS）1011-信号失敗（SF）1000-信号分解（SD）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-保護スイッチ完了 - トラフィックラップ（w）000-アイドル（i）
The IPS control messages are shown in this document as:
IPSコントロールメッセージは、このドキュメントに次のように表示されます。
{REQUEST_TYPE, SOURCE_ADDRESS, WRAP_STATUS, PATH_INDICATOR}
{request_type、source_address、wrap_status、path_indicator}
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の例は、信号の損失（LOS）、フレームの損失（LOF）、事前に選択されたSFしきい値を超えるラインビットエラー率（BER）、ラインアラーム表示信号（AIS）です。SRP Keep-Alive障害はエンドツーエンドのカバレッジを提供し、その結果、ソネットパストリガーは必要ないことに注意してください。
3. Signal Degrade (SD - automatic)
3. 信号分解（SD-自動）
Protection caused by a media "soft failure". SONET example of a SD is Line BER or Path BER above a preselected SD threshold.
メディアの「ソフト障害」によって引き起こされる保護。SDのSONETの例は、事前に選択されたSDしきい値の上のラインBERまたはパス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.
作業チャネルがSDまたはSF条件がなくなった後、回復のしきい値を満たした後に入力されます。IPは、保護スイッチの振動を防ぐためにトラフィックを復元する前にWTRタイムアウトを待っています。
Each node in the IPS protocol is in one of the following states for each of the rings:
IPSプロトコルの各ノードは、各リングの次の状態のいずれかにあります。
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}
このモードでは、ノードは保護スイッチを実行する準備ができており、ソースアドレスフィールドに「自己」を含む隣接ノード「アイドル」メッセージの両方に送信します{idle、self、i、s}
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メッセージに基づいて入力されます。Noll Requestの長いパスメッセージが受信され、ノードがメッセージを削除しない場合（ストリッピング条件のプロトコルルールを参照）、ノードはTTLを減少させ、変更なしでメッセージを再送信します。アイドルメッセージの送信は、nullリクエストのないメッセージが転送される方向に停止されます。
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メッセージに基づいて発行された保護要求に基づいて入力されます。
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倍に自動的に減少することが望ましい（必須ではありません）。
R S.1:
R S.1：
IPS signaling is performed using IPS control packets as defined in Figure 14 "IPS Packet Format".
IPSシグナル伝達は、図14 "IPSパケット形式"で定義されている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.
ローカルリクエストを実行することも、短いパス要求の実行も、リングのノードを通過する長いパスメッセージがない場合、リング上の近隣のメッセージにアイドルメッセージを実行しないノード。
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) 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では、ノードAはノードAとノードの間のスパンでSF（ローカルリクエスト/自己検出要求）を検出しますbと外側のリングで{sf、a、w、s}、内側のリングで{sf、a、w、l}の調達を開始します。ノードBは、ノードA（短いパスリクエスト）から保護要求を受信し、内側のリングで{idle、b、w、s}、および{sf、b、w、l}で{idle、b、w、s}を開始します。
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
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.
保護リクエスト階層は次のとおりです（最優先度よりも最優先事項）。一般に、優先度の高い要求は、ルールとして記載されている例外を除き、リング内のより低い優先度要求を先取りします。以下の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-強制スイッチ（FS）1011-信号失敗（SF）1000-信号分解（SD）0110-マニュアルスイッチ（MS）0101-復元を待つ（WTR）0000-リクエストなし（アイドル）：最低優先度
R P.2:
R p.2：
Requests >= SF can coexist.
リクエスト> = SFは共存できます。
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).
ノードは、元々ノード自体によって生成されたIPSパケットを転送することはありません（ノードのソースアドレスがあります）。
R P.7:
R P.7：
Nodes never forward packets with the PATH_INDICATOR set to SHORT.
ノードは、path_indicatorが短く設定されているパケットを決して転送しません。
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.
ノードが長いパス要求を受信し、リクエストが> = {short path request、self extected request}の最高の場合、ノードはメッセージをチェックして、メッセージが短いパスで隣人から来ているかどうかを判断します。その場合、パススルーに入ることなく、メッセージをストリップします。
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メッセージから収集されます）。
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時間期間）に入ります。WTRは、デフォルト値が60秒で、10-600秒の範囲で構成できます。
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.
ノードが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モードで、長いパス要求ソースが反対側のネイバー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).
ノードがタイプSDまたは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)
1つのスパンに2つの障害と結果のWTR条件が2つある場合、2番目のWTRがタイムアウトすると両方のラップダウンが表示されます（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/SD条件が同じ側で行われる場合、FSを無視するSF/SD条件を受け入れて処理します。このルールがなければ、単一の終了ラップ条件が発生する可能性があります。（スパンのみの一端にのみ包みます）。
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}
Legend: Mate = node on the other end of the affected span
REQ = {FS | SF | SD | MS}
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.
B.リングで検出された繊維上の単方向の故障を備えた4つのノードA、B、C、およびDのリングのサンプルシナリオは、故障前にアイドル状態（すべてのノードはアイドル状態です）にあります。
Signal Fail Scenario
信号障害シナリオ
1. Ring in Idle, all nodes transmit (Tx) {IDLE, SELF, I, S} on both rings (in both directions)
1. アイドル状態でリング、すべてのノードが送信されます（TX）{Idle、self、i、s}の両方のリング（両方の方向）
FIGURE 21. An SRP Ring with outer ring fiber cut
図21.外側のリングファイバーカット付きのSRPリング
fiber cut
---------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を検出し、内側のリング/ショートパス：{sf、b、w、s}と外側のリング/ロングパス：tx {sfに向かって、ラップ状態（ラップを実行）、テキサスに遷移します。、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は、短いパスで保護要求を受信し、ラップ状態、テキサス州、短いパスでBに移行します。sf、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がスイッチリクエストを受信すると、パススルーモード（各方向）に入ります。
5. Steady state is reached
5. 定常状態に到達します
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. b on b clearss、bはwrapを解き、wtrタイマー、tx {wtr、b、w、s}を内側とtx {wtr、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}（障害のためにメッセージは通過しません）および長いパスで：TX {WTR、a、w、l}
3. Nodes C and D relay long path messages without changing the IPS octet
3. ノードCおよびDリレーIPSオクテットを変更せずに長いパスメッセージ
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. B. Bの時間は、内側と外側の両方のリングでアイドル状態（Unwraps）tx {idle、b、i、s}に移行します
6. A receives Rx {IDLE, B, I, S} and transitions to Idle
6. aはrx {idle、b、i、s}を受け取り、アイドルに移行します
7. As idle messages reach C and D the nodes enter the idle state (start sourcing the Idle messages)
7. アイドルメッセージがCおよびDに到達すると、ノードはアイドル状態に入ります（アイドルメッセージの調達を開始）
8. Steady state it reached
8. それが達した安定した状態
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の間の双方向の故障がある4つのノードA、B、C、Dのリングのサンプルシナリオは、障害前にアイドル状態（すべてのノードがアイドル状態です）にあります。
Signal Fail Scenario
信号障害シナリオ
1. Ring in Idle, all nodes transmit (Tx) {IDLE, SELF, I, S} on both rings (in both directions)
1. アイドル状態でリング、すべてのノードが送信されます（TX）{Idle、self、i、s}の両方のリング（両方の方向）
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を検出し、内側のリング/ショートパスでBに向かってラップ状態（ラップを実行する）に移行します：{sf、a、w、s}および外側のリング/長いパス：tx {sf {sf、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を検出し、内側のリング/ショートパス：{sf、b、w、s}と外側のリング/ロングパス：tx {sfに向かって、ラップ状態（ラップを実行）、テキサスに遷移します。、b、w、l}
FIGURE 22. An SRP Ring with bidirectional fiber cut
図22.双方向繊維カットを備えたSRPリング
fiber cut
---------X-----------------------------
| -------X--------------------------- |
| | fiber cut | |
| 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がスイッチリクエストを受信すると、パススルーモード（各方向）に入ります。
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. sf on a clears、aはwrapを解き、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はwrapを解きません。現在、このリクエストに応じて機能する短いパスWTRリクエストが表示されているためです。ラップ、テキサス{アイドル、b、w、s}をaとtx {wtr、b、w、l}に向けて長い経路に保ちます
3. Nodes C and D relay long path messages without changing the IPS octet
3. ノードCおよびDリレーIPSオクテットを変更せずに長いパスメッセージ
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でのWTRタイムズアウトAはアイドル状態（ドロップラップ）に入り、両方のリングでアイドルの送信を開始します
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. 定常状態に到達します
FIGURE 23. An SRP Ring with a failed node
図23.障害のあるノードを備えたSRPリング
---------------------------------------
| ----------------------------------- |
| | | |
| v | v /
----- ----/
| A | | C/| failed
| | | / | node 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が失敗するリングのシナリオのサンプル。リングは、障害前にアイドル状態（すべてのノードがアイドル状態です）にあります。
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. アイドル状態でリング、すべてのノードが送信されます（TX）{Idle、self、i、s}の両方のリング（両方の方向）
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を検出し、内側のリング/ショートパスでcに向かってラップ状態（ラップを実行）に移行します：{sf、b、w、s}および外側のリング/長いパス：tx {sf {sf、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を検出し、外側のリング/ショートパスでcに向かってラップ状態（ラップを実行）に移行します：{sf、a、w、s}および内側のリング/長いパス：tx {sf {sf、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リクエストを受信すると、パススルーモード（各方向）に入り、アイドルメッセージの調達を停止し、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からアイドルメッセージを受信します。長いパス保護要求{SF、B、W、L}が長いスパンで受信しているため、短いパスネイバー（c）から発信されないため、ノードAはWTRをドロップし、パススルーに入ります。CとBの間の状態通過要求
5. Steady state is reached
5. 定常状態に到達します
Second Span Returns to Service
2番目のスパンがサービスに戻ります
The scenario is like the Bidirectional Fiber Cut fault clearing scenario.
このシナリオは、双方向繊維カット障害クリアリングシナリオのようなものです。
FIGURE 24. An SRP Ring with a failed node
図24.障害のあるノードを備えたSRPリング
wrap
----->|--------------------------------
| -<--|------------------------------ |
| | | |
| v | v
----- ----
| A | | C | Added
| | | | node
----- -----
^ | ^ |
o | | i | |
u | | n | |
t | | n | |
e | | e --- wrap
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. アイドル状態でリング、すべてのノードが送信されます（TX）{Idle、self、i、s}の両方のリング（両方の方向）
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を検出し、内側のリング/ショートパス：{sf、b、w、s}と外側のリング/ロングパス：tx {sfに向かって、ラップ状態（ラップを実行）、テキサスに遷移します。、b、w、l}
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を検出し、内側のリング/ショートパスでラップ状態（ラップを実行する）、テキサス州にBに向かって遷移します：{SF、A、W、S}および外側のリング/ロングパス：TX {sf、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リクエストを受信すると、パススルーモード（各方向）に入り、アイドルメッセージの調達を停止し、A B間のメッセージの渡しを開始します。
6. Steady state is reached
6. 定常状態に到達します
Node C is Powered Up and Fibers Between Nodes A and C are Reconnected
ノードCは電源を伸ばし、ノードAとCの間の繊維が再接続されています
This scenario is identical to the returning a Failed Node to Service scenario.
このシナリオは、故障したノードを返すためにシナリオを返すことと同じです。
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が接続されています。シナリオは、双方向の繊維カット障害クリアリングシナリオと同じです。
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はメディア独立ですが、レイヤー1メディアタイプでSRPがどのように使用されるかに注目する価値があります。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).
SONET/SDHフレーミングプラスPOSパケットデリミングにより、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 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.
SRPは、SONET/SDH ADM（追加マルチプレクサーを追加）への支流接続を介して、SONET/SDHリングネットワークに接続することもできます。2つのSRPリングは、2つのSTS-NC接続にマッピングできます。SONET/SDHネットワークは通常、完全に冗長な接続を提供するため、2つのSTS-NC接続にマッピングされたSRPには2つのレベルの保護があります。SONET/SDHネットワークはレイヤー1保護を提供し、SRPはレイヤー2保護を提供します。この場合、SRP信号失敗IPSトリガー（SONET/SDHが保護できる障害に対応する）を約100ミリ秒間保護するために、SONET/SDHネットワークを保護できるようにすることをお勧めします。IPS保護が行われる必要がある場合、100ミリ秒以上（SONET/SDH保護障害を示す）の場合の障害が続く場合のみ。
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光ネットワークを介して行われた接続は、内部タイミングを利用する必要があります。
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.
ノードは、オペレーターコマンドのため、またはソフトウェアクラッシュなどのエラー条件により、パススルーモードに入ることができます。
[1] ANSI X3T9 FDDI Specification
[1] ANSI X3T9 FDDI仕様
[2] IEEE 802.5 Token Ring Specification
[2] IEEE 802.5トークンリング仕様
[3] Bellcore GR-1230, Issue 4, Dec. 1998, "SONET Bidirectional Line-Switched Ring Equipment Generic Criteria".
[3] Bellcore GR-1230、第4号、1998年12月、「SONET双方向ラインスイッチ付きリング機器汎用基準」。
[4] ANSI T1.105.01-1998 "Synchronous Optical Network (SONET) Automatic Protection Switching"
[4] ANSI T1.105.01-1998「同期光ネットワーク（SONET）自動保護スイッチング」
[5] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[5] Malis、A。and W. Simpson、「PPP Over Sonet/SDH」、RFC 2615、1999年6月。
[6] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[6] シンプソン、W。、「HDLCのようなフレーミングのPPP」、STD 51、RFC 1662、1994年7月。
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.
共有メディアと同様に、そのノードが誤って構成されているか、悪意を持って構成されている場合、そのノードをトラバースするパケットがそのノードで使用可能です。さらに、ノードは、別のノードを対象としたパケットを検査するだけでなく、目的のノードが空間的再利用を取得するために使用される宛先除去スキームのためにパケットを受信するのを防ぐこともできます。トポロジの発見を使用して、重複するMACアドレスを検出する必要があります。
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は、このドキュメントに含まれる仕様の一部またはすべてに関して請求された知的財産権について通知されています。詳細については、請求権のオンラインリストを参照してください。
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-FAのオリジナルバージョンを思いついたホンワチンに感謝します。著者に加えて、SRPの元の想起には、ホンワチン、グレームフレイザー、トニーベイツ、ブルースウィルフォード、フェイサルダルワラ、ロバートブロバーグが含まれます。
Comments should be sent to the authors at the following addresses:
コメントは、次のアドレスで著者に送信する必要があります。
David Tsiang Cisco Systems 170 W. Tasman Drive San Jose, CA 95134
David Tsiang Cisco Systems 170 W. Tasman Drive San Jose、CA 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
George Suwala Cisco Systems 170 W. Tasman Drive San Jose、CA 95134
Phone: (408) 525-8674 EMail: gsuwala@cisco.com
電話：（408）525-8674メール：gsuwala@cisco.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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エディター機能の資金は現在、インターネット協会によって提供されています。