[要約] RFC 3309は、Stream Control Transmission Protocol（SCTP）のチェックサム変更に関する要約です。このRFCの目的は、SCTPのチェックサムの計算方法を変更し、パフォーマンスとセキュリティを向上させることです。
Network Working Group J. Stone
Request for Comments: 3309 Stanford
Updates: 2960 R. Stewart
Category: Standards Cisco Systems
D. Otis
SANlight
September 2002
Stream Control Transmission Protocol (SCTP) Checksum Change
ストリーム制御伝送プロトコル（SCTP）チェックサムの変更
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
Stream Control Transmission Protocol (SCTP) currently uses an Adler-32 checksum. For small packets Adler-32 provides weak detection of errors. This document changes that checksum and updates SCTP to use a 32 bit CRC checksum.
ストリーム制御伝送プロトコル（SCTP）は現在、Adler-32チェックサムを使用しています。小さなパケットの場合、Adler-32はエラーの弱い検出を提供します。このドキュメントは、そのチェックサムを変更し、SCTPを更新して32ビットCRCチェックサムを使用します。
Table of Contents
目次
1 Introduction ................................................... 2
2 Checksum Procedures ............................................ 3
3 Security Considerations......................................... 6
4 IANA Considerations............................................. 6
5 Acknowledgments ................................................ 6
6 References ..................................................... 7
Appendix ......................................................... 9
Authors' Addresses ............................................... 16
Full Copyright Statement ......................................... 17
1 Introduction
1はじめに
A fundamental weakness has been detected in SCTP's current Adler-32 checksum algorithm [STONE]. This document updates and replaces the Adler-32 checksum definition in [RFC 2960]. Note that there is no graceful transition mechanism for migrating to the new checksum. Implementations are expected to immediately switch to the new algorithm; use of the old algorithm is deprecated.
SCTPの現在のAdler-32チェックサムアルゴリズム[Stone]で根本的な弱点が検出されています。このドキュメントは、[RFC 2960]のAdler-32チェックサム定義を更新および置き換えます。新しいチェックサムに移行するための優雅な遷移メカニズムはないことに注意してください。実装はすぐに新しいアルゴリズムに切り替えることが期待されています。古いアルゴリズムの使用は非推奨です。
One requirement of an effective checksum is that it evenly and smoothly spreads its input packets over the available check bits.
効果的なチェックサムの要件の1つは、入力パケットを利用可能なチェックビットに均等かつスムーズに広げることです。
From an email from Jonathan Stone, who analyzed the Adler-32 as part of his doctoral thesis:
博士論文の一部としてAdler-32を分析したJonathan Stoneからのメールから：
"Briefly, the problem is that, for very short packets, Adler32 is guaranteed to give poor coverage of the available bits. Don't take my word for it, ask Mark Adler. :-)
「簡単に言えば、非常に短いパケットについては、Adler32が利用可能なビットのカバレッジが不十分であることが保証されていることです。それについて私の言葉を受け取らないでください、マーク・アドラーに尋ねてください。:-)
Adler-32 uses two 16-bit counters, s1 and s2. s1 is the sum of the input, taken as 8-bit bytes. s2 is a running sum of each value of s1. Both s1 and s2 are computed mod-65521 (the largest prime less than 2^16). Consider a packet of 128 bytes. The *most* that each byte can be is 255. There are only 128 bytes of input, so the greatest value which the s1 accumulator can have is 255 * 128 = 32640. So, for 128-byte packets, s1 never wraps. That is critical. Why?
Adler-32は、2つの16ビットカウンター、S1とS2を使用しています。S1は、8ビットバイトとして取得される入力の合計です。S2は、S1の各値の実行額です。S1とS2の両方は、MOD-65521を計算しています（2^16未満の最大のプライム）。128バイトのパケットを検討してください。各バイトが可能な *最も *は255です。128バイトの入力しかないため、S1アキュムレータが持つことができる最大の値は255 * 128 = 32640です。したがって、128バイトパケットの場合、S1はラップしません。それは重要です。なぜ？
The key is to consider the distribution of the s1 values, over some distribution of the values of the individual input bytes in each packet. Because s1 never wraps, s1 is simply the sum of the individual input bytes. (Even Doug's trick of adding 0x5555 doesn't help here, and an even larger value doesn't really help: we can get at most one mod-65521 reduction.)
重要なのは、各パケット内の個々の入力バイトの値のある程度の分布で、S1値の分布を考慮することです。S1は決してラップしないため、S1は単に個々の入力バイトの合計です。（0x5555を追加するダグのトリックでさえ、ここでは役に立たず、さらに大きな値は本当に役に立ちません。最大で1つのMOD-65521削減を獲得できます。）
Given the further assumption that the input bytes are drawn independently from some distribution (they probably aren't: for file system data, it's even worse than that!), the Central Limit Theorem tells us that that s1 will tend to have a normal distribution. That's bad: it tells us that the value of s1 will have hot-spots at around 128 times the mean of the input distribution: around 16k, assuming a uniform distribution. That's bad. We want the accumulator to wrap as many times as possible, so that the resulting sum has as close to a uniform distribution as possible. (I call this "fairness".) So, for short packets, the Adler-32 s1 sum is guaranteed to be unfair. Why is that bad? It's bad because the space of valid packets -- input data, plus checksum values -- is also small. If all packets have checksum values very close to 32640, then the likelihood of even a 'small' error leaving a damaged packet with a valid checksum is higher than if all checksum values are equally likely."
入力バイトがある程度の分布から独立して描かれているというさらなる仮定を考えると（おそらくそうではありません：ファイルシステムデータについては、それよりもさらに悪いです！）、中央の限界定理は、S1が正規分布を持っている傾向があることを示しています。。それは悪いことです。S1の値は、入力分布の平均の約128倍でホットスポットを持っていることを示しています。均一な分布を想定して、約16Kです。それは良くないね。アキュムレータができるだけ多くの回数をラップするようにして、結果として得られる合計ができるだけ均一な分布に近づくようにしたいと考えています。（私はこれを「公平性」と呼びます。）したがって、短いパケットの場合、Adler-32 S1 Sumは不公平であることが保証されています。なぜそれが悪いのですか？有効なパケットのスペース（入力データとチェックサムの値）も小さいため、それは悪いことです。すべてのパケットが32640に非常に近いチェックサム値を持っている場合、「小さな」エラーでさえ、有効なチェックサムを残したパケットを残す可能性は、すべてのチェックサム値が等しく可能性が高い場合よりも高くなります。」
Due to this inherent weakness, exacerbated by the fact that SCTP will first be used as a signaling transport protocol where signaling messages are usually less than 128 bytes, a new checksum algorithm is specified by this document, replacing the current Adler-32 algorithm with CRC-32c.
この固有の弱点により、SCTPが最初にシグナリングトランスポートプロトコルとして使用されるという事実により悪化し、シグナリングメッセージは通常128バイト未満であるため、新しいチェックサムアルゴリズムがこのドキュメントで指定され、現在のAdler-32アルゴリズムをCRCに置き換えます。-32c。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
キーワードは、このドキュメントに表示される場合、[RFC2119]に記載されているように解釈される場合、必要な、必須、必要は、推奨、推奨、推奨、推奨、推奨、推奨、推奨、推奨、およびオプションでなければなりません。
Bit number order is defined in [RFC1700].
ビット番号の順序は[RFC1700]で定義されています。
2 Checksum Procedures
2チェックサム手順
The procedures described in section 2.1 of this document MUST be followed, replacing the current checksum defined in [RFC2960].
[RFC2960]で定義されている現在のチェックサムを置き換えて、このドキュメントのセクション2.1で説明した手順に従う必要があります。
Furthermore any references within [RFC2960] to Adler-32 MUST be treated as a reference to CRC-32c. Section 2.1 of this document describes the new calculation and verification procedures that MUST be followed.
さらに、[RFC2960]内のAdler-32への参照は、CRC-32Cへの参照として扱わなければなりません。このドキュメントのセクション2.1では、従わなければならない新しい計算および検証手順について説明します。
When sending an SCTP packet, the endpoint MUST strengthen the data integrity of the transmission by including the CRC-32c checksum value calculated on the packet, as described below.
SCTPパケットを送信するとき、エンドポイントは、以下に説明するように、パケットに計算されたCRC-32Cチェックサム値を含めることにより、伝送のデータの整合性を強化する必要があります。
After the packet is constructed (containing the SCTP common header and one or more control or DATA chunks), the transmitter shall:
パケットが構築された後（SCTP共通ヘッダーと1つ以上の制御またはデータチャンクを含む）、送信機は次のとおりです。
1) Fill in the proper Verification Tag in the SCTP common header and initialize the Checksum field to 0's.
1) SCTP共通ヘッダーの適切な確認タグを入力し、チェックサムフィールドを0に初期化します。
2) Calculate the CRC-32c of the whole packet, including the SCTP common header and all the chunks.
2) SCTP共通ヘッダーとすべてのチャンクを含む、パケット全体のCRC-32Cを計算します。
3) Put the resulting value into the Checksum field in the common header, and leave the rest of the bits unchanged.
3) 結果の値を共通ヘッダーのチェックサムフィールドに入れ、残りの部分を変更せずに残します。
When an SCTP packet is received, the receiver MUST first check the CRC-32c checksum:
SCTPパケットを受信した場合、受信者は最初にCRC-32Cチェックサムをチェックする必要があります。
1) Store the received CRC-32c value,
1) 受信したCRC-32C値を保存し、
2) Replace the 32 bits of the Checksum field in the received SCTP packet with all '0's and calculate a CRC-32c value of the whole received packet. And,
2) 受信したSCTPパケットのチェックサムフィールドの32ビットをすべての '0を交換し、受信したパケット全体のCRC-32C値を計算します。そして、
3) Verify that the calculated CRC-32c value is the same as the received CRC-32c value. If not, the receiver MUST treat the packet as an invalid SCTP packet.
3) 計算されたCRC-32C値が受信したCRC-32C値と同じであることを確認します。そうでない場合、受信者はパケットを無効なSCTPパケットとして扱う必要があります。
The default procedure for handling invalid SCTP packets is to silently discard them.
無効なSCTPパケットを処理するためのデフォルトの手順は、それらを静かに破棄することです。
Any hardware implementation SHOULD be done in a way that is verifiable by the software.
ハードウェアの実装は、ソフトウェアが検証できる方法で実行する必要があります。
We define a 'reflected value' as one that is the opposite of the normal bit order of the machine. The 32 bit CRC is calculated as described for CRC-32c and uses the polynomial code 0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25 +x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. The CRC is computed using a procedure similar to ETHERNET CRC [ITU32], modified to reflect transport level usage.
「反射値」を、マシンの通常のビット順序の反対のものとして定義します。32ビットCRCは、CRC-32Cについて説明されているように計算され、多項式コード0x11edc6f41（castagnoli93）またはx^32 x^28 x^27 x^26 x^25 x^23 x^22 x^20 x^19 xを使用します。^18 x^14 x^13 x^11 x^10 x^9 x^8 x^6 x^0。CRCは、輸送レベルの使用量を反映するように変更されたイーサネットCRC [ITU32]に似た手順を使用して計算されます。
CRC computation uses polynomial division. A message bit-string M is transformed to a polynomial, M(X), and the CRC is calculated from M(X) using polynomial arithmetic [Peterson 72].
CRC計算は、多項式分割を使用します。メッセージビットストリングMは多項式M（x）に変換され、CRCは多項式算術[Peterson 72]を使用してM（x）から計算されます。
When CRCs are used at the link layer, the polynomial is derived from on-the-wire bit ordering: the first bit 'on the wire' is the high-order coefficient. Since SCTP is a transport-level protocol, it cannot know the actual serial-media bit ordering. Moreover, different links in the path between SCTP endpoints may use different link-level bit orders.
CRCがリンク層で使用される場合、多項式はワイヤビットの順序付けから派生します。最初のビット「ワイヤ」は高次係数です。SCTPはトランスポートレベルのプロトコルであるため、実際のシリアルメディアビットの順序を知ることはできません。さらに、SCTPエンドポイント間のパス内の異なるリンクは、異なるリンクレベルのビット注文を使用する場合があります。
A convention must therefore be established for mapping SCTP transport messages to polynomials for purposes of CRC computation. The bit-ordering for mapping SCTP messages to polynomials is that bytes are taken most-significant first; but within each byte, bits are taken least-significant first. The first byte of the message provides the eight highest coefficients. Within each byte, the least-significant SCTP bit gives the most significant polynomial coefficient within that byte, and the most-significant SCTP bit is the least significant polynomial coefficient in that byte. (This bit ordering is sometimes called 'mirrored' or 'reflected' [Williams93].) CRC polynomials are to be transformed back into SCTP transport-level byte values, using a consistent mapping.
したがって、CRC計算を目的として、SCTPトランスポートメッセージを多項式にマッピングするための規則を確立する必要があります。SCTPメッセージを多項式にマッピングするためのビット順序は、バイトが最初に最も重要であることです。しかし、各バイト内で、ビットは最初に最も重要ではないことです。メッセージの最初のバイトは、8つの最高の係数を提供します。各バイト内で、最も重要でないSCTPビットは、そのバイト内で最も重要な多項式係数を与え、最も重要なSCTPビットは、そのバイトで最も有意な多項式係数です。（このビット順序は、「ミラーリング」または「反射」と呼ばれることもあります[Williams93]。）CRC多項式は、一貫したマッピングを使用して、SCTPトランスポートレベルのBYTE値に変換されます。
The SCTP transport-level CRC value should be calculated as follows:
SCTPトランスポートレベルのCRC値は、次のように計算する必要があります。
- CRC input data are assigned to a byte stream, numbered from 0 to N-1.
- CRC入力データは、0からn-1までのバイトストリームに割り当てられます。
- the transport-level byte-stream is mapped to a polynomial value. An N-byte PDU with j bytes numbered 0 to N-1, is considered as coefficients of a polynomial M(x) of order 8N-1, with bit 0 of byte j being coefficient x^(8(N-j)-8), bit 7 of byte j being coefficient x^(8(N-j)-1).
- トランスポートレベルのバイトストリームは、多項式値にマッピングされます。jバイトが0からn-1のnバイトPDUは、順序8n-1の多項式m（x）の係数と見なされ、バイトjのビット0は係数x^（8（n-j）-8）です。、バイトjのビット7は係数x^（8（n-j）-1）です。
- the CRC remainder register is initialized with all 1s and the CRC is computed with an algorithm that simultaneously multiplies by x^32 and divides by the CRC polynomial.
- CRCの残りのレジスタはすべての1で初期化され、CRCは同時にx^32を掛け、CRC多項式で除算するアルゴリズムで計算されます。
- the polynomial is multiplied by x^32 and divided by G(x), the generator polynomial, producing a remainder R(x) of degree less than or equal to 31.
- 多項式にx^32を乗算し、発電機多項式であるg（x）で除算し、31以下の程度の程度のr（x）を生成します。
- the coefficients of R(x) are considered a 32 bit sequence.
- r（x）の係数は32ビットシーケンスと見なされます。
- the bit sequence is complemented. The result is the CRC polynomial.
- ビットシーケンスが補完されます。結果はCRC多項式です。
- The CRC polynomial is mapped back into SCTP transport-level bytes. Coefficient of x^31 gives the value of bit 7 of SCTP byte 0, the coefficient of x^24 gives the value of bit 0 of byte 0. The coefficient of x^7 gives bit 7 of byte 3 and the coefficient of x^0 gives bit 0 of byte 3. The resulting four-byte transport-level sequence is the 32-bit SCTP checksum value.
- CRC多項式は、SCTP輸送レベルのバイトにマッピングされます。x^31の係数は、SCTPバイト0のビット7の値を与え、x^24の係数はバイト0のビット0の値を与えますx^7はバイト3のビット7とx^の係数を与えます。0はバイト3のビット0を与えます。
IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor literature on CRCs often follow an alternative formulation, in which the register used to hold the remainder of the long-division algorithm is initialized to zero rather than all-1s, and instead the first 32 bits of the message are complemented. The long-division algorithm used in our formulation is specified, such that the the initial multiplication by 2^32 and the long-division are combined into one simultaneous operation. For such algorithms, and for messages longer than 64 bits, the two specifications are precisely equivalent. That equivalence is the intent of this document.
実装注：CRCに関する標準文書、教科書、およびベンダーの文献は、多くの場合、代替の定式化に従います。レジスタは、残りの長い分割アルゴリズムを保持するために使用されていました。メッセージが補完されます。製剤で使用される長距離アルゴリズムが指定されているため、2^32の初期乗算と長距離が1つの同時動作に結合されます。このようなアルゴリズムの場合、および64ビットより長いメッセージの場合、2つの仕様はまったく同等です。その同等性は、このドキュメントの意図です。
Implementors of SCTP are warned that both specifications are to be found in the literature, sometimes with no restriction on the long-division algorithm. The choice of formulation in this document is to permit non-SCTP usage, where the same CRC algorithm may be used to protect messages shorter than 64 bits.
SCTPの実装者は、両方の仕様が文献に記載されていることを警告されています。時には長距離アルゴリズムに制限がない場合があります。このドキュメントの定式化の選択は、同じCRCアルゴリズムを使用して64ビットより短いメッセージを保護するために使用できる非SCTP使用を許可することです。
If SCTP could follow link level CRC use, the CRC would be computed over the link-level bit-stream. The first bit on the link mapping to the highest-order coefficient, and so on, down to the last link-level bit as the lowest-order coefficient. The CRC value would be transmitted immediately after the input message as a link-level 'trailer'. The resulting link-level bit-stream would be (M(X)x) * x^32) + (M(X)*x^32))/ G(x), which is divisible by G(X). There would thus be a constant CRC remainder for 'good' packets. However, given that implementations of RFC 2960 have already proliferated, the IETF discussions considered that the benefit of a 'trailer' CRC did not outweigh the cost of making a very large change in the protocol processing. Further, packets accepted by the SCTP 'header' CRC are in one-to-one correspondence with packets accepted by a modified procedure using a 'trailer' CRC value, and where the SCTP common checksum header is set to zero on transmission and is received as zero.
SCTPがリンクレベルCRCの使用に従うことができる場合、CRCはリンクレベルのビットストリームで計算されます。リンクの最初のビットは、最高級の係数へのマッピングなど、最低係数として最後のリンクレベルのビットまでです。CRC値は、入力メッセージの直後にリンクレベルの「トレーラー」として送信されます。結果のリンクレベルのビットストリームは（m（x）x） * x^32）（m（x） * x^32））/ g（x）であり、g（x）で割り切れます。したがって、「良い」パケットには一定のCRC残りがあります。ただし、RFC 2960の実装がすでに増殖していることを考えると、IETFの議論では、「トレーラー」CRCの利点はプロトコル処理の非常に大きな変化をもたらすコストを上回っていないと考えられていました。さらに、SCTP 'ヘッダー' CRCによって受け入れられたパケットは、「トレーラー」CRC値を使用して修正された手順で受け入れられたパケットと1対1の対応であり、SCTP共通チェックサムヘッダーが送信でゼロに設定され、受信されます。ゼロとして。
There may be a computational advantage in validating the Association against the Verification Tag, prior to performing a checksum, as invalid tags will result in the same action as a bad checksum in most cases. The exceptions for this technique would be INIT and some SHUTDOWN-COMPLETE exchanges, as well as a stale COOKIE-ECHO. These special case exchanges must represent small packets and will minimize the effect of the checksum calculation.
チェックサムを実行する前に、確認タグに対する関連性を検証する際には計算上の利点があるかもしれません。無効なタグは、ほとんどの場合、悪いチェックサムと同じアクションにつながるためです。この手法の例外は、initといくつかのシャットダウン完全な交換と、古いクッキーエコーです。これらの特別なケース交換は、小さなパケットを表す必要があり、チェックサムの計算の効果を最小限に抑えます。
3 Security Considerations
3つのセキュリティ上の考慮事項
In general, the security considerations of RFC 2960 apply to the protocol with the new checksum as well.
一般に、RFC 2960のセキュリティ上の考慮事項は、新しいチェックサムを使用してプロトコルにも適用されます。
4 IANA Considerations
4 IANAの考慮事項
There are no IANA considerations required in this document.
このドキュメントでは、IANAの考慮事項は必要ありません。
5 Acknowledgments
5謝辞
The authors would like to thank the following people that have provided comments and input on the checksum issue:
著者は、チェックサムの問題に関するコメントと情報を提供した以下の人々に感謝したいと思います。
Mark Adler, Ran Atkinson, Stephen Bailey, David Black, Scott Bradner, Mikael Degermark, Laurent Glaude, Klaus Gradischnig, Alf Heidermark, Jacob Heitz, Gareth Kiely, David Lehmann, Allision Mankin, Lyndon Ong, Craig Partridge, Vern Paxson, Kacheong Poon, Michael Ramalho, David Reed, Ian Rytina, Hanns Juergen Schwarzbauer, Chip Sharp, Bill Sommerfeld, Michael Tuexen, Jim Williams, Jim Wendt, Michael Welzl, Jonathan Wood, Lloyd Wood, Qiaobing Xie, La Monte Yarroll.
マーク・アドラー、ラン・アトキンソン、スティーブン・ベイリー、デビッド・ブラック、スコット・ブラッドナー、ミカエル・デガルク、ローラン・グラード、クラウス・グラディシニグ、アルフ・ハイダーマーク、ジェイコブ・ハイツ、ガレス・キーリー、デビッド・リーマン、アライジョン・マンキン、リンドン・オング、、マイケル・ラマルホ、デビッド・リード、イアン・リチーナ、ハンズ・ジュエルゲン・シュワルツバウアー、チップ・シャープ、ビル・ソマーフェルド、マイケル・トゥエクセン、ジム・ウィリアムズ、ジム・ウェント、マイケル・ウェルツル、ジョナサン・ウッド、ロイド・ウッド、Qiaobing Xie、LAモンテ・ヤロル。
Special thanks to Dafna Scheinwald, Julian Satran, Pat Thaler, Matt Wakeley, and Vince Cavanna, for selection criteria of polynomials and examination of CRC polynomials, particularly CRC-32c [Castagnoli93].
Dafna Scheinwald、Julian Satran、Pat Thaler、Matt Wakeley、およびVince Cavannaに感謝します。多項式の選択基準とCRC多項式の検査、特にCRC-32C [Castagnoli93]に感謝します。
Special thanks to Mr. Ross Williams and his document [Williams93]. This non-formal perspective on software aspects of CRCs furthered understanding of authors previously unfamiliar with CRC computation. More formal treatments of [Blahut 94] or [Peterson 72], was also essential.
ロス・ウィリアムズ氏と彼の文書[Williams93]に感謝します。CRCSのソフトウェアの側面に関するこの非フォーマルな視点は、以前はCRCの計算に不慣れな著者の理解を促進しました。[Blahut 94]または[Peterson 72]のより正式な治療も不可欠でした。
6 References
6リファレンス
[Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman, "Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE Transactions on Communications, Vol. 41, No. 6, June 1993
[Castagnoli93] G. Castagnoli、S。Braeuer、M。Herrman、「24および32のパリティビットによる環状冗長チェックコードの最適化」、IEEE Transactions on Communications、vol。41、No。6、1993年6月
[McKee75] H. McKee, "Improved {CRC} techniques detects erroneous leading and trailing 0's in transmitted data blocks", Computer Design Volume 14 Number 10 Pages 102-4,106, October 1975
[McKee75] H. McKee、「改善された{CRC}手法は、送信されたデータブロックで誤ったリーディングおよびトレーニング0を検出します」、コンピューターデザインボリューム14番号10ページ102-4,106、1975年10月
[RFC1700] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", RFC 1700, October 1994.
[RFC1700] Reynolds、J。およびJ. Postel、「割り当てられた番号」、RFC 1700、1994年10月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol," RFC 2960, October 2000.
[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。and V.Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[ITU32] ITU-T Recommendation V.42, "Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion", section 8.1.1.6.2, October 1996.
[ITU32] ITU-Tの推奨V.42、「非同期から同期変換を使用したDCEのエラー修正手順」、セクション8.1.1.6.2、1996年10月。
[STONE] Stone, J., "Checksums in the Internet", Doctoral dissertation - August 2001.
[Stone] Stone、J。、「インターネットのチェックサム」、博士論文 - 2001年8月。
[Williams93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS" - Internet publication, August 1993, http://www.geocities.com/SiliconValley/Pines/ 8659/crc.htm.
[Williams93] Williams、R。、「CRCエラー検出アルゴリズムの痛みのないガイド」 - インターネット出版、1993年8月、http：//www.geocities.com/siliconvalley/pines/ 8659/crc.htm。
[Blahut 1994] R.E. Blahut, Theory and Practice of Error Control Codes, Addison-Wesley, 1994.
[Blahut 1994] R.E.Blahut、エラー制御コードの理論と実践、Addison-Wesley、1994。
[Easics 2001] http://www.easics.be/webtools/crctool. Online tools for synthesis of CRC Verilog and VHDL.
[Easics 2001] http://www.easics.be/webtools/crctool。CRC VerilogおよびVHDLの合成のためのオンラインツール。
[Feldmeier 95] David C. Feldmeier, Fast software implementation of error detection codes, IEEE Transactions on Networking, vol 3 no 6, pp 640-651, December, 1995.
[Feldmeier 95] David C. Feldmeier、エラー検出コードの高速ソフトウェア実装、ネットワーキングに関するIEEEトランザクション、Vol 3 No 6、pp 640-651、1995年12月。
[Glaise 1997] R. J. Glaise, A two-step computation of cyclic redundancy code CRC-32 for ATM networks, IBM Journal of Research and Development} vol 41 no 6, 1997. http://www.research.ibm.com/journal/rd/416/ glaise.html.
[Glaise 1997] R. J. Glaise、ATMネットワーク用の環状冗長コードCRC-32の2段階の計算、IBM Journal of Research and Development} Vol 41 no 6、1997。http：//www.research.ibm.com/journal/rd/416/glaise.html。
[Prange 1957] E. Prange, Cyclic Error-Correcting codes in two symbols, Technical report AFCRC-TN-57-103, Air Force Cambridge Research Center, Cambridge, Mass. 1957.
[Prange 1957] E. Prange、2つのシンボルのサイクリックエラー補正コード、テクニカルレポートAFCRC-TN-57-103、空軍ケンブリッジリサーチセンター、ケンブリッジ、マサチューセッツ州1957年。
[Peterson 1972] W. W. Peterson and E.J Weldon, Error Correcting Codes, 2nd. edition, MIT Press, Cambridge, Massachusetts.
[Peterson 1972] W. W. Peterson and E.J Weldon、エラー修正コード、2番目。エディション、MIT Press、ケンブリッジ、マサチューセッツ。
[Shie2001] Ming-Der Shieh et. al, A Systematic Approach for Parallel CRC Computations. Journal of Information Science and Engineering, Vol.17 No.3, pp.445-461
[Shie2001] Ming-Der Shieh et。AL、並列CRC計算のための体系的なアプローチ。Journal of Information Science and Engineering、Vol.17 No.3、pp.445-461
[Sprachman2001] Michael Sprachman, Automatic Generation of Parallel CRC Circuits, IEEE Design & Test May-June 2001
[Sprachman2001] Michael Sprachman、並列CRC回路の自動生成、IEEEデザイン＆テスト2001年5月 - 6月
Appendix
付録
This appendix is for information only and is NOT part of the standard.
この付録は情報のみを用意しており、標準の一部ではありません。
The anticipated deployment of SCTP ranges over several orders of magnitude of link speed: from cellular-power telephony devices at tens of kilobits, to local links at tens of gigabits. Implementors of SCTP should consider their link speed and choose, from the wide range of CRC implementations, one which matches their own design point for size, cost, and throughput. Many techniques for computing CRCs are known. This Appendix surveys just a few, to give a feel for the range of techniques available.
SCTPの予想される展開は、数十キロビットのセルラー電力テレフォニーデバイスから、数十ギガビットのローカルリンクまで、数桁のリンク速度に及びます。SCTPの実装者は、リンク速度を考慮し、幅広いCRC実装から選択する必要があります。CRCを計算するための多くの手法が知られています。この付録は、利用可能なさまざまなテクニックを感じるために、ほんの数個の調査を行っています。
CRCs are derived from early work by Prange in the 1950s [Prange 57]. The theory underlying CRCs and choice of generator polynomial can be introduced by either the theory of Galois fields [Blahut 94] or as ideals of an algebra over cyclic codes [cite Peterson 72].
CRCは、1950年代のPrangeによる初期の研究に由来しています[Prange 57]。CRCの根底にある理論と発電機多項式の選択は、ガロワフィールドの理論[Blahut 94]のいずれかによって、または周期的なコード上の代数の理想[Peterson 72を引用]によって導入できます。
One of the simplest techniques is direct bit-serial hardware implementations, using the generator polynomial as the taps of a linear feedback shift register (LSFR). LSFR computation follows directly from the mathematics, and is generally attributed to Prange. Tools exist which, a CRC generator polynomial, will produce synthesizable Verilog code for CRC hardware [Easics 2001].
最も単純な手法の1つは、発電機多項式を線形フィードバックシフトレジスタ（LSFR）のタップとして使用する直接的なビットシリアルハードウェアの実装です。LSFR計算は数学から直接続き、一般にPrangeに起因します。CRCジェネレーター多項式であるCRCハードウェア用の合成可能なVerilogコードを生成するツールが存在します[Easics 2001]。
Since LSFRs do not scale well in speed, a variety of other techniques have been explored. One technique exploits the fact that the divisor of the polynomial long-division, G, is known in advance. It is thus possible to pre-compute lookup tables giving the polynomial remainder of multiple input bits --- typically 2, 4, or 8 bits of input at a time. This technique can be used either in software or in hardware. Software to compute lookup tables yielding 2, 4, or 8 bits of result is freely available. [Williams93]
LSFRは速度を十分に拡張していないため、他のさまざまな手法が調査されています。1つの手法では、多項式の長距離gの除数であるGが事前に知られているという事実を活用しています。したがって、ルックアップテーブルを事前に計算することができます。複数の入力ビットの多項式残りの残り---通常は2、4、または8ビットの入力が一度に入力されます。この手法は、ソフトウェアまたはハードウェアで使用できます。2、4、または8ビットの結果を生成するルックアップテーブルを計算するソフトウェアは、自由に利用可能です。[Williams93]
For multi-gigabit links, the above techniques may still not be fast enough. One technique for computing CRCS at OC-48 rates is 'two-stage' CRC computation [Glaise 1997]. Here, some multiple of G(x), G(x)H(x), is chosen so as to minimize the number of nonzero coefficients, or weight, of the product G(x)H(x). The low weight of the product polynomial makes it susceptible to efficient hardware divide-by-constant implementations. This first stage gives M(x)/ (G(x)H(x)), as its result. The second stage then divides the result of the first stage by H(x), yielding (M(x)/(G(x)H(x)))/H(x). If H(x) is also relatively prime to G(x), this gives M(x)/G(x). Further developments on this approach can be found in [Shie2001] and [Sprachman2001].
マルチギガビットリンクの場合、上記の手法はまだ十分に速くない場合があります。OC-48レートでCRCを計算するための1つの手法は、「2段階」CRC計算です[Glaise 1997]。ここでは、g（x）h（x）のg（x）、g（x）h（x）のいくつかの倍数が選択され、g（x）h（x）の非ゼロ係数または重量の数を最小化します。製品の多項式の重量が少ないため、適切なハードウェアの分割型の実装の影響を受けやすくなります。この最初の段階は、その結果として、m（x）/（g（x）h（x））を提供します。第2段階では、最初の段階の結果をH（x）で分割し、（m（x）/（g（x））h（x））/h（x）を生成します。h（x）がg（x）に比べて比較的素数である場合、これはm（x）/g（x）を与えます。このアプローチに関するさらなる開発は、[SHIE2001]および[Sprachman2001]にあります。
The literature also includes a variety of software CRC implementations. One approach is to use a carefully-tuned assembly code for direct polynomial division. [Feldmeier 95] reports that for low-weight polynomials, tuned polynomial arithmetic gives higher throughput than table-lookup algorithms. Even within table-lookup algorithms, the size of the table can be tuned, either for total cache footprint, or (for space-restricted environments) to minimize total size.
文献には、さまざまなソフトウェアCRC実装も含まれています。1つのアプローチは、直接多項式分割に慎重に調整されたアセンブリコードを使用することです。[Feldmeier 95]は、低重量多項式の場合、調整された多項式算術により、テーブルルックアップアルゴリズムよりも高いスループットが得られると報告しています。テーブルルックアップアルゴリズム内であっても、総サイズを最小限に抑えるために、キャッシュフットプリント全体、または（スペース制限環境の場合）テーブルのサイズを調整できます。
Implementors should keep in mind, the bit ordering described in Section 2: the ordering of bits within bytes for computing CRCs in SCTP is the least significant bit of each byte is the most-significant polynomial coefficient(and vice-versa). This 'reflected' SCTP CRC bit ordering matches on-the-wire bit order for Ethernet and other serial media, but is the reverse of traditional Internet bit ordering.
実装者は、セクション2で説明されているビットの順序付けを覚えておく必要があります。SCTPのCRCを計算するためのバイト内のビットの順序付けは、各バイトの最も重要なビットであり、最も重要な多項式係数（および逆）です。この「反射」SCTP CRCビット注文は、イーサネットおよびその他のシリアルメディアのオンザワイヤビット注文と一致しますが、従来のインターネットビット注文の逆です。
One technique to accommodate this bit-reversal can be explained as follows: sketch out a hardware implementation, assuming the bits are in CRC bit order; then perform a left-to-right inversion (mirror image) on the entire algorithm. (We defer, for a moment, the issue of byte order within words.) Then compute that "mirror image" in software. The CRC from the "mirror image" algorithm will be the bit-reversal of a correct hardware implementation. When the link-level media sends each byte, the byte is sent in the reverse of the host CPU bit-order. Serialization of each byte of the "reflected" CRC value re-reverses the bit order, so in the end, each byte will be transmitted on-the-wire in the specified bit order.
このビット反転に対応するための1つの手法は、次のように説明できます。BITがCRCビット順序であると仮定して、ハードウェアの実装をスケッチします。次に、アルゴリズム全体で左から右への反転（鏡像）を実行します。（私たちはしばらくの間、単語内のバイト順序の問題を延期します。）その後、ソフトウェアでその「ミラーイメージ」を計算します。「ミラーイメージ」アルゴリズムからのCRCは、正しいハードウェアの実装のビット反転になります。リンクレベルのメディアが各バイトを送信すると、バイトはホストCPUビットオーダーの逆に送信されます。「反射された」CRC値の各バイトのシリアル化はビット順序を反転させるため、最終的には、各バイトが指定されたビット順序でワイヤで送信されます。
The following non-normative sample code is taken from an open-source CRC generator [Williams93], using the "mirroring" technique and yielding a lookup table for SCTP CRC32-c with 256 entries, each 32 bits wide. While neither especially slow nor especially fast, as software table-lookup CRCs go, it has the advantage of working on both big-endian and little-endian CPUs, using the same (host-order) lookup tables, and using only the pre-defined ntohl() and htonl() operations. The code is somewhat modified from [Williams93], to ensure portability between big-endian and little-endian architectures. (Note that if the byte endian-ness of the target architecture is known to be little-endian the final bit-reversal and byte-reversal steps can be folded into a single operation.)
以下の非規範的なサンプルコードは、オープンソースCRCジェネレーター[Williams93]から取得され、「ミラーリング」手法を使用して、256エントリのSCTP CRC32-Cのルックアップテーブルを生成します。ソフトウェアのテーブルルックアップCRCSが進むにつれて、特に遅くも速いことも特に高速ではありませんが、同じ（ホストの）ルックアップテーブルを使用し、前のもののみを使用して、ビッグエンディアンとリトルエンディアンの両方のCPUで作業するという利点があります。定義されたntohl（）およびhtonl（）操作。このコードは、[Williams93]から多少変更されており、大エンディアンとリトルエンディアンの建築物の間の携帯性を確保しています。（ターゲットアーキテクチャのバイトエンディアン性が小さなエンディアンであることが知られている場合、最終的なビット反転とバイト反転ステップを単一の操作に折りたたむことができることに注意してください。）
/*************************************************************/
/* Note Definition for Ross Williams table generator would */
/* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */
/* For Mr. Williams direct calculation code use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */
/*************************************************************/
/* Example of the crc table file */
#ifndef __crc32cr_table_h__
#define __crc32cr_table_h__
#define CRC32C_POLY 0x1EDC6F41
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
unsigned long crc_c[256] = { 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L,0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, };
unsigned long crc_c [256] = {0x00000000l、0xf26b8303l、0xe13b70f7l、0x1350f3f4l、0xc79a971fl、0x35f1141cl、0x26a1e7e7e8l、0xd4ca64ebl、0x8bd9558cad8cad8cad8cad8cad8cad8cfd958c x6be22838l、0x9989ab3bl、0x4d43cfd0l、0xbf284cd3l、0xac78bf27l、0x5e133c24l、0x105ec76fl、0xe235446cl、0xf165b798l、0x0349bbl、0xd78l、0x0349bbl0x25Afd373l、0x36ff2087l、0xc494a384l、0x9a879fa0l、0x68ec1ca3l、0x7bbcef57l、0x89d76c54l、0x5d1d08bfl、0xaf7668bbbbcl、0xbbc26848bfl、0xbbc26888bfl、 0x20bd8edel、0xd2d60dddl、0xc186fe29l、0x33ed7d2al、0x154c9ac2l、0x061c6936l、0xf4777ea35l、0xa64d6111616d616l、0x580f5512512512512 0xb93425e5l、0x6dfe410el、0x9f95c20dl、0x8cc531f9l、0x7eaeb2fal、0x30e349b1l、0xc288cab2l、0xd1d83946l、0x23b3ba45l、0xf779deeel、0x05125dadl、0x1642ae59l、0xe4292d5aal、0xe4292d5aal 1927dl、0x5b016189l、0xa96ae28al、0x7da08661l、0x8fcb0562l、0x9c9bf696l、0x6ef07595l、0x417b1dbcl、0xb3109ebfl、0xa0404404040404044040404040404040404040404040404040404040404040404040404040404040404040404404040404040404040404040404040404040404040404 e18aa3l、0x748a09a0l、0x67dafa54l、0x95b17957l、0xcba24573l、0x39c9c670l、0x2a993584l、0xd8f2b687l、0x0c38d26cl、0xfe53516fl、0xed03a29bl、0x1f682198l、0x182198l、0x182198l L、0xb01eaa24l、0x42752927l、0x96bf4dccl、0x64d4cecfl、0x77843d3bl、0x85efbe38l、0xdbfc821cl、0x2997011fl 0d9600l、0xfd5d65f4l、0x0f36e6f7l、0x61c69362l、0x93ad1061l、0x80fde395l、0x72966096l、0xa65c047dl、0x54378775l、0x4767748al、0xb1f44444444444444444444444444444444444444444448 0xf84f3859l、0x2c855cb2l、0xdeeedfb1l、0xcdbe2c45l、0x3fd5af46l、0x7198540dl、0x83f3d70el、0x90a3244fal、0x62c8a8a88a888444444444444444444444444444444444444444444444444444444444444444444444444444424 L、0x5739b3e5l、0xa55230e6l、0xfb410cc2l、0x092a8fc1l、0x1a7a7c35l、0xe811ff36l、0x3cdb9bddl、0xceb018del、0xdde0eb2al、0x2f8b6829l、0x82f63b8lb78l、0x709db87bll、0x1b87bl、0x709db87bbl 、0x456cac67l、0xb7072f64l、0xa457dc90l、0x563c5ff93l、0x082f63b7l、0xfa44e0b4l、0xe9141340l、0x1b7l、0xcfb58pf4e7l、0xcfb545f88pf458l83l、0xe9141340l、0x1b7l E845fl、0xdce5075cl、0x92a8fc17l、0x60c37f14l、0x73938ce0l、0x81f80fe3l、0x55326b08l、0xa759e80bl、0xb4091bffl、0x466298fcl、0x1871a4d8l、0xea1a27dbl、0xea1a27dbl、0xea1a27dbl、 0xdfeb33c7l、0x2d80b0c4l、0x3ed04330l、0xccbbbc033l、0xa24bb5a6l、0x502036a5l、0x4370c5551l、0xb11bb4652l、0x65d122b9l、0x59l、0x59l 681d14dl、0x2892ed69l、0xdaf96e6al、0xc9a99d9el、0x3bc21e9dl、0xef087a76l、0x1d63f975l、0x0e330a81l、0xfc5888882l、0xb21572c9l、0x407ef1cal、0x532e023el、0x532e023el、0x532e023lel、0x532e023el 6l、0x87e466d5l、0x94b49521l、0x66df1622l、0x38cc2a06l、0xcaaa7a905l、0xd9f75af1l、0x2b9cd9f2l、0xff56bd19l、0x0d3、0x0d3edc1dec1dc1dc1dc1dc144d19l Eedl、0xc38d26c4l、0x31e6a5c7l、0x22b65633l、0xd0dddd530l、0x0417b1dbl、0xf67c32d8l、0xe52cc12cl、0x17474222ffl、0x49547e0bl、0xbb3ffd08l、0xa86f0efcl、0x5a048dffl、0x8 6ff599e3l、0x9d9e1ae0l、0xd3d3e1abl、0x21b862a8l、0x32e8915cl、0xc083125fl、0x144976b4l、0xe6222f5b7l、0xf57207207207207207207207l、0x57l、0x572L、0x572072072043L、0x572072072072072043L Xab613a67l、0xb831c993l、0x4a5a4a90l、0x9e902e7bl、0x6cfbad78l、0x7fab55e8cl、0x8dc0dd8fl、0xe330a81al、0x115b2b19l、0x020bd8edl、0xf0605beel、0x24aa3f05l、0xd6cp244444444adcp24a、0xd6ccp24ap24aw05l 7faccf1l、0x69e9f0d5l、0x9b8273d6l、0x88d28022l、0x7ab90321l、0xae7367cal、0x5c18e4c9l、0x4f48173dl、0xbd23943l、0xf3343l、0xf3343l x12551f82l、0xe03e9c81l、0x34f4f86al、0xc69f7b69l、0xd5cf889dl、0x27a40b9el、0x79b737bbal、0x8bdcb4b9l、0x988c474dl、0x6ae7c44el、0xbe2da0a0a5l、0x4c44623a6l、0x4423a6dda 1L、};
#endif
#endif
/* Example of table build routine */
#include <stdio.h>
#include <stdlib.h>
#define OUTPUT_FILE "crc32cr.h" #define CRC32C_POLY 0x1EDC6F41L FILE *tf;
#define output_file "crc32cr.h" #define crc32c_poly 0x1edc6f41l file *tf;
unsigned long reflect_32 (unsigned long b) { int i; unsigned long rw = 0L;
unsigned long refrect_32（unsigned long b）{int i;署名されていない長いrw = 0l;
for (i = 0; i < 32; i++){
if (b & 1)
rw |= 1 << (31 - i);
b >>= 1;
}
return (rw);
}
unsigned long build_crc_table (int index) { int i; unsigned long rb;
unsigned long build_crc_table（int index）{int i;署名されていない長いRB;
rb = reflect_32 (index);
rb = refrect_32（index）;
for (i = 0; i < 8; i++){
if (rb & 0x80000000L)
rb = (rb << 1) ^ CRC32C_POLY;
else
rb <<= 1;
}
return (reflect_32 (rb));
}
main () { int i;
main（）{int i;
printf ("\nGenerating CRC-32c table file <%s>\n", OUTPUT_FILE);
if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){
printf ("Unable to open %s\n", OUTPUT_FILE);
exit (1);
}
fprintf (tf, "#ifndef __crc32cr_table_h__\n");
fprintf (tf, "#define __crc32cr_table_h__\n\n");
fprintf (tf, "#define CRC32C_POLY 0x%08lX\n", CRC32C_POLY);
fprintf (tf, "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf (tf, "\nunsigned long crc_c[256] =\n{\n");
for (i = 0; i < 256; i++){
fprintf (tf, "0x%08lXL, ", build_crc_table (i));
if ((i & 3) == 3)
fprintf (tf, "\n");
}
fprintf (tf, "};\n\n#endif\n");
if (fclose (tf) != 0)
printf ("Unable to close <%s>." OUTPUT_FILE);
else
printf ("\nThe CRC-32c table has been written to <%s>.\n",
OUTPUT_FILE);
}
/* Example of crc insertion */
#include "crc32cr.h"
#include "crc32cr.h"
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = ~0L;
unsigned long result;
unsigned char byte0,byte1,byte2,byte3;
for (i = 0; i < length; i++){
CRC32C(crc32, buffer[i]);
}
result = ~crc32;
/* result now holds the negated polynomial remainder;
* since the table and algorithm is "reflected" [williams95].
* That is, result has the same value as if we mapped the message
* to a polynomial, computed the host-bit-order polynomial
* remainder, performed final negation, then did an end-for-end
* bit-reversal.
* Note that a 32-bit bit-reversal is identical to four inplace
* 8-bit reversals followed by an end-for-end byteswap.
* In other words, the bytes of each bit are in the right order,
* but the bytes have been byteswapped. So we now do an explicit
* byteswap. On a little-endian machine, this byteswap and
* the final ntohl cancel out and could be elided.
*/
byte0 = result & 0xff;
byte1 = (result>>8) & 0xff;
byte2 = (result>>16) & 0xff;
byte3 = (result>>24) & 0xff;
crc32 = ((byte0 << 24) |
(byte1 << 16) |
(byte2 << 8) |
byte3);
return ( crc32 );
}
int
insert_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned long crc32;
message = (SCTP_message *) buffer;
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
/* and insert it into the message */
message->common_header.checksum = htonl(crc32);
return 1;
}
int
validate_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned int i;
unsigned long original_crc32;
unsigned long crc32 = ~0L;
/* save and zero checksum */
message = (SCTP_message *) buffer;
original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
return ((original_crc32 == crc32)? 1 : -1);
}
Authors' Addresses
Jonathan Stone Room 446, Mail code 9040 Gates building 4A Stanford, Ca 94305
ジョナサンストーンルーム446、メールコード9040ゲートビル4Aスタンフォード、カリフォルニア94305
EMail: jonathan@dsg.stanford.edu
Randall R. Stewart 24 Burning Bush Trail. Crystal Lake, IL 60012 USA
ランドールR.スチュワート24バーニングブッシュトレイル。イリノイ州クリスタルレイク60012 USA
EMail: rrs@cisco.com
Douglas Otis 800 E. Middlefield Mountain View, CA 94043 USA
ダグラスオーティス800 E.ミドルフィールドマウンテンビュー、カリフォルニア94043 USA
EMail: dotis@sanlight.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。