Network Working Group D. Tsiang
Request for Comments: 2892 G. Suwala
Category: Informational Cisco Systems
August 2000
The Cisco SRP MAC Layer Protocol
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.
著作権（C）インターネット協会（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層プロトコル、「空間再利用プロトコル」（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は、以前に発表されたドラフト仕様でした。以下のリストはV1からV2の機能の違い：
- 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.
- キープアライブ機能を提供することに加えて使用情報を搬送する新たな制御パケットでキープアライブパケットの交換。
- Change bit value of inner ring to be 1 and outer to be 0.
- 内輪の変更ビット値は1であり、かつ外側0であること。
- Reduction in the number of TTL bits from 11 to 8.
- 11から8までTTLビットの数の減少。
- Removal of the DS bit.
- DSビットの除去。
- 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）のほとんどは、二つのリングのために複製されます。
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.
双方向リング[3] [1]またはSONET / SDH FDDIのように、メディア又はステーションに障害が発生した場合のリングラッピングを可能にします。ラッピングは、インテリジェント保護スイッチング（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.
二つのリングを区別するために、一方を「内側」リングなど、他の「外側」環と呼ばれます。 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.
空間再利用は、リングの全体的な総帯域幅を増やすためにリングに使用される概念です。ユニキャストトラフィックは唯一の環は、送信元ノードと宛先ノードではなく、そのようなトークンリングおよびFDDI等の以前のリングベースのプロトコルのように全体のリングとの間にまたがって渡されるので、これは可能です。
Figure 2 below outlines how spatial reuse works. In this example, node 1 is sending traffic to node 4, node 2 to node 3 and node 5 to node 6. Having the destination node strip unicast data from the ring allows other nodes on the ring who are downstream to have full access to the ring bandwidth. In the example given this means node 5 has full bandwidth access to node 6 while other traffic is being simultaneously transmitted on other parts of the ring.
以下の図2は、再利用がどのように機能するか、空間の概要について説明します。この例では、ノード1が4ノードにトラフィックを送信し、ノード3、ノード2、ノード5、ノード6に宛先ノードストリップを有するリングからユニキャストデータは、下流にあるリング上の他のノードがへのフルアクセスを持つことができリング帯域幅。与えられた例では、これは、他のトラフィックを同時にリングの他の部分に送信されている間に、ノード5はノード6への完全な帯域幅へのアクセスを有することを意味します。
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.
両方のグローバルとローカルアクセスが必要とされる場合の例として、グローバル割り当てに基づいて、帯域幅の1/2を取得する2ノード1、図2、及び図5を再度参照します。しかし、地元の視点から、ノード5は、その帯域幅は、ノード1と2の公正なシェアを妨げることはありませんので、すべての帯域幅を得ることができる必要があります。
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マッチしたパケットは、ユニキャストである場合、パケットは削除されます。パケットは、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のデータを転送し、または送信バッファを介してノードから発信データが送信されますか。優先度の高い転送されたデータは、常に最初に送信されます。優先度の高い送信データがあれば、優先度低トランジット・バッファ（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は外輪に内輪をラップします。ラップが設定された後、N1へのN4からのトラフィックは、最初は非最適パス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.
その後、新しいリングトポロジが発見され、トポロジ発見およびその後の最適経路選択はIPSプロトコルの一部ではないことを図6注意に示すように、新たな最適経路は、N4-> N3-> N2-N1に使用されます。
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.
リングラップ[3] [4]スタイルIPSシグナリングSONET BLSRを介して制御されます。 SONET機器や速いほど速いラップを実行するための目的です。
The IPS protocol processes the following request types (in the order of priority, from highest to lowest):
IPSプロトコルは、（最高から最低まで、優先度の順に）次の要求タイプを処理します。
1. Forced Switch (FS): operator originated, performs a protection switch on a requested span (wraps at both ends of the span)
1.強制スイッチ（FS）：オペレータは、発信が要求されたスパンの保護切り替えを行う（スパンの両端ラップ）
2. Signal Fail (SF): automatic, caused by a media Signal Failure or SRP keep-alive failure - performs a protection switch on a requested span
2.信号障害（SF）：自動、メディア信号障害や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
前記手動スイッチ（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).
保護は、（自動またはオペレータが発信）指定されたスパンのために要求された場合、ノードは、どの保護が問題に失敗したスパンで短いパスの両方を使用して、スパンの他端のノードへの保護要求を（要求されました、一方向であってもよい故障）とリングの周りに長いパス（AS）。
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:
フレームチェックシーケンス（FCS）は、パケットオーバーSONET（ - RFC-2615で指定されたPOS）で用いたのと同じCRCをRFC-1662で指定されているように、32ビット巡回冗長検査（CRC）です。生成多項式は次のようになります。
CRC-32:
CRC-32：
x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 + X8 + X7 + X5 + X4 + X2 + X + 1
The FCS is computed over the destination address, source address, protocol type and payload. It does not include the SRP header.
FCSは、宛先アドレス、ソースアドレス、プロトコルタイプ、およびペイロードにわたって計算されます。これは、SRPヘッダーが含まれていません。
Note that the packet format after the SRP header is identical to Ethernet Version 2.
SRPヘッダ後のパケットフォーマットがイーサネットバージョン2と同じであることに留意されたいです。
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によってサポートされているノードの合計数は、パケットが最初の総数の少なくとも二倍TTLをに設定する必要がリングに送信されると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. MODE値
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.
プロトコルタイプは、イーサタイプ表現で使用されるような2つのオクテットフィールドです。 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:
SRPはまた、ATMセルの送信をサポートしています。詳細なセルフォーマットを以下に示します。
FIGURE 9. SRP Cell Format
図9. SRPセルフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |R| MOD | PRI |P| VPI/VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCI | PTI |C| HEC | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. ATM Payload .
. ( 48 Bytes ) +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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用法パケットもキープアライブ機能を実行します。 SRP用法パケットは、およそすべての106マイクロ秒を送信する必要があります。
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.
受信インタフェースは、キープアライブタイムアウト間隔内の利用パケットを見ていない場合には、L2キープアライブタイムアウト割り込み/イベントをトリガします。 IPSソフトウェアは、その後、故障してそのインターフェイスをマークし、そのインターフェイスの周りに保護スイッチを開始します。キープアライブタイムアウト間隔は16倍SRP用法パケット送信間隔に設定されるべきです。
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.
MODEビットが10X（SRP制御）に設定されている場合、これは、制御メッセージを示しています。制御メッセージは、常に隣接ノードによって受信され、削除されます。彼らは、定義ユニキャストであり、そして任意のアドレス情報を必要としません。制御パケットの宛先アドレスフィールドが0のに設定する必要があります。制御パケットのソースアドレスフィールドは、送信ノードの送信元アドレスに設定されるべきです。
Two types of controls messages are defined : Pass to host and Locally buffered. Pass to host messages can be passed to the host software by whatever means is convenient. This is most often the same path used to transfer data packets to the host. Locally buffered control messages are usually reserved for protection messages. These are normally buffered locally in order to not contend for resources with data packets. The actual method of handling these messages is up to the implementor.
コントロールメッセージの二つのタイプが定義されています。ホストとローカルバッファリングに渡します。便利なあらゆる手段により、ホストソフトウェアに渡すことができるメッセージをホストに渡します。これは、ほとんどの場合、ホストにデータパケットを転送するために使用されるのと同じパスです。ローカルバッファリング制御メッセージは、通常、保護メッセージのために予約されています。これらは、通常のデータパケットとリソースを競合しないために、ローカルにバッファリングされています。これらのメッセージを処理する実際の方法は、実装次第です。
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）値は（すべて1の）制御パケットを送信し、利用可能な最も優先度の高い送信キューにキューイングされなければならないときを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
0xFFで予約0x03-
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は、ノードが制御パケットを転送するたびにデクリメント（-1）されなければならない制御層のホップ数です。ノードは、制御TTL <= 1の制御パケットを受信した場合、それはパケットを受け入れ、それを転送してはなりません。
Note that the control layer hop count is separate from the SRP L2 TTL which is always set to 1 for control messages.
制御層ホップカウントは常に、制御メッセージのために1に設定されているSRP L2 TTLから分離されていることに留意されたいです。
The originator of the control message should set the initial value of the control TTL to the SRP L2 TTL normally used for data packets.
制御メッセージの発信者は、通常、データパケットのために使用SRP L2 TTLに制御TTLの初期値を設定しなければなりません。
The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words starting with the control version. If there are an odd number of octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros. This is the same checksum algorithm as that used for TCP. The checksum does not cover the 32 bit SRP FCS.
チェックサムフィールドは、コントロールのバージョンで始まるすべての16ビットワードの1の補数の和の16ビットの1の補数です。チェックサムされるべきオクテットの奇数がある場合、最後のオクテットは、チェックサムの目的のために16ビット・ワードを形成するためにゼロで右側に埋め込まれます。パッドは、セグメントの一部として送信されていません。チェックサムを計算しながら、チェックサムフィールド自体がゼロで置き換えられます。これは、TCPのために使用したものと同じチェックサムアルゴリズムです。チェックサムは32ビットSRP FCSをカバーしていません。
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アドレスを持っている必要があります。マルチキャストビットは、即ち、マルチキャストビットは、宛先アドレスで最も重要なオクテットの最下位ビットであり、正規のアドレス指定規則を使用して定義されます。それは許容されるが、管理レイヤ2ドメイン（すなわち、レイヤ2透明ブリッジを介しSRPリングに接続された任意のネットワークとともにSRPリング自体である）内で一意であることが知られているいずれかのノードのMACアドレスを変更することをお勧めではありません。
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.
各ノードは、1個のまたは両方の環上のトポロジディスカバリパケットを送信することによって、トポロジディスカバリを行います。トポロジパケットを発信するノードは、egressingリング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.
この二オクテットフィールドは、最初の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アドレスが、そのノードは、（IEEEによって割り当てられた）グローバルに固有のMACアドレスですであればノードによって発信されていると判断されます。
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バインディングは、ノードの48ビットMACアドレスに続くMAC Typeフィールドで構成されなければなりません。最初のMACはMACが発信元の結合されなければならない結合。通常、発信者の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の一致が入力リングIDなくSRPヘッダに見出さRビットとして結合最後のMACのMAC Typeフィールドで見つかったリング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 IPSプロトコルルール」ルールP.8を参照）は、必ずしもSRPヘッダソースアドレスと同じではありません。
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)
4 Path indicator
4パスのインジケータ
0 - short (S)
1 - long (L)
5-7 Status Code
5-7ステータスコード
010 - Protection Switch Completed - traffic Wrapped (W)
000 - Idle (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.
この問題を解決するには、リング内のノードの少なくとも二倍の数に設定されている各パケット内のフィールドを生きて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つのリング上のパケットを受信すると、他のリング上でそれを送信することです。ストリッピング及び受信の決定を行うときしたがって、ラップ状態にあるノードは、リング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.
彼らは、ノードがラップしている場合を除き、それらが受信される方向について、「間違った」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.
CRCエラーが発生した場合ので、宛先アドレスのホストによって受け入れ5.パケットは、上位レベルで廃棄されるべきです。
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.
そのソースアドレス、受信局のことであり、そのring_idマッチ剥離しなければならない7.パケット。ノードがラップしている場合は、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エラーが発生したパケットを廃棄する責任があります。条件文（if文）falseの場合、真とダウン分岐場合は右に分岐します。
A node can transmit four types of packets:
ノードは、パケットの四種類を送信することができます。
1. High priority packets from the high priority transit buffer.
高優先度の転送バッファから1の高優先度パケット。
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 <allowed_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文）右への分岐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（ホスト以外のソースからリングへ転送されたトラフィックの量）とallowed_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).
ノードが輻輳を見たとき、それは、低域フィルタリングされたそのmy_usage（lp_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を受ける彼らの上流の他の隣人に伝播し、使用のNULL値をrcvd_usageを伝播されていないノード（すべて1）。地元の再利用の機会が検出された場合は例外です。追加の空間再利用（ローカルリユース）はallow_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_okフラグを介してホストlp_my_usageのmy_usage実行によって送信されるオクテットのmy_usageカウントが送信を許可されています
allow_usage the fair amount each node is allowed to transmit
各ノードが送信することを許可されているかなりの量をallow_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
DECAY_INTERVAL = OC-12 @ 8000オクテット回、32,000オクテット回OC-48 @
AGECOEFF = 4 // Aging coeff for my_usage and fwd_rate
my_usageとfwd_rateためAGECOEFF = 4 //エイジングCOEFF
LP_FWD = 64 // Low pass filter for fwd_rate LP_MU = 512 // Low pass filter for my usage LP_ALLOW = 64 // Low pass filter for allow usage auto increment
私の使用状況LP_ALLOWためfwd_rate LP_MU = 512 //ローパスフィルタ許可の使用自動インクリメントのために= 64 //ローパスフィルタ用LP_FWD = 64 //ローパスフィルタ
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
//を送信できるこれ以上のLO-PRIOホストトラフィックでTB_LO_THRESHOLD // TBの深さ
MAX_LRATE = AGECOEFF * DECAY_INTERVAL = 128,000 for OC-48, 32000 for OC-12
MAX_LRATE = AGECOEFF * DECAY_INTERVAL OC-12、OC-48、32000ため= 128,000
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;
もし（（my_usage <！allow_usage）&&（（lo_tb_depth> 0）&&（fwd_rate <my_usage））&&（my_usage <MAX_ALLOWANCE））//真は、ホストパケットを送信するためにOKを意味=真my_usage_ok。
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)
輻輳=（lo_tb_depth> TB_LO_THRESHOLD / 2）
lp_my_usage = ((LP_MU-1) * lp_my_usage + my_usage) / LP_MU
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を分だけデクリメントされる（allow_usage / AGECOEFF、my_usage / AGECOEFF）
lp_fwd_rate = ((LP_FWD-1) * lp_fwd_rate + fwd_rate) / LP_FWD
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キロバイトに寸法決めされています。 TB_HI_THRESHOLDはTB_LO_THRESHOLDよりまたはOC12レートで458キロバイトの高い870マイクロ秒に設定されています。
The high priority transit buffer needs to hold 2 to 3 MTUs or about 30KB.
高優先度の転送バッファは、3つのMTUまたは30キロバイト約2を保持する必要があります。
Each node operates in "free-run" mode. That is, the receive clock is derived from the incoming receive stream while the transmit clock is derived from a local oscillator. This eliminates the need for expensive clock synchronization as required in existing SONET networks. Differences in clock frequency are accommodated by inserting a small amount of idle bandwidth at each nodes output.
各ノードは、「フリーラン」モードで動作します。送信クロックを局部発振器から導出されている間すなわち、受信クロックは、着信受信ストリームから導出されます。これは、既存のSONETネットワークで必要とされる高価なクロック同期が不要になります。クロック周波数の差は、各ノードの出力における空き帯域の少量を挿入して収容されています。
The clock source for the transmit clock shall be selected to deviate by no more than 20 ppm from the center frequency. The overall outgoing rate of the node shall be rate shaped to accommodate the worst case difference between receive and transmit clocks of adjacent nodes. This works as follows:
送信クロックのクロック・ソースは、中心周波数からこれ以上20ppm以下によりずれるように選択されなければなりません。ノードの全体的な送信レートは、隣接ノードの受信および送信クロックとの間の最悪の場合の差に対応するように成形速度でなければなりません。これは次のように動作します：
A transit buffer slip count (tb_cnt) keeps track of the amount of octets inserted into the TB minus the amount of octets transmitted and is a positive integer.
トランジット・バッファ・スリップ・カウント（tb_cnt）はTBマイナス送信されたオクテットの量に挿入されたオクテットの量を追跡し、正の整数です。
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）速度を設定します。
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 +デルタ）速度を設定します。サンプル期間、tb_cnt> = sync_thresholdの先頭であれば、我々はQuantum2にレートを設定しました。これは、私たちは追いつくことができ、最終的にsync_threshold <どこへ行くTBスリップ・カウントが発生します。 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デルタで、実装依存となります。
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フラグはデータのさらなる送信を（停止が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.
2 ^^ 18または262144クロックサイクルの間隔をとります。 Quantum1値は、データレートは=（ - DELTA LINE_RATE）することを採取しなければなりません。 tb_cnt着信レートが送信レートより大きく、=（LINE_RATE + DELTA）であることを示す場合Quantum2値を採取し、使用しなければなりません。着信および発信レートクロックのソースは+/- 100ppmであると仮定する。
For an OC12c SPE rate of 600 Mbps and a system clock rate of 800 Mbps (16 bits @ 50 Mhz). The system clock rate is the rate at which the system transmits bytes to the framer (in most cases the framer transmit rate is asynchronous from the rate at which the system transfers data to the framer).
600 MbpsでのOC12C SPEレート800 Mbpsの（50 MHzの@ 16ビット）のシステム・クロック・レートのために。システム・クロック・レートは、システムが（ほとんどの場合、フレーマ送信レートがシステムにデータを転送するレートからフレーマに非同期である）フレーマにバイトを送信する速度です。
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
Quantum2 /インターバル* 800 Mbpsの= 600 Mbpsの（1 +デルタ）Quantum2 =インターバル*（600/800）*（1 +デルタ）Quantum2 =インターバル*（600/800）*（1 + 1E-4）= 196628
Note: The actual data rate for OC-12c is 599.04 Mbps.
注意：OC-12cのための実際のデータレートは599.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)
4 Path indicator
4パスのインジケータ
0 - short (S)
1 - long (L)
5-7 Status Code
5-7ステータスコード
010 - Protection Switch Completed -traffic Wrapped (W)
000 - Idle (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コントロールメッセージを使用して通知されます。
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.
このコマンドは、コマンドが発行されるノードに、コマンドが宛先とされた隣接ノードでトラフィックをラップ、保護にワーキングチャネルからリングスイッチを行います。制御された方法でリングに別のノードを追加する例に使用します。
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の例を示します。予め選択されたSFしきい値、回線アラーム表示信号（AIS）上記信号（LOS）、フレーム同期損失（LOF）、ラインのビット誤り率（BER）の損失。 SRPキープアライブ障害は、エンドツーエンドのカバレッジを提供していますし、結果としてSONETパストリガーは必要ありません。
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です。
Like the FS, but of lower priority. Can be used for example to take down the WTR.
FS似ていますが、優先度の低いです。 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状態が消えた後、作業チャネルが回復閾値を満たす後に入りました。 IPSは、保護スイッチ発振を防止するために、トラフィックを復元する前に、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}
このモードでは、ノードは、保護スイッチを実行する準備ができており、それはソースアドレスフィールド内の「自己」を含むIPSメッセージ、「アイドル」の両方の近隣ノードに送信{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メッセージに基づいて入力されます。 NOT NULL要求に長いパスメッセージを受信したノードがメッセージを削除しない場合、ノードがTTLをデクリメントし、変更せずにメッセージを再送信する（条件をストリッピングするためのプロトコルルールを参照）されている場合。アイドル・メッセージの送信がないヌル要求のメッセージが転送される方向に停止されます。
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".
図14「IPSパケットフォーマット」で定義されている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.
ローカル要求を実行することも、環上の隣人にIDLEメッセージショートパス要求信号を実行もされていないノードは、そのリング上のノードを通過しない長いパスメッセージが存在しない場合。
R S.5:
R S.5：
Protection IPS packets are never wrapped.
保護IPSパケットはラップされることはありません。
R S.6:
R S. 6：
If the protocol calls for sending both short and long path requests on the same span (for example if a node has all fibers disconnected), only the short path request should be sent.
同じスパン上短期および長期の両方のパス要求を送信するためのプロトコルの呼び出しは、（例えば、ノードは、すべての繊維が切断された場合）、短いパス要求が送信されるべきである場合。
R S.7:
R S. 7：
A node wraps and unwraps only on a local request or on a short path request. A node never wraps or unwraps as a result of a long path request. Long path requests are used only to maintain protection hierarchy. (Since the long path requests do not trigger protection, there is no need for destination addresses and no need for topology maps)
ノードラップと、ローカル要求またはショートパス要求にアンラップします。ノードがラップしないか、長いパス要求の結果としてアンラップありません。長いパス要求は保護階層を維持するためにのみ使用されます。 （長いパス要求は保護を誘発しないので、宛先アドレスは不要とトポロジマップの必要はありません）
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とノードB間のスパンにSF（ローカルリクエスト/自己検出要求）を検出し、外輪と{SF、A、W上{SF、A、W、S}を調達開始します内側リング上のL}。ノードBは、ノードA（ショートパス要求）からの保護要求を受け取ると外輪に内輪と{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
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.
ノード決して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.
ノードは長いパス要求を受信し、要求がある場合> = {ショートパス要求、自己検出要求}の最上位に、ノードは、メッセージが短い経路上のネイバーから来ているかどうかを決定するためにメッセージをチェックします。そのような場合、それはパススルー入力しないと、メッセージが削除されます。
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)
2つの障害やシングルスパン上の2つの結果のWTR条件がある場合はWTR時間は、ノードが自動的にアンラップしない満了した後、タイムアウトする2番目の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}
凡例：影響を受けたスパンREQ = {FSのもう一方の端に=ノードメイト| SF | SD |ミズ}
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.環上の検出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}両方の環に（両方向に）
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}
{SF、B、W、S}と外輪/長いパスに：送信2. Bは、内側リング/短い経路上に向かって、（ラップを行い）、外輪のTXをラップ状態への遷移をSFを検出します{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に向かってラップ状態、送信に遷移：{IDLE、A、W、S}（メッセージが障害に通過しない）と長いパス上： TX {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
ノードDおよびCとして4.切替要求を受信し、彼らはアイドルメッセージを供給停止とBとの間でメッセージを渡す開始意味する（各方向に）パススルーモードに入ります
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}
B 1. SFはWTRタイマを設定し、Bはアンラップしない、クリア、送信{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に向かって短いパス上：{IDLE、A、W、S}（メッセージが障害に通過しない）と長いパスに：送信{WTR、A、W、L}
3. Nodes C and D relay long path messages without changing the IPS octet
3.ノードC及びD IPSオクテットを変更することなく、長いパスメッセージをリレー
5. WTR times out on B. B transitions to idle state (unwraps) Tx {IDLE, B, I, S} on both inner and outer rings
B. B 5. WTRタイムアウトアイドル状態に遷移する（アンラップ）のTx {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に到達します
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}及び外側リング/長い経路で：送信{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}
{SF、B、W、S}と外輪/長いパスに：送信3. Bは、内側リング/短い経路上に向かって、（ラップを行い）、外輪のTXをラップ状態への遷移をSFを検出します{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
ノードDおよびCとして4.切替要求を受信し、彼らはアイドルメッセージを供給停止とBとの間でメッセージを渡す開始意味する（各方向に）パススルーモードに入ります
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は、Aはアンラップしない、WTRタイマを設定し、長いパスのTX {WTR、A、W、S} Bに向かっておよびTx {WTR、A、W、L}
2. SF on B clears, B does not unwrap. Since it now has a short path WTR request present from A it acts upon this request. It keeps the wrap, Tx {IDLE, B, W, S} towards A and Tx {WTR, B, W, L} on the long path
Bのクリア2. SFは、Bはアンラップされません。それは今AからショートパスWTR要求存在を持っているので、この要求に応じて作用します。それは長いパスにラップ、AおよびTx {WTR、B、W、L}に向かって送信{IDLE、B、W、S}を保ちます
3. Nodes C and D relay long path messages without changing the IPS octet
3.ノードC及びD IPSオクテットを変更することなく、長いパスメッセージをリレー
5. WTR times out on A. A enters the idle state (drops wraps) and starts transmitting idle in both rings
A. A 5. WTRがタイムアウトは、アイドル状態に入る（ラップ滴）および両方の環にアイドル送信を開始します
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}及び外側リング/長い経路で：送信{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}及びインナーリング/長い経路で：送信{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の要求を受信すると、それらは（各方向に）パススルーモードに入る、アイドルメッセージを供給停止とBとの間でメッセージを渡す開始
Failed Node and One Span Return to Service
障害が発生したノードとサービスに対する一つのスパン戻ります
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}を供給し始めます。
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
{SFは、B、W、L}は長いスパンで受信された長波パスプロテクション要求はショートパスネイバー（C）から発信されていないので4ノードAは、ノードCからのアイドルメッセージを受信し、ノードAは、WTRをドロップし、入射しますCとBとの間のリクエストを渡すパススルー状態
Second Span Returns to Service
第二のスパンは、サービスに返します。
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}両方の環に（両方向に）
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}
{SF、B、W、S}と外輪/長いパスに：送信3. Bは、内側リング/短い経路上に向かって、（ラップを行い）、外輪のTXをラップ状態への遷移をSFを検出します{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}及び外側リング/長い経路で：送信{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の要求を受信すると、それらは（各方向に）パススルーモードに入る、アイドルメッセージを供給停止とBとの間でメッセージを渡す開始
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
第二のスパンは、サービスに入れ
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は、独立したメディアではあるが、それは、SRPがレイヤ1のメディアタイプで使用される方法は注目に値します。 SONET / SDHオーバーSRPがSRPのアプリケーションに認識される最初のメディアタイプです。
Flag delimiting on SONET/SDH uses the octet stuffing method defined for POS. The flags (0x7E) are packet delimiters required for SONET/SDH links but may not be necessary for SRP on other media types. End of a packet is delineated by the flag which could also be the same as the next packet's starting flag. If the flag (0x7E) or an escape character (0x7D) are present anywhere inside the packet, they have to be escaped by the escape character when used over SONET/SDH media.
SONET / SDH上の旗の区切りは、POS用に定義されたオクテットスタッフィング方式を使用しています。フラグ（0x7Eを）は、SONET / SDHリンクのために必要なパケットのデリミタであるが、他のメディアタイプにSRPのために必要ではないかもしれません。パケットの終わりは、また、次のパケットの開始フラグと同じにすることができフラグによって描写されます。フラグ（0x7Eを）またはエスケープ文字（0x7D）は、パケット内の任意の場所存在する場合、それらは、SONET / SDHメディア上で使用する場合、エスケープ文字でエスケープする必要があります。
SONET/SDH framing plus POS packet delimiting allows SRP to be used directly over fiber or through an optical network (including WDM equipment).
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リングは、二つのSTS-Ncの接続にマッピングすることができます。 2 STS-Ncの接続にマッピングSRPは2つのレベルの保護を有することになるので、SONET / SDHネットワークは、典型的には、完全に冗長接続を提供します。 SONET / SDHネットワークは、レイヤ1保護を提供し、SRPは、レイヤ2保護を提供します。この場合には、SONET / SDH網を保護することを可能にするために約100ミリ秒（SONET / SDHによって保護することができる障害に対応する）SRP信号障害IPSトリガーをオフに保持することが推奨されます。障害が100以上のミリ秒（SONET / SDH保護失敗を示す）継続している場合にのみ、IPS保護が行われるべきです。
Since multiple protection levels over the same physical infrastructure are not very desirable, an alternate way of connecting SRP over a SONET/SDH network is configuring SONET/SDH without protection. Since the connection is unprotected at layer 1, SRP would be the sole protection mechanism.
同じ物理インフラストラクチャを介して複数の保護レベルは非常に望ましくないため、SONET / SDHネットワーク上SRPを接続する別の方法は、保護なしSONET / SDHの設定されています。接続はレイヤ1で保護されていないので、SRPは唯一の保護メカニズムになります。
Hybrid SRP rings may also be built where some parts of the ring traverse over a SONET/SDH network while other parts do not.
ハイブリッドSRPリングは、他の部分がないながら、環の一部がSONET / SDHネットワークを介して横断する場合に構築することができます。
Connections to a SONET/SDH network would have to be synchronized to network timing by some means. This can be accomplished by locking the transmit connection to the frequency of the receive connection (called loop timing) or via an external synchronization technique.
SONET / SDHネットワークへの接続は、何らかの手段でネットワークタイミングに同期させる必要があります。これは、接続を受け取る（と呼ばれるループタイミング）の周波数への送信接続をロックすることによって、または外部同期技術を介して達成することができます。
Connections made via dark fiber or over a WDM optical network should utilize internal timing as clock synchronization is not necessary in this case.
クロック同期は、この場合には必要ではないようにダークファイバを介して、またはWDM光ネットワークを介して行われる接続は、内部タイミングを利用すべきです。
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]反抗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]ベルコア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.およびW.シンプソン、 "PPP SONET上/ SDH"、RFC 2615、1999年6月。
[6] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[6]、STD 51、RFC 1662、1994年7月シンプソン、W.、 "HDLC様のフレーミングにおけるPPPを"。
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.
そのノードは、設定ミスや悪意をもって構成されている場合、任意の共有メディアのように、ノードを通過するパケットは、そのノードに利用可能です。ノードは、パケットが別のノードのためのもので検査するだけでなく、空間的な再利用を得るために使用される宛先ストリッピング方式にパケットを受信することから意図ノードを防止するために加え、それが可能です。 Topologyの検出は、重複した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の元conceiversは本町華チン、グレアム・フレイザー、トニー・ベイツ、ブルース・ウィルフォード、ファイサルDaruwalla、およびロバート・ブロバーグが含まれます。
Comments should be sent to the authors at the following addresses:
コメントは、以下のアドレスで、作者に送信する必要があります。
David Tsiang Cisco Systems 170 W. Tasman Drive San Jose, CA 95134
デビッドTsiangシスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 95134
Phone: (408) 526-8216 EMail: tsiang@cisco.com
電話：（408）526-8216 Eメール：tsiang@cisco.com
George Suwala Cisco Systems 170 W. Tasman Drive San Jose, CA 95134
ジョージ不和シスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 95134
Phone: (408) 525-8674 EMail: gsuwala@cisco.com
電話：（408）525-8674 Eメール：gsuwala@cisco.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。