約 5,373,841 件
https://w.atwiki.jp/shiren_dansamihai/pages/28.html
《TA部門》 順位 タイム 参加者 1位 15分14秒 philos 2位 15分18秒 Taka-tan 3位 16分10秒 プロナ 4位 16分47秒 IKAN 5位 17分45秒 アルベリ 6位 17分59秒 モコモン 7位 18分09秒 ねこ 8位 18分43秒 ポテト 9位 19分02秒 †執事Rose† 10位 19分04秒 ぶり大根 11位 19分24秒 ダンベル邪馬台国@8kg 12位 20分31秒 カッサーノ 13位 21分31秒 シェング 14位 24分35秒 華燕凛 15位 24分37秒 かずしボンバー 16位 24分47秒 jet 17位 25分17秒 だんさみ 18位 25分51秒 鉄雄 19位 26分10秒 nasuten 20位 26分14秒 ハートキャッチロリコン 21位 26分33秒 鬼怒川 22位 30分03秒 りん☆cookie 23位 30分47秒 へるにゃん 24位 31分20秒 ロリコン魔人 25位 31分43秒 チーズ野郎 26位 31分52秒 紅葉 27位 31分54秒 おこじょ 28位 33分22秒 ゆぅじ 29位 36分48秒 Mie 30位 37分39秒 トーシロ 31位 37分52秒 リク 32位 37分59秒 ロリコン爆弾 33位 38分16秒 sanno 34位 43分51秒 ストリーキング大好きな大人のおもちゃ君 35位 1時間44分14秒 にとうしんえるものかわいいほう 36位 22階まで行きました あちき 37位 シレン5予約RTA 4 24 24 きょんたん 38位 報告なし あんのうん 38位 報告なし コキャレット 《救出数部門》 順位 回数 参加者 1位 30回 IKAN 1位 30回 アルベリ 3位 29回 ぶり大根 4位 24回 だんさみ 5位 21回 ハートキャッチロリコン 5位 21回 Taka-tan 7位 20回 nasuten 8位 18回 プロナ 9位 14回 ロリコン魔人 9位 14回 紅葉 11位 13回 シェング 12位 12回 ポテト 13位 11回 おこじょ 14位 9回 philos 15位 8回 カッサーノ 16位 6回 ねこ 17位 5回 へるにゃん 17位 5回 モコモン 17位 5回 ロリコン爆弾 20位 4回 チーズ野郎 20位 4回 ゆぅじ 20位 4回 sanno 20位 4回 トーシロ 24位 3回 †執事Rose† 24位 3回 かずしボンバー 24位 3回 りん☆cookie 24位 3回 リク 24位 3回 Mie 29位 2回 ダンベル邪馬台国@8kg 29位 2回 鉄雄 29位 2回 華燕凛 29位 2回 ストリーキング大好きな大人のおもちゃ君 29位 2回 鬼怒川 34位 1回 jet 34位 1回 にとうしんえるものかわいいほう 36位 0回 きょんたん 36位 0回 あちき 36位 0回 あんのうん 36位 0回 コキャレット 《総合部門》 順位 参加者 合計得点 クリア回数 1位 IKAN 7500点 30回 2位 アルベリ 7302点 30回 3位 Taka-tan 6135点 21回 4位 ぶり大根 4510点 28回 5位 だんさみ 3582点 24回 6位 ポテト 3411点 12回 7位 プロナ 3290点 18回 8位 ハートキャッチロリコン 2987点 21回 9位 philos 2827点 9回 10位 カッサーノ 2067点 8回 11位 nasuten 1930点 20回 12位 シェング 1866点 13回 13位 ねこ 1597点 6回 14位 モコモン 1487点 5回 15位 †執事Rose† 881点 3回 16位 紅葉 765点 14回 17位 おこじょ 699点 11回 18位 かずしボンバー 590点 3回 19位 ダンベル邪馬台国@8kg 540点 2回 20位 ロリコン魔人 529点 14回 21位 鉄雄 415点 2回 22位 チーズ野郎 406点 4回 23位 華燕凛 384点 2回 24位 りん☆cookie 343点 3回 25位 鬼怒川 342点 2回 26位 へるにゃん 330点 5回 27位 ゆぅじ 320点 4回 28位 ロリコン爆弾 277点 5回 29位 jet 226点 1回 30位 sanno 211点 4回 31位 リク 192点 3回 32位 トーシロ 182点 4回 33位 Mie 156点 3回 34位 ストリーキング大好きな大人のおもちゃ君 47点 2回 35位 にとうしんえるものかわいいほう 5点 1回 36位 あちき 22階までいけました(*‘ω＾ *） 0回 37位 きょんたん シレン5予約RTA 4 24 24 0回 38位 あんのうん 0 0回 38位 コキャレット 0 0回
https://w.atwiki.jp/bemanilyrics/pages/34.html
beatmania IIDX 15 DJ TROOPERS 曲名 ジャンル アーティスト beatmania IIDX 15 DJ TROOPERS Be OK EUROBEAT good-cool ft. Florence Blue Rain TRANCE dj TAKA VS Ryu☆ Darling my LUV J-R&B DJ Yoshitaka feat.B-Agents Dazzlin Darlin HANDZ UP HHH I m In Love Again -DJ YOSHITAKA REMIX- TRANCE Remixed by DJ YOSHITAKA JOURNEY TO FANTASICA (IIDX LIMITED) THE WORLD GROOVE S.S.D.FANTASICA feat. EMI with ARATA Kick Out 仮面 E-DANCE POP 上野圭市(aka. Babyweapon,DJ SWAMI)feat.星野奏子 MAX LOVE LOVELY BUCHIAGE POP DJ YOSHITAKA feat.星野奏子 Now and Forever ENERGETIC TRANCE StripE vs MUNETICA feat.ARISA oratio HYMNUS 蓑舞衆 PROMISE FOR LIFE BALLAD TЁЯRA WORKS REMINISCENCE TRI EURO FANTASIA jun with Alison Rising in the Sun (original mix) UK HARDCORE kors k feat.Rie Ristaccia OUVERTURE Zektbach ROCK ME NOW RAGGA ROCK GUHROOVY fw. NO+CHIN Shades of Grey HARD TRANCE Fracus State Of The Art TECHNOTRONICA Sota Fujimori feat. cyborg AKEMI switch ULTIMATE J-POP DAISUKE ASAKURA ex.TЁЯRA the trigger of innocence ETHNOTRONICA Seiya Murai TROOPERS ULTIMATE CORE Des-TRACT エコ爺 80's EURO Y Co. 叶うまでは ELECTRIC AOR ウッチーズ 湘南族 -cannibal coast- ELECTRO Aural Vampire 華爛漫 -Flowers- HYPER JAPANESQUE 2 TЁЯRA マチ子の唄 EDUCATION AKIRA YAMAOKA CS beatmania IIDX 15 DJ TROOPERS Biometrics Warrior RAGGACORE GUHROOVY fw. NO+CHIN Cookie Bouquets BRAKE CORE L.E.D. vs TOMOSUKE fw.crimm
https://w.atwiki.jp/freegamematome/pages/17.html
ゲーム一覧(五十音順) あ行 か行 艦隊これくしょん～艦これ～ ガールフレンド(仮) Cookie Clicker さ行 た行 な行 は行 パズル ドラゴンズ ま行 マジョカマジョルナ や行 ら行 ラグナロクオンライン（ブレイザブリク） わ行
https://w.atwiki.jp/cookie_kaisetu/pages/1850.html
[部分編集] 概要 正式名称は『[Cookie☆10周年]東方合作企劃 天子的異變記事』（2020年02月15日）。 Momokoの作品。声あて動画ではないので声優はいない。 [部分編集] +登場キャラクター +大まかなストーリー [部分編集] ニコニコでの扱い [部分編集] 本スレでの扱い [部分編集] 実況での扱い
https://w.atwiki.jp/prima/pages/1627.html
Blogs on Deborah Cook #bf レパートリー 作曲家名（全角フルネーム）に置き換えてください [部分編集] 作曲家名（全角フルネーム）に置き換えてください 作品名（全角）に置き換えてください役名（全角）に置き換えてください Last Update 2011/01/30 04 07ページ先頭へ
https://w.atwiki.jp/ameba_pigg/pages/2060.html
手づくりクッキー whiteday_cookie_1003.swf 2010ホワイトデー 通販 パソコン 期間限定 男女共通 ファッション 小物 140アメG http //ameblo.jp/pigg-staff/entry-10476575800.html
https://w.atwiki.jp/scrapbooking/pages/90.html
ペーパーを決めて、ハサミやノリを使って好きな写真をレイアウトしていくScrapbookingも楽しいけれど、なかなか時間が作れない人や、Scrapbookingに必要な道具や材料を手に入れにくい環境の方にオススメ!! Digital Scrapbookingのサイト情報です。 下記に無い国内外のDigital Scrapbookingをご存じの方がいらっしゃいましたら、ここに↓↓↓書き込みお願い致します DigiScrapDepot.com (2009-02-07 07 35 09) scrapblog (2009-11-22 22 50 24) ADORNit Digital Scrapbooking (2009-11-22 22 52 19) Digiscrap Friends (2009-11-22 23 05 15) heritage makers (2009-11-24 09 43 54) サイト名 URL Bunny CatesChristina Renee DesignsComputer Scrapbook.comDigiFreeFeel Free to Digiscrappin' 気軽にデジタルスクラップブッキングScrapbook-BytesScrapbook-ElementsShabby Princess.comTWO Peas iN a BUCKeT tags plugin error ページが存在しているかを確認してください。
https://w.atwiki.jp/code_matome/pages/30.html
http //tools.ietf.org/html/rfc4960 Page 70まで Network Working Group R. Stewart, Ed. Request for Comments 4960 September 2007 Obsoletes 2960, 3309 Category Standards Track Stream Control Transmission Protocol Stream Control Transmission Protocol 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. このドキュメントはインターネットコミュニティにインターネット標準の規定とプロトコルと改良のための提案と議論の要求をする。 標準化状態とプロトコル状態はSTD1の最新版を参照してください。 このメモの配布には制限がない。 Abstract 概要 This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications. このドキュメントはRFC2960とRFC3309を廃止する。 このドキュメントはStream Control Transmission Protocol(SCTP)を記述する。 SCTPはIPネットワーク上で公衆無線網(PSTN)の音声メッセージを送信するために設計されているが、 より広い応用が可能。 SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users SCTPはIP等のコネクションレスパケット網上で動作する信頼性の高いプロトコルである。 SCTPはユーザーに下記のサービスを提供する。 -- acknowledged error-free non-duplicated transfer of user data, -- ユーザデータのエラー無し、重複無しの送信 -- data fragmentation to conform to discovered path MTU size, -- Path MTUサイズに適合するためのデータの分割(フラグメント) -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -- 個々のユーザメッセージの到達順序のオプションを使用した 複数ストリーム内のユーザメッセージの順序送信 -- optional bundling of multiple user messages into a single SCTP packet, and -- 単一SCTPパケットに複数のユーザメッセージを任意にバンドルする -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. -- アソシエーションによるマルチホーミングのサポートによるネットワークレベルの障害耐性。 The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. SCTPの設計は輻輳制御に適切な振る舞いと、フラッディング、マスカレード攻撃への耐性が含まれる。 Stewart Standards Track [Page 1] RFC 4960 Stream Control Transmission Protocol September 2007 Table of Contents 1. Introduction ....................................................5 1.導入 1.1. Motivation .................................................5 1.1. モチベーション 1.2. Architectural View of SCTP .................................6 1.2. SCTPのアーキテクチャ観点 1.3. Key Terms ..................................................6 1.3. 用語 1.4. Abbreviations .............................................10 1.4. 略語 1.5. Functional View of SCTP ...................................10 1.5 SCTPの機能的観点 1.5.1. Association Startup and Takedown ...................11 1.5.1. AssociationのStartupとTakedown 1.5.2. Sequenced Delivery within Streams ..................12 1.5.2. ストリーム内の順序送信 1.5.3. User Data Fragmentation ............................12 1.5.3. ユーザデータの分割(フラグメント) 1.5.4. Acknowledgement and Congestion Avoidance ...........12 1.5.4. Acknowledgementと輻輳回避 1.5.5. Chunk Bundling .....................................13 1.5.5. チャンクバンドリング 1.5.6. Packet Validation ..................................13 1.5.6 パケット検証 1.5.7. Path Management ....................................13 1.5.7. パスマネジメント 1.6. Serial Number Arithmetic ..................................14 1.6 シリアルナンバーの計算 1.7. Changes from RFC 2960 .....................................15 1.7. RFC2960からの変更点 2. Conventions ....................................................15 2. ルール 3. SCTP Packet Format .............................................15 3. SCTPパケットフォーマット 3.1. SCTP Common Header Field Descriptions .....................16 3.1. SCTP共通ヘッダーフィールドの説明 3.2. Chunk Field Descriptions ..................................17 3.2. チャンクフィールドの説明 3.2.1. Optional/Variable-Length Parameter Format ..........19 3.2.1. オプション/可変長パラメータのフォーマット 3.2.2. Reporting of Unrecognized Parameters ...............21 3.2.2. 認められていないパラメータの報告 3.3. SCTP Chunk Definitions ....................................21 3.3. SCTPチャンク定義 3.3.1. Payload Data (DATA) (0) ............................22 3.3.1. ペイロードデータ (DATA) (0) 3.3.2. Initiation (INIT) (1) ..............................24 3.3.2 Initialtion (INIT) (1) 3.3.2.1. Optional/Variable-Length Parameters in INIT ........................27 3.3.2.1 INITのオプション/可変長パラメータ 3.3.3. Initiation Acknowledgement (INIT ACK) (2) ..........30 3.3.3. Initiation Acknowledgement (INIT ACK) (2) 3.3.3.1. Optional or Variable-Length Parameters ....33 3.3.3.1. オプション/可変長パラメータ 3.3.4. Selective Acknowledgement (SACK) (3) ...............34 3.3.4 Selective Acknowledgement (SACK) (3) 3.3.5. Heartbeat Request (HEARTBEAT) (4) ..................38 3.3.5. Heartbeat Request (HEARTBEAT) (4) 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) ......39 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) 3.3.7. Abort Association (ABORT) (6) ......................40 3.3.7. Abort Association (ABORT) (6) 3.3.8. Shutdown Association (SHUTDOWN) (7) ................41 3.3.8. Shutdown Association (SHUTDOWN) (7) 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) ........41 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) 3.3.10. Operation Error (ERROR) (9) .......................42 3.3.10. Operation Error (ERROR) (9) 3.3.10.1. Invalid Stream Identifier (1) ............44 3.3.10.1 Invalid Stream Identifier (1) 3.3.10.2. Missing Mandatory Parameter (2) ..........44 3.3.10.2 Missing Mandatory Parameter (2) 3.3.10.3. Stale Cookie Error (3) ...................45 3.3.10.3. Stale Cokie Error (3) 3.3.10.4. Out of Resource (4) ......................45 3.3.10.4. Out of resource (4) 3.3.10.5. Unresolvable Address (5) .................46 3.3.10.5. Unresolvable Address (5) 3.3.10.6. Unrecognized Chunk Type (6) ..............46 3.3.10.6. Unrecognized Chunk Type (6) 3.3.10.7. Invalid Mandatory Parameter (7) ..........47 3.3.10.7. Invalid Mandatory Parameter (7) 3.3.10.8. Unrecognized Parameters (8) ..............47 3.3.10.8. Unrecognized Parameters (8) 3.3.10.9. No User Data (9) .........................48 3.3.10.9. No User Data (9) 3.3.10.10. Cookie Received While Shutting Down (10) ...............................48 3.3.10.10. Cookie Received While Shutting Down (10) Stewart Standards Track [Page 2] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.10.11. Restart of an Association with New Addresses (11) ......................49 3.3.10.11 Restart of an Association with New Addresses (11) 3.3.10.12. User-Initiated Abort (12) ...............49 3.3.10.12 User-Initiated Abort (12) 3.3.10.13. Protocol Violation (13) .................50 3.3.10.13 Protocol Violation (13) 3.3.11. Cookie Echo (COOKIE ECHO) (10) ....................50 3.3.11. Cookie Echo (COOKIE ECHO) (11) 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) ..........51 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) ........51 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) 4. SCTP Association State Diagram .................................52 4. SCTP Association状態遷移図 5. Association Initialization .....................................56 5. Association Initialization 5.1. Normal Establishment of an Association ....................56 5.1. Associationの通常の確立 5.1.1. Handle Stream Parameters ...........................58 5.1.1. Streamパラメータの処理 5.1.2. Handle Address Parameters ..........................58 5.1.2. Addressパラメータの処理 5.1.3. Generating State Cookie ............................61 5.1.3. State Cookieの生成 5.1.4. State Cookie Processing ............................62 5.1.4. State Cookieの処理 5.1.5. State Cookie Authentication ........................62 5.1.5. State Cookieの認証 5.1.6. An Example of Normal Association Establishment .....64 5.1.6. 通常のAssociation確立の例 5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and ..........................................65 5.2. 重複、予期しないINIT、INIT ACK、COOKIE ECHOの処理 5.2.1. INIT Received in COOKIE-WAIT or COOKIE-ECHOED State (Item B) .......................66 5.2.1. COOKIE-WAIT or COOKIE-ECHOED状態でのINIT受信 5.2.2. Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, .............................66 5.2.2. CLOSED、COOKIE-ECHOED以外の状態での予期しないINIT 5.2.3. Unexpected INIT ACK ................................67 5.2.3. 予期しないINIT ACK 5.2.4. Handle a COOKIE ECHO when a TCB Exists .............67 5.2.4. TCBが存在する場合のCOOKIE ECHOの処理 5.2.4.1. An Example of a Association Restart .......69 5.2.4.1 Association Restartの例 5.2.5. Handle Duplicate COOKIE-ACK. .......................71 5.2.5. COOKIE-ACK重複の処理 5.2.6. Handle Stale COOKIE Error ..........................71 5.2.6. COOKIE Error状態の処理 5.3. Other Initialization Issues ...............................72 5.3. 他のInitialization問題 5.3.1. Selection of Tag Value .............................72 5.3.1. Tag Valueの選択 5.4. Path Verification .........................................72 5.4. パス検証 6. User Data Transfer .............................................73 6. ユーザデータ送信 6.1. Transmission of DATA Chunks ...............................75 6.1. データチャンクの送信 6.2. Acknowledgement on Reception of DATA Chunks ...............78 6.2. データチャンク受信のAcknowledgement 6.2.1. Processing a Received SACK .........................81 6.2.1. SACK受信の処理 6.3. Management of Retransmission Timer ........................83 6.3. 再送タイマのマネジメント 6.3.1. RTO Calculation ....................................83 6.3.1. RTOの計算 6.3.2. Retransmission Timer Rules .........................85 6.3.2. 再送タイマのルール 6.3.3. Handle T3-rtx Expiration ...........................86 6.3.3. T3-rtx期限切れの処理 6.4. Multi-Homed SCTP Endpoints ................................87 6.4. Multi-Homed SCTPエンドポイント 6.4.1. Failover from an Inactive Destination Address ......88 6.4.1. 非アクティブな宛先アドレスからのFailover(障害迂回) 6.5. Stream Identifier and Stream Sequence Number ..............88 6.5. Stream Identifier and Stream Sequence Number 6.6. Ordered and Unordered Delivery ............................88 6.6. 順序送信と非順序送信 6.7. Report Gaps in Received DATA TSNs .........................89 6.7. 受信したDATA TSNのGaps報告 6.8. CRC32c Checksum Calculation ...............................90 6.8. CRC32チェックサムの計算 6.9. Fragmentation and Reassembly ..............................91 6.9. 分割と組み立て 6.10. Bundling .................................................92 6.10. バンドリング 7. Congestion Control .............................................93 7. 輻輳制御 7.1. SCTP Differences from TCP Congestion Control ..............94 7.1 TCP輻輳制御とSCTPの違い Stewart Standards Track [Page 3] RFC 4960 Stream Control Transmission Protocol September 2007 7.2. SCTP Slow-Start and Congestion Avoidance ..................95 7.2. SCTP Slow-Startと輻輳回避 7.2.1. Slow-Start .........................................96 7.2.1 Slow-Start 7.2.2. Congestion Avoidance ...............................97 7.2.2. 輻輳回避 7.2.3. Congestion Control .................................98 7.2.3. 輻輳制御 7.2.4. Fast Retransmit on Gap Reports .....................98 7.2.4. Gap ReportのFast Retransmit 7.3. Path MTU Discovery .......................................100 7.3. Path MTU Discovery 8. Fault Management ..............................................100 8. Fault Management 8.1. Endpoint Failure Detection ...............................100 8.1 エンドポイント障害検知 8.2. Path Failure Detection ...................................101 8.2. パス障害検知 8.3. Path Heartbeat ...........................................102 8.3. Path Heartbeat 8.4. Handle Out of the Blue Packets .........................104 8.4. Out of the Blue パケットの処理 8.5. Verification Tag .........................................105 8.5. Tagの検証 8.5.1. Exceptions in Verification Tag Rules ..............105 8.5.1. Tagルール検証の例外 9. Termination of Association ....................................106 9. Associationの終了 9.1. Abort of an Association ..................................107 9.1. AssociationのAbort 9.2. Shutdown of an Association ...............................107 9.2. AssociationのShutdown 10. Interface with Upper Layer ...................................110 10. 上位レイヤのInterface 10.1. ULP-to-SCTP .............................................110 10.1 上位レイヤからSCTP 10.2. SCTP-to-ULP .............................................120 10.2. SCTPから上位レイヤ 11. Security Considerations ......................................123 11. セキュリティの考慮 11.1. Security Objectives .....................................123 11.1 セキュリティの目的 11.2. SCTP Responses to Potential Threats .....................124 11.2. 脆弱性へのSCTPの対応 11.2.1. Countering Insider Attacks .......................124 11.2.1 Inside攻撃への対応 11.2.2. Protecting against Data Corruption in the Network ..........................................124 11.2.2 ネットワーク内のデータ破損に対する保護 11.2.3. Protecting Confidentiality .......................124 11.2.3 機密性の保護 11.2.4. Protecting against Blind Denial-of-Service Attacks ........................125 11.2.4. DoS攻撃からの保護 11.2.4.1. Flooding ................................125 11.2.4.1. Flooding 11.2.4.2. Blind Masquerade ........................126 11.2.4.2. Blind Masquerade 11.2.4.3. Improper Monopolization of Services .....127 11.2.4.3. 不適切なサービス独占 11.3. SCTP Interactions with Firewalls ........................127 11.3. ファイヤーウォールとSCTPの作用 11.4. Protection of Non-SCTP-Capable Hosts ....................128 11.4. SCTP非対応ホストの保護 12. Network Management Considerations ............................128 12. ネットワークマネジメントの考慮 13. Recommended Transmission Control Block (TCB) Parameters ......129 13. 推奨されるTCBパラメータ 13.1. Parameters Necessary for the SCTP Instance ..............129 13.1. SCTPインスタンスに必要なパラメータ 13.2. Parameters Necessary per Association (i.e., the TCB) ....129 13.2. Association(すなわちTCB)毎に必要なパラメータ 13.3. Per Transport Address Data ..............................131 13.3. Transport Adddress Data毎に 13.4. General Parameters Needed ...............................132 13.4. 一般的に必要なパラメータ 14. IANA Considerations ..........................................132 14. IANAの考慮 14.1. IETF-defined Chunk Extension ............................132 14.1 IETF定義のチャンク拡張 14.2. IETF-Defined Chunk Parameter Extension ..................133 14.2 IETF定義のチャンクパラメータ拡張 14.3. IETF-Defined Additional Error Causes ....................133 14.3. IETF定義の追加エラーCause 14.4. Payload Protocol Identifiers ............................134 14.4 ペイロードプロトコルの識別子 14.5. Port Numbers Registry ...................................134 14.5. ポート番号登録簿 15. Suggested SCTP Protocol Parameter Values .....................136 15. 提案されるSCTPプロトコルパラメータ値 16. Acknowledgements .............................................137 16. Acknowledgements Appendix A. Explicit Congestion Notification .....................139 Appendix A. 詳細な輻輳通知 Stewart Standards Track [Page 4] RFC 4960 Stream Control Transmission Protocol September 2007 Appendix B. CRC32c Checksum Calculation ..........................140 Appendix A. CRC32チェックサムの計算 Appendix C. ICMP Handling ........................................142 Appendix C. ICMPの処理 References .......................................................149 参照 Normative References ..........................................149 Normative References Informative References ........................................150 Informative References 1. Introduction This section explains the reasoning behind the development of the Stream Control Transmission Protocol (SCTP), the services it offers, and the basic concepts needed to understand the detailed description of the protocol. このセクションではStream Control Transmission Protocol (SCTP)が提供するサービス、 プロトコルの詳細を理解するために必要な基本的なコンセプトの背景を説明する。 This document obsoletes [RFC2960] and [RFC3309]. このドキュメントはRFC2960、RFC3309を廃止する。 1.1. Motivation 1.1. モチベーション TCP [RFC0793] has performed immense service as the primary means of reliable data transfer in IP networks. However, an increasing number of recent applications have found TCP too limiting, and have incorporated their own reliable data transfer protocol on top of UDP [RFC0768]. The limitations that users have wished to bypass include the following TCP [RFC0793]はIPネットワーク内の高信頼性のデータ転送の方法としてサービスを提供している。 しかし、最近のアプリケーションではTCPの多くの制限から、UDP[RFC0768]上に独自の信頼性のあるデータ転送プロトコルが組み込まれている。 ユーザが回避を望む制限には下記のものがある。 -- TCP provides both reliable data transfer and strict order-of- transmission delivery of data. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases, the head-of-line blocking offered by TCP causes unnecessary delay. -- TCPは信頼性のデータ転送と厳密なデータの順序伝送を提供する。 データお順序性が必要なアプリケーションもあるが、一部のアプリケーションでは順序制御のない信頼性のデータ転送を必要とする。 これらの両方のケースでは、TCPが提供するhead-of-line blocking(head-of-the-lineブロッキング（キュー送信によるブロッキング)が原因となる。 -- The stream-oriented nature of TCP is often an inconvenience. Applications must add their own record marking to delineate their messages, and must make explicit use of the push facility to ensure that a complete message is transferred in a reasonable time. -- TCPのストリーム指向は不便である。 アプリケーションはプッシュ機構を使用する、メッセージを送信する。 -- The limited scope of TCP sockets complicates the task of providing highly-available data transfer capability using multi-homed hosts. -- TCPの限られた範囲では、multi-homed hostsを使用した高信頼データ転送の提供が複雑になる。 -- TCP is relatively vulnerable to denial-of-service attacks, such as SYN attacks. --TCPはSYN攻撃のようなDoS攻撃に比較的脆弱である。 Transport of PSTN signaling across the IP network is an application for which all of these limitations of TCP are relevant. While this application directly motivated the development of SCTP, other applications may find SCTP a good match to their requirements. IPネットワーク上のPSTNシグナリングの転送は、TCPのこれらの制限が関係しているアプリケーションである。 これがSCTPの開発の動機であり、いくつかのアプリケーションの要件にもマッチする。 Stewart Standards Track [Page 5] RFC 4960 Stream Control Transmission Protocol September 2007 1.2. Architectural View of SCTP 1.2. SCTPのアーキテクチャ観点 SCTP is viewed as a layer between the SCTP user application ( SCTP user for short) and a connectionless packet network service such as IP. The remainder of this document assumes SCTP runs on top of IP. The basic service offered by SCTP is the reliable transfer of user messages between peer SCTP users. It performs this service within the context of an association between two SCTP endpoints. Section 10 of this document sketches the API that should exist at the boundary between the SCTP and the SCTP user layers. SCTPはSCTPユーザアプリケーション(略：SCTP user)とIPのようなコネクションレスのパケットサービスとみなされる。 SCTPはIP上で動作することを前提とする。 SCTPが提供する基本機能はSCTPユーザ間のユーザメッセージの信頼性転送である。 SCTPは2つのSCTPエンドポイント間のassociationのコンテキスト内でこのサービスを実行する。 Section 10ではSCTPとSCTPユーザレイヤ間の境界に存在するAPIを説明する。 SCTP is connection-oriented in nature, but the SCTP association is a broader concept than the TCP connection. SCTP provides the means for each SCTP endpoint (Section 1.3) to provide the other endpoint (during association startup) with a list of transport addresses (i.e., multiple IP addresses in combination with an SCTP port) through which that endpoint can be reached and from which it will originate SCTP packets. The association spans transfers over all of the possible source/destination combinations that may be generated from each endpoint s lists. SCTPはコネクション指向の性質があるが、SCTP associationはTCPコネクションより広範なコンセプトである。 SCTPは各SCTPエンドポイントにSCTPパケット転送するための転送アドレスのリスト(すなわちSCTPポートと組み合わせられた複数のIPアドレス)を他のエンドポイントに提供するための方法を提供する。 Associationは各エンドポイントのリストから生成されるsource/destinationのすべての組み合わせの転送に作成される。 _____________ _____________ | SCTP User | | SCTP User | | Application | | Application | |-------------| |-------------| | SCTP | | SCTP | | Transport | | Transport | | Service | | Service | |-------------| |-------------| | |One or more ---- One or more| | | IP Network |IP address \/ IP address| IP Network | | Service |appearances /\ appearances| Service | |_____________| ---- |_____________| SCTP Node A | -------- Network transport ------- | SCTP Node B Figure 1 An SCTP Association 1.3. Key Terms 1.3. 用語 Some of the language used to describe SCTP has been introduced in the previous sections. This section provides a consolidated list of the key terms and their definitions. SCTPを説明するために使用される用語は前の章で導入された。 この章では用語と定義を提供する。 o Active destination transport address A transport address on a peer endpoint that a transmitting endpoint considers available for receiving user messages. o Active destination transport address： 送信側エンドポイントがユーザデータを受信可能と判断しているエンドポイント間のトランスポートアドレス。 Stewart Standards Track [Page 6] RFC 4960 Stream Control Transmission Protocol September 2007 o Bundling An optional multiplexing operation, whereby more than one user message may be carried in the same SCTP packet. Each user message occupies its own DATA chunk. o Bundling（バンドリング） 複数のユーザメッセージを同じSCTPパケットで転送することによる多重化処理。 各ユーザメッセージは各データチャンクで送信される。 o Chunk A unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content. o Chunk（チャンク） チャンクヘッダとチャンクコンテンツで構成されるSCTPパケット内の情報の単位。 o Congestion window (cwnd) An SCTP variable that limits the data, in number of bytes, a sender can send to a particular destination transport address before receiving an acknowledgement. o Congestion window (cwnd)（輻輳ウィンドウ） データを制限するSCTPのパラメータ（byte数）で、送信側がacknowledgementを受信する前に宛先アドレスに送信できる。 o Cumulative TSN Ack Point The TSN of the last DATA chunk acknowledged via the Cumulative TSN Ack field of a SACK. o Cumulative TSN Ack Point（累積TSN Ack Point） 最後のデータチャンクのTSNはSACKの累積TSN AckフィールドでAckされる。 o Idle destination address An address that has not had user messages sent to it within some length of time, normally the HEARTBEAT interval or greater. o Idle destination address ユーザメッセージをHEARTBEATかそれ以上の時間に受信できなかったアドレス。 o Inactive destination transport address An address that is considered inactive due to errors and unavailable to transport user messages. o Inactive destination transport address エラーによりinactiveと判断され、ユーザメッセージの転送に使用できないアドレス。 o Message = user message Data submitted to SCTP by the Upper Layer Protocol (ULP). o Message = user message 上位レイヤ(ULP)からSCTPに送信されるデータ。 o Message Authentication Code (MAC) An integrity check mechanism based on cryptographic hash functions using a secret key. Typically, message authentication codes are used between two parties that share a secret key in order to validate information transmitted between these parties. In SCTP, it is used by an endpoint to validate the State Cookie information that is returned from the peer in the COOKIE ECHO chunk. The term MAC has different meanings in different contexts. SCTP uses this term with the same meaning as in [RFC2104]. o Message Authentication Code (MAC) 秘密鍵を用いたハッシュ関数に基づく、Integrityチェックのメカニズム。 通常、MACは秘密鍵を共有する2者間で送信された情報の検証のために使用される。 SCTPでは、COOKIE ECHOチャンクでピアから返信されたState Cookie情報を検証するためにエンドポイントで使用される。 o Network Byte Order Most significant byte first, a.k.a., big endian. o Network Byte Order（ネットワークバイトオーダー） 最上位byteが最初。別名ビッグエンディアン。 o Ordered Message A user message that is delivered in order with respect to all previous user messages sent within the stream on which the message was sent. o Ordered Message（順序制御されたメッセージ） メッセージが送信されたストリーム内で順序通りに転送されたユーザメッセージ。 o Outstanding TSN (at an SCTP endpoint) A TSN (and the associated DATA chunk) that has been sent by the endpoint but for which it has not yet received an acknowledgement. o Outstanding TSN (at an SCTP endpoint)（SCTPエンドポイントの未処理のTSN） エンドポイントにより送信されたが、acknowledgementを受信していないTSNおよび関連するデータチャンク。 Stewart Standards Track [Page 7] RFC 4960 Stream Control Transmission Protocol September 2007 o Path The route taken by the SCTP packets sent by one SCTP endpoint to a specific destination transport address of its peer SCTP endpoint. Sending to different destination transport addresses does not necessarily guarantee getting separate paths. o Path SCTPエンドポイント間の特定の宛先トランスポートアドレスへのSCTPエンドポイントが送信したSCTPパケットが通るルート。 異なる宛先トランスポートアドレスに送信することは、必ずしもパスを分けることを必要としない。 o Primary Path The primary path is the destination and source address that will be put into a packet outbound to the peer endpoint by default. The definition includes the source address since an implementation MAY wish to specify both destination and source address to better control the return path taken by reply chunks and on which interface the packet is transmitted when the data sender is multi-homed. o Primary Path Primary pathはエンドポイント間の送信にデフォルトで使用される宛先と送信元のアドレス。 定義は送信元アドレスと宛先アドレスを含んでいる、それは、実装ではマルチホーム送信のときにパケットを送信する送信元・宛先の両方のアドレスを指定するため。。 o Receiver Window (rwnd) An SCTP variable a data sender uses to store the most recently calculated receiver window of its peer, in number of bytes. This gives the sender an indication of the space available in the receiver s inbound buffer. o Receiver Window (rwnd) SCTP変数でデータ送信側がエンドポイント間の最新の受信ウィンドウを保持するために使用するバイト数。 送信者に受信者の受信バッファの使用可能な領域の値を示す。 o SCTP association A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time. o SCTP association SCTPエンドポイント間のプロトコルの関係。 2つのSCTPエンドポイントとVerification Tag、TSNなどのプロトコル状態情報から構成される。 Associationはassociationのエンドポイントのトランスポートアドレスを使って一意に識別できる。 2つのSCTPエンドポイントある時点でその間に複数のSCTP associationを持ってはいけない。 o SCTP endpoint The logical sender/receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint. o SCTP endpoint SCTPパケットの論理的な送信者/受信者。 マルチホームホストでは、SCTPエンドポイントは、送信元トランスポートアドレスと宛先トランスポートアドレスの組である。 SCTPエンドポイントで使用されるトランスポートアドレスは同じポート番号を使用する必要があるが、複数のIPアドレスを使用することができる。 SCTPに使用されるトランスポートアドレスは別のSCTPエンドポイントで使用することはできない。 つまり、トランスポートアドレスはSCTPエンドポイントで一意である。 o SCTP packet (or packet) The unit of data delivery across the interface between SCTP and the connectionless packet network (e.g., IP). An SCTP packet includes the common SCTP header, possible SCTP control chunks, and user data encapsulated within SCTP DATA chunks. o SCTP packet (or packet) SCTPとコネクションレスパケット網(例 IP)間のインタフェース間のデータ送信ユニット。 SCTPパケットはSCTPヘッダを含み、場合によりSCTP制御チャンク、SCTPデータチャンク（カプセル化ユーザデータを含む）も含まれる。 o SCTP user application (SCTP user) The logical higher-layer application entity which uses the services of SCTP, also called the Upper-Layer Protocol (ULP). o SCTP user application (SCTP user) SCTPを使用する論理的に上位のアプリケーション。Upper-Layer Protocol(ULP)とも呼ばれる。 Stewart Standards Track [Page 8] RFC 4960 Stream Control Transmission Protocol September 2007 o Slow-Start Threshold (ssthresh) An SCTP variable. This is the threshold that the endpoint will use to determine whether to perform slow start or congestion avoidance on a particular destination transport address. Ssthresh is in number of bytes. o Slow-Start Threshold (ssthresh) SCTP変数。エンドポイントが特定の宛先トランスポートアドレスにスロースタートや輻輳回避を実行するかを決定するための閾値。ssthreshはバイト数。 o Stream A unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service. o Stream 2つのSCTPエンドポイント間で確立される一方向の論理チャネルで、すべてのユーザメッセージが順序送信（非順序送信のServiceは除く）により送信される。 Note The relationship between stream numbers in opposite directions is strictly a matter of how the applications use them. It is the responsibility of the SCTP user to create and manage these correlations if they are so desired. 対向のストリームとの関連はアプリケーションが管理する。 o Stream Sequence Number A 16-bit sequence number used internally by SCTP to ensure sequenced delivery of the user messages within a given stream. One Stream Sequence Number is attached to each user message. o Stream Sequence Number ストリーム内のユーザメッセージの順序送信を保証するため、SCTPが使用する16ビットのシーケンス番号。 Stream Sequence Numberは各ユーザメッセージに付与される。 o Tie-Tags Two 32-bit random numbers that together make a 64-bit nonce. These tags are used within a State Cookie and TCB so that a newly restarting association can be linked to the original association within the endpoint that did not restart and yet not reveal the true Verification Tags of an existing association. o Tie-Tags 64bitのnonceを作る32bitの乱数。 タグは、associationにリンクできるようにState CookieとTCBで使用される。 o Transmission Control Block (TCB) An internal data structure created by an SCTP endpoint for each of its existing SCTP associations to other SCTP endpoints. TCB contains all the status and operational information for the endpoint to maintain and manage the corresponding association. o Transmission Control Block (TCB) 他のSCTPエンドポイントへ各SCTP associationのためにSCTPエンドポイントによって作成された内部データ構造。 TCBはassociationを維持、管理するための状態情報と運用状態のすべてを含んでいる。 o Transmission Sequence Number (TSN) A 32-bit sequence number used internally by SCTP. One TSN is attached to each chunk containing user data to permit the receiving SCTP endpoint to acknowledge its receipt and detect duplicate deliveries. o Transmission Sequence Number (TSN) SCTPが内部的に使用する32ビットのシーケンス番号。 TSNは受信の確認と重複受信検出を受信側SCTPエンドポイントが可能なようにユーザデータを含むチャンクに付与される。 o Transport address A transport address is traditionally defined by a network-layer address, a transport-layer protocol, and a transport-layer port number. In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the transport protocol). o Transport address ネットワークレイヤアドレス（ネットワーク層）とポート番号（トランスポート層）。 o Unacknowledged TSN (at an SCTP endpoint) A TSN (and the associated DATA chunk) that has been received by the endpoint but for which an acknowledgement has not yet been sent. Or in the opposite case, for a packet that has been sent but no acknowledgement has been received. o Unacknowledged TSN (at an SCTP endpoint) エンドポイントで受信されたが、acknowledgementがまだ送信されていないTSN。 送信側ではパケットは送信されたが、acknowledgementがまだ受信されていない。 Stewart Standards Track [Page 9] RFC 4960 Stream Control Transmission Protocol September 2007 o Unordered Message Unordered messages are unordered with respect to any other message; this includes both other unordered messages as well as other ordered messages. An unordered message might be delivered prior to or later than ordered messages sent on the same stream. o Unordered Message（順序制御されていないメッセージ） 非順序送信の他のメッセージ（非順序送信メッセージ or 順序送信メッセージ）に関して非順序送信である。 非順序送信メッセージは同じストリームで送信された順序送信メッセージの前後に送信される。 o User message The unit of data delivery across the interface between SCTP and its user. o User message SCTPとユーザ間のインタフェースのデータ送信単位。 o Verification Tag A 32-bit unsigned integer that is randomly generated. The Verification Tag provides a key that allows a receiver to verify that the SCTP packet belongs to the current association and is not an old or stale packet from a previous association. o Verification Tag ランダムに生成される32bit非負整数。 Verification Tagは受信者のSCTPパケットが現在のassociationに属し、以前のassociationの古いパケットか確認するキーを提供する。 1.4. Abbreviations MAC - Message Authentication Code [RFC2104] RTO - Retransmission Timeout RTT - Round-Trip Time RTTVAR - Round-Trip Time Variation SCTP - Stream Control Transmission Protocol SRTT - Smoothed RTT TCB - Transmission Control Block TLV - Type-Length-Value coding format TSN - Transmission Sequence Number ULP - Upper-Layer Protocol 1.5. Functional View of SCTP 1.5 SCTPの機能的観点 The SCTP transport service can be decomposed into a number of functions. These are depicted in Figure 2 and explained in the remainder of this section. SCTPトランスポートサービスはいくつかの機能に分割できる。 これらは図2に示されるとおり、本章で説明される。 Stewart Standards Track [Page 10] RFC 4960 Stream Control Transmission Protocol September 2007 SCTP User Application SCTPユーザアプリケーション ----------------------------------------------------- __________________________________________ | || Sequenced Delivery | | Association || within Streams | | ||____________________| | Startup |Stream内の順序送信 | |______________________________ | and || User Data Fragmentation | | ||____________________________| | Takedown |ユーザデータのフラグメント | |______________________________ | || Acknowledgement | | || and | | || Congestion Avoidance | | ||____________________________| | |Acknowledgementと輻輳回避 | |_______________________________ | || Chunk Bundling | | ||_____________________________| | | | |___________________________________ | || Packet Validation | | ||_________________________________| | | | |_______________________________ | || Path Management | |__________________||______________________________| Figure 2 Functional View of the SCTP Transport Service Figure 2 SCTP Transport Serviceの機能観点 1.5.1. Association Startup and Takedown 1.5.1. Association Startup and Takedown An association is initiated by a request from the SCTP user (see the description of the ASSOCIATE (or SEND) primitive in Section 10). アソシエーションはSCTPユーザからの要求で初期化される。 （ASSOCIATE SENDのプリミティブはSection 10参照。） A cookie mechanism, similar to one described by Karn and Simpson in [RFC2522], is employed during the initialization to provide protection against synchronization attacks. The cookie mechanism uses a four-way handshake, the last two legs of which are allowed to carry user data for fast setup. The startup sequence is described in Section 5 of this document. RFC2522でKarn and Simpsonが述べたのと同じcookieメカニズムがsyn attackに対する保護を提供するため初期化中に使用される。 4-way handshakeのcookieメカニズムは、fast setupでユーザデータを送信する最後の2 legを使う。 startupシーケンスはSection 5で述べられる。 SCTP provides for graceful close (i.e., shutdown) of an active association on request from the SCTP user. See the description of the SHUTDOWN primitive in Section 10. SCTP also allows ungraceful close (i.e., abort), either on request from the user (ABORT Stewart Standards Track [Page 11] RFC 4960 Stream Control Transmission Protocol September 2007 primitive) or as a result of an error condition detected within the SCTP layer. Section 9 describes both the graceful and the ungraceful close procedures. SCTPはSCTPユーザからの要求によるアクティブなassociationのgraceful 切断(shutdown)を提供する。 SHUTDOWNプリミティブはSection 10参照。SCTPはユーザからの要求やSCTPレイヤで検出されたエラーによるungraceful 切断(abort)も許可する。 Section 9ではgraceful切断、ungraceful切断を説明する。 SCTP does not support a half-open state (like TCP) wherein one side may continue sending data while the other end is closed. When either endpoint performs a shutdown, the association on each peer will stop accepting new data from its user and only deliver data in queue at the time of the graceful close (see Section 9). SCTPはTCPのようなhalf-open state（片方が切断されている間にもう片方がデータを送信する）をサポートしない。 エンドポイントの片方がshutdownすると、各peerのassociationは新しいデータの受け入れを停止し、graceful切断時にキューのデータのみを送信する。 1.5.2. Sequenced Delivery within Streams The term stream is used in SCTP to refer to a sequence of user messages that are to be delivered to the upper-layer protocol in order with respect to other messages within the same stream. This is in contrast to its usage in TCP, where it refers to a sequence of bytes (in this document, a byte is assumed to be 8 bits). streamは同じストリーム内の他のメッセージとの間で順番に上位レイヤに送信されるユーザメッセージのsequenceを表すためにSCTPで使われる。これはbyteのsequenceを表すTCPの使用方法とは対照的である。 The SCTP user can specify at association startup time the number of streams to be supported by the association. This number is negotiated with the remote end (see Section 5.1.1). User messages are associated with stream numbers (SEND, RECEIVE primitives, Section 10). Internally, SCTP assigns a Stream Sequence Number to each message passed to it by the SCTP user. On the receiving side, SCTP ensures that messages are delivered to the SCTP user in sequence within a given stream. However, while one stream may be blocked waiting for the next in-sequence user message, delivery from other streams may proceed. SCTPユーザはassociation startup時にサポートされるassociation数を指定できる。 その数はremote end（Section 5.1.1）でネゴシエーションされる。 ユーザメッセージはstream number(SEND、RECEIVEプリミティブ。Section 10)に関連付けられる。 内部的には、SCTPはSCTPユーザから渡された各メッセージにStream Sequence Numberを付与する。 受信側ではSCTPはメッセージが指定されたstream内のsequenceのSCTPユーザに送信されることを保証する。 streamが次のsequence内のユーザメッセージ待ちのためブロック中、別のstreamの送信を進めてよい。 SCTP provides a mechanism for bypassing the sequenced delivery service. User messages sent using this mechanism are delivered to the SCTP user as soon as they are received. SCTPはsequence deliveryのバイパスのためのメカニズムを提供する。 このメカニズムを使用して送信されたユーザメッセージは、受信したSCTPユーザにすぐに届けられる。 1.5.3. User Data Fragmentation When needed, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the path MTU. On receipt, fragments are reassembled into complete messages before being passed to the SCTP user. SCTPは下層に渡すSCTPパケットのパスMTUのを保証するためユーザメッセージをfragmentする。 受信ではfragmentはSCTPユーザに渡される前に元のメッセージにreassembleされる。 1.5.4. Acknowledgement and Congestion Avoidance SCTP assigns a Transmission Sequence Number (TSN) to each user data fragment or unfragmented message. The TSN is independent of any Stream Sequence Number assigned at the stream level. The receiving end acknowledges all TSNs received, even if there are gaps in the sequence. In this way, reliable delivery is kept functionally separate from sequenced stream delivery. SCTPはTransmission Sequence Number(TSN)を各ユーザデータメッセージに付与する。 TSNはstream levelで割り当てられたStream Sequence Numberとは無関係である。 受信側はsequenceにgapがあってもすべてのTSNをacknowledgeする。 これにより、信頼性送信と順序送信の機能分割が保たれる。 Stewart Standards Track [Page 12] RFC 4960 Stream Control Transmission Protocol September 2007 The acknowledgement and congestion avoidance function is responsible for packet retransmission when timely acknowledgement has not been received. Packet retransmission is conditioned by congestion avoidance procedures similar to those used for TCP. See Section 6 and Section 7 for a detailed description of the protocol procedures associated with this function. acknowledgementと輻輳回避はacknowledgementが受信できない時のパケット再送を担う。 パケット再送はTCPで使用されるものと同様の輻輳回避プロシージャで調整される。 この機能に関連するプロシージャの詳細はSection6、7を参照。 1.5.5. Chunk Bundling As described in Section 3, the SCTP packet as delivered to the lower layer consists of a common header followed by one or more chunks. Each chunk may contain either user data or SCTP control information. The SCTP user has the option to request bundling of more than one user message into a single SCTP packet. The chunk bundling function of SCTP is responsible for assembly of the complete SCTP packet and its disassembly at the receiving end. Section 3で説明したように、SCTP下位レイヤに送信されるSCTPパケットは1つ以上のチャンクと共通ヘッダで構成される。 各チャンクはSCTP control informationまたはユーザデータを含んでよい。 SCTPユーザは一つのSCTPパケットに複数のユーザデータのbundlingを要求するオプションをもつ。 チャンクbundling機能はSCTPパケットの分割と受信側での組み立てを担う。 During times of congestion, an SCTP implementation MAY still perform bundling even if the user has requested that SCTP not bundle. The user s disabling of bundling only affects SCTP implementations that may delay a small period of time before transmission (to attempt to encourage bundling). When the user layer disables bundling, this small delay is prohibited but not bundling that is performed during congestion or retransmission. 輻輳時、SCTPの実装ではユーザがSCTP bundleされないことを要求した場合でもbundlingを実行してもよい。 bundlingのユーザによる無効化は送信前のわずかな遅延に関するSCTPの実装に影響を与える（bundlingを試みるため）。 ユーザ層がbudlingを無効化したらわずかな遅延を抑えられるが、輻輳時や再送時にbundlingが実行されない。 1.5.6. Packet Validation A mandatory Verification Tag field and a 32-bit checksum field (see Appendix B for a description of the CRC32c checksum) are included in the SCTP common header. The Verification Tag value is chosen by each end of the association during association startup. Packets received without the expected Verification Tag value are discarded, as a protection against blind masquerade attacks and against stale SCTP packets from a previous association. The CRC32c checksum should be set by the sender of each SCTP packet to provide additional protection against data corruption in the network. The receiver of an SCTP packet with an invalid CRC32c checksum silently discards the packet. 必須のVerificaton Tagフィールドと32bitチェックサムフィールド(CRC32チェックサムの詳細はAppenix B参照)はSCTP common headerに含まれる。 Verification Tagの値はassociation startup時に各association間で選択される。 正しいVerification Tagなしで受信したパケットはblind masquerade attackと古いassociationパケットとして削除される。 CRC32チェックサムはネットワークによるデータ破損に対する保護を提供するため各SCTPパケットの送信者によって送信されること。 不正なCRCチェックサムのSCTPパケットの受信者はパケットを破棄する。 1.5.7. Path Management The sending SCTP user is able to manipulate the set of transport addresses used as destinations for SCTP packets through the primitives described in Section 10. The SCTP path management function chooses the destination transport address for each outgoing SCTP packet based on the SCTP user s instructions and the currently perceived reachability status of the eligible destination set. The path management function monitors reachability through heartbeats Stewart Standards Track [Page 13] RFC 4960 Stream Control Transmission Protocol September 2007 when other packet traffic is inadequate to provide this information and advises the SCTP user when reachability of any far-end transport address changes. The path management function is also responsible for reporting the eligible set of local transport addresses to the far end during association startup, and for reporting the transport addresses returned from the far end to the SCTP user. SCTP送信者はSection10で説明されるプリミティブによりSCTPパケットの宛先として使用されるtransport addressのsetを操作できる。 SCTP path managementはSCTPユーザの指定や宛先の到達性の状態に基づき、各送信SCTPパケットの宛先transport addressを選択する。 path managementはパケットトラヒックの情報が不足している場合、heartbeatで到達性を監視し、SCTPユーザに他のtransport addressの到達性の変化を通知する。 path managementはassociation startup時に相手へのlocal transport addressを通知と、相手のSCTPユーザから返されたtransport addressを報告を担い。 At association startup, a primary path is defined for each SCTP endpoint, and is used for normal sending of SCTP packets. association startup時、primary pathは各SCTP間に定義され、通常のSCTPパケット送信に使用される。 On the receiving end, the path management is responsible for verifying the existence of a valid SCTP association to which the inbound SCTP packet belongs before passing it for further processing. 受信側ではpath managementは受信したSCTPパケットをその後の処理に渡す前に正しいSCTP associationであるかの確認を担う。 Note Path Management and Packet Validation are done at the same time, so although described separately above, in reality they cannot be performed as separate items. Path ManagementとPacket Validationは同時には実行されるため、実際は上記に分けた説明が別々に実行されることはない。 1.6. Serial Number Arithmetic It is essential to remember that the actual Transmission Sequence Number space is finite, though very large. This space ranges from 0 to 2**32 - 1. Since the space is finite, all arithmetic dealing with Transmission Sequence Numbers must be performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. There are some subtleties to computer modulo arithmetic, so great care should be taken in programming the comparison of such values. When referring to TSNs, the symbol = means less than or equal (modulo 2**32). Transmission Sequence Number空間は非常に大きいが有限（0～2^32-1）である。 有限であるため、Transmission Sequence Numberを扱う演算はmod 2^32をする必要がある。 この演算は0～2^32-1のサイクルとしてシーケンス番号を保持する。 moduloの計算には微妙な点があるため、値の比較には注意が必要である。 TSNを参照する際は = は以下(mod 2^32)を意味する。 Comparisons and arithmetic on TSNs in this document SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32. RFC1982で定義されるSERIAL_BITS = 32のSerial Number ArithmeticをTSNの比較や計算に使用すること。 An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more than 2**31 - 1 above the beginning TSN of its current send window. Doing so will cause problems in comparing TSNs. endpointは送信ウィンドウでTSN 2^31-1を超えるデータチャンクを送信しないこと。 そうするとTSNの計算で問題が生じる。 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. That is, the next TSN a DATA chunk MUST use after transmitting TSN = 2*32 - 1 is TSN = 0. TSNは2^32-1に達すると重複する。 つまり次のTSN=0はTSN=2^32-1を送信した後に使用すること。 Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16. All other arithmetic and comparisons in this document use normal arithmetic. RFC1982で定義されるSERIAL_BITS = 16のSerial Number ArithmeticをStream Sequence Numberを計算に使用すること。 このドキュメントのその他の計算、比較は通常の算術演算を使用する。 Stewart Standards Track [Page 14] RFC 4960 Stream Control Transmission Protocol September 2007 1.7. Changes from RFC 2960 SCTP was originally defined in [RFC2960], which this document obsoletes. Readers interested in the details of the various changes that this document incorporates are asked to consult [RFC4460]. SCTPはこのドキュメントが廃止したRFC2960で定義された。 このドキュメントに組み込まれた変更の詳細はRFC4460を参照。 2. Conventions The key words MUST , MUST NOT , REQUIRED , SHALL , SHALL NOT , SHOULD , SHOULD NOT , RECOMMENDED , MAY , and OPTIONAL in this document are to be interpreted as described in RFC 2119 [RFC2119]. このドキュメントのキーワード MUST , MUST NOT , REQUIRED , SHALL , SHALL NOT , SHOULD , SHOULD NOT , RECOMMENDED , MAY , and OPTIONAL はRFC2119で説明されるように解釈されること。 3. SCTP Packet Format An SCTP packet is composed of a common header and chunks. A chunk contains either control information or user data. SCTPパケットはcommon headerとチャンクで構成される。チャンクはcontrol informationまたはユーザデータを含む。 The SCTP packet format is shown below SCTPパケットフォーマットを下記に示す。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Multiple chunks can be bundled into one SCTP packet up to the MTU size, except for the INIT, INIT ACK, and SHUTDOWN COMPLETE chunks. These chunks MUST NOT be bundled with any other chunk in a packet. See Section 6.10 for more details on chunk bundling. INIT、INIT ACKとSHUTDOWN COMPLETEのチャンク除き、MTUサイズまで1つのSCTPパケットにチャンクをbundleできる。 これらのチャンクはパケット内の他のチャンクをbundleしないこと。 chunk bundlingの詳細はSection 6.10参照。 If a user data message doesn t fit into one SCTP packet it can be fragmented into multiple chunks using the procedure defined in Section 6.9. ユーザメッセージが1つのSCTPパケットに収まらない場合、Section 6.9のプロシージャを用いて複数のチャンクにfragmentできる。 All integer fields in an SCTP packet MUST be transmitted in network byte order, unless otherwise stated. SCTPパケット内のすべての整数フィールドはネットワークバイトオーダーで送信されること。 Stewart Standards Track [Page 15] RFC 4960 Stream Control Transmission Protocol September 2007 3.1. SCTP Common Header Field Descriptions SCTP Common Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Number | Destination Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Verification Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Port Number 16 bits (unsigned integer) This is the SCTP sender s port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port, and possibly the destination IP address to identify the association to which this packet belongs. The port number 0 MUST NOT be used. SCTP送信者のポート番号。 パケットのassociatinを識別するため送信元、宛先のIPアドレス、SCTP宛先ポートとともに受信者に使用される。 ポート番号0は使わないこと。 Destination Port Number 16 bits (unsigned integer) This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application. The port number 0 MUST NOT be used. パケットの宛先ポート番号。 受信側が受信エンドポイント/アプリケーションにSCTPパケットをde-multiplexするために使用する。 ポート番号0は使わないこと。 Verification Tag 32 bits (unsigned integer) The receiver of this packet uses the Verification Tag to validate the sender of this SCTP packet. On transmit, the value of this Verification Tag MUST be set to the value of the Initiate Tag received from the peer endpoint during the association initialization, with the following exceptions パケットの受信者が送信者のSCTPパケットの検証のためにVerification Tagを使用する。 送信時、Verification Tagはassociation initialization中にピアエンドポイントから受信したInitiate Tagの値を設定すること。 下記の例外は除く。 - A packet containing an INIT chunk MUST have a zero Verification Tag. INITチャンクを含むパケットはzero Verification Tagであること。 - A packet containing a SHUTDOWN COMPLETE chunk with the T bit set MUST have the Verification Tag copied from the packet with the SHUTDOWN ACK chunk. T bitのSHUTDOWN COMPLETEチャンクを含むパケットは、SHUTDOWN ACKチャンクパケットからコピーされたVerification Tagであること。 - A packet containing an ABORT chunk may have the verification tag copied from the packet that caused the ABORT to be sent. For details see Section 8.4 and Section 8.5. ABORTチャンクを含むパケットは、ABORTが送信される原因となったパケットからコピーされたVerification Tagをコピーすること。 詳細はSection 8.4、8.5を参照。 Stewart Standards Track [Page 16] RFC 4960 Stream Control Transmission Protocol September 2007 An INIT chunk MUST be the only chunk in the SCTP packet carrying it. INITチャンクはこれを送信するSCTPの唯一のチャンクであること。 Checksum 32 bits (unsigned integer) This field contains the checksum of this SCTP packet. Its calculation is discussed in Section 6.8. SCTP uses the CRC32c algorithm as described in Appendix B for calculating the checksum. SCTPパケットのチェックサム。 計算方法はSection 6.8で述べる。 SCTPはCRC32アルゴリズム（Appendix B）を用いる。 3.2. Chunk Field Descriptions The figure below illustrates the field format for the chunks to be transmitted in the SCTP packet. Each chunk is formatted with a Chunk Type field, a chunk-specific Flag field, a Chunk Length field, and a Value field. SCTPパケットで送信されるチャンクフィールドフォーマットを示す。 各チャンクはChunk Type、Chunk-specific Flag、Chunk Length、Chunk Valueから構成される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Chunk Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Type 8 bits (unsigned integer) This field identifies the type of information contained in the Chunk Value field. It takes a value from 0 to 254. The value of 255 is reserved for future use as an extension field. Chunk Value filedの情報の種類を識別する。 0～254をとる。255は今後の拡張のための予約。 The values of Chunk Types are defined as follows Chunk Typesは下記のように定義される。 ID Value Chunk Type ----- ---------- 0 - Payload Data (DATA) 1 - Initiation (INIT) 2 - Initiation Acknowledgement (INIT ACK) 3 - Selective Acknowledgement (SACK) 4 - Heartbeat Request (HEARTBEAT) 5 - Heartbeat Acknowledgement (HEARTBEAT ACK) 6 - Abort (ABORT) 7 - Shutdown (SHUTDOWN) 8 - Shutdown Acknowledgement (SHUTDOWN ACK) 9 - Operation Error (ERROR) 10 - State Cookie (COOKIE ECHO) 11 - Cookie Acknowledgement (COOKIE ACK) Stewart Standards Track [Page 17] RFC 4960 Stream Control Transmission Protocol September 2007 12 - Reserved for Explicit Congestion Notification Echo (ECNE) 13 - Reserved for Congestion Window Reduced (CWR) 14 - Shutdown Complete (SHUTDOWN COMPLETE) 15 to 62 - available 63 - reserved for IETF-defined Chunk Extensions 64 to 126 - available 127 - reserved for IETF-defined Chunk Extensions 128 to 190 - available 191 - reserved for IETF-defined Chunk Extensions 192 to 254 - available 255 - reserved for IETF-defined Chunk Extensions Chunk Types are encoded such that the highest-order 2 bits specify the action that must be taken if the processing endpoint does not recognize the Chunk Type. Chunk Typeは上位2bitがエンドポイントがChunk Typeを認識しない場合のアクションを指定するためにエンコードされる。 00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it. SCTPパケット処理を停止し、破棄する。Chunkを処理しない。 01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized chunk in an Unrecognized Chunk Type . SCTPパケット処理を停止し、破棄する。Chunkを処理せず、Unrecognized Chunk TypeとしてChunkを報告する。 10 - Skip this chunk and continue processing. Chunkをスキップし、処理を継続する。 11 - Skip this chunk and continue processing, but report in an ERROR chunk using the Unrecognized Chunk Type cause of error. Chunkをスキップし、処理を継続する。Unrecognized Chunk Typeを使用したERROR Chunkで報告する。 Note The ECNE and CWR chunk types are reserved for future use of Explicit Congestion Notification (ECN); see Appendix A. ECNEとCWR chunkタイプはECN(明示的輻輳通知)で使用するためreserveされている。Appendix A参照。 Chunk Flags 8 bits The usage of these bits depends on the Chunk type as given by the Chunk Type field. Unless otherwise specified, they are set to 0 on transmit and are ignored on receipt. Chunk Type fieldで指定されたChunk typeに応じて使用される。 特に規定がない場合、送信側で0が設定され、受信側で無視される。 Chunk Length 16 bits (unsigned integer) This value represents the size of the chunk in bytes, including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any chunk padding. Chunk Value、Chunk Length、Chunk Flags、Chunk Typesのバイト単位のchunkサイズを表す。 Chunk Value fieldが0の場合、Lengthは4に設定される。 Chunk Lengthはchunk paddingをカウントしない。 Stewart Standards Track [Page 18] RFC 4960 Stream Control Transmission Protocol September 2007 Chunks (including Type, Length, and Value fields) are padded out by the sender with all zero bytes to be a multiple of 4 bytes long. This padding MUST NOT be more than 3 bytes in total. The Chunk Length value does not include terminating padding of the chunk. However, it does include padding of any variable-length parameter except the last parameter in the chunk. The receiver MUST ignore the padding. Chunkは4バイトの倍数であるために、0バイトで送信者によってpaddingされる。 paddingは3バイトを超えてはいけない。 Chunk Lengthはchunkの終端のpaddingを含んでいない。 受信者はpaddingを無視すること。 Note A robust implementation should accept the chunk whether or not the final padding has been included in the Chunk Length. robustな実装ではpaddingがChunk Lengthに含まれているか確認する必要がある。 Chunk Value variable length The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type. Chunk Value fieldはChunkで送信される情報が含まれている。 使用方法とフォーマットはChunk Typeに依存する。 The total length of a chunk (including Type, Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes, and this padding is not included in the Chunk Length field. The sender MUST NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes. chunkの合計のサイズは4バイトの倍数であること。 4バイトの倍数でない場合、送信者は0バイトでpaddingし、paddingはChunk Lengthに含めないこと。 送信者は3バイトより多くをpaddingしてはいけない。 受信者はpaddingバイトを無視すること。 SCTP-defined chunks are described in detail in Section 3.3. The guidelines for IETF-defined chunk extensions can be found in Section 14.1 of this document. SCTP定義のchunkはSection 3.3で詳しく述べる。 IETF定義のchunk拡張はSection 14.1で述べる。 3.2.1. Optional/Variable-Length Parameter Format Chunk values of SCTP control chunks consist of a chunk-type-specific header of required fields, followed by zero or more parameters. The optional and variable-length parameters contained in a chunk are defined in a Type-Length-Value format as shown below. SCTP control chunkのChunk valueは0以上のパラメータの必須フィールドのchunk-type-specificヘッダで構成される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Parameter Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stewart Standards Track [Page 19] RFC 4960 Stream Control Transmission Protocol September 2007 Chunk Parameter Type 16 bits (unsigned integer) The Type field is a 16-bit identifier of the type of parameter. It takes a value of 0 to 65534. パラメータのタイプの16bit識別子。0～65534。 The value of 65535 is reserved for IETF-defined extensions. Values other than those defined in specific SCTP chunk descriptions are reserved for use by IETF. 65535はIETF定義の拡張のためのreserve。 特定のSCTP chunkで定義された値以外はIETFで使用するためreserveされている。 Chunk Parameter Length 16 bits (unsigned integer) The Parameter Length field contains the size of the parameter in bytes, including the Parameter Type, Parameter Length, and Parameter Value fields. Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding bytes. Parameter Type、Parameter Length、Parameter Valueのバイト数。 Parameter Valueが0ならばLengthは4。 Parameter Lengthはpadding byteを含まない。 Chunk Parameter Value variable length The Parameter Value field contains the actual information to be transferred in the parameter. Parameter Valueはパラメータで転送される情報を含む。 The total length of a parameter (including Type, Parameter Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the parameter is not a multiple of 4 bytes, the sender pads the parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is not included in the Parameter Length field. A sender MUST NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes. パラメータ長の合計は4バイトの倍数であること。 4バイトの倍数でない場合、送信者は最後(Parameter Valueの後)に0でpaddingする。 padding長はParameter Lengthに含めない。 送信者は3バイトより多くのpaddingをしてはいけない。 受信者はpaddingを無視すること。 The Parameter Types are encoded such that the highest-order 2 bits specify the action that must be taken if the processing endpoint does not recognize the Parameter Type. Parameter Typeが認識できない場合にParameter Typeの上位2ビットでやるべきアクションが定義されている。 00 - Stop processing this parameter; do not process any further parameters within this chunk. パラメータの処理を停止し、パラメータを処理しない。 01 - Stop processing this parameter, do not process any further parameters within this chunk, and report the unrecognized parameter in an Unrecognized Parameter , as described in Section 3.2.2. パラメータパケット処理を停止し、パラメータを処理しない。Unrecognized Parameterとしてパラメータを報告する。Section 3.2.2参照。 10 - Skip this parameter and continue processing. パラメータをスキップし、処理を継続する。 11 - Skip this parameter and continue processing but report the unrecognized parameter in an Unrecognized Parameter , as described in Section 3.2.2. パラメータをスキップし、処理を継続する。Unrecognized parameterで報告する。Section 3.2.2参照。 Stewart Standards Track [Page 20] RFC 4960 Stream Control Transmission Protocol September 2007 Please note that in all four cases, an INIT ACK or COOKIE ECHO chunk is sent. In the 00 or 01 case, the processing of the parameters after the unknown parameter is canceled, but no processing already done is rolled back. 4つのケースでINIT ACK、COOKIE ECHOが送信されるのに注意してください。 00 or 01のケースでは、キャンセルされ、未実施の処理はロールバックされない。 The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 14.2. Note that a parameter type MUST be unique across all chunks. For example, the parameter type 5 is used to represent an IPv4 address (see Section 3.3.2.1). The value 5 then is reserved across all chunks to represent an IPv4 address and MUST NOT be reused with a different meaning in any other chunk. SCTPのパラメータはSCTP chunk sectionで定義される。 IETF定義のパラメータ拡張はSection 14.2で定義される。 すべてのchunkでParameter Typeは一意であること。 例えば、Parameter Type 5はIPv4アドレスを表すために使用される。(Section 3.3.1.1参照) 5はIPv4 アドレスを表すためにreserveされており、他のchunkで異なる意味の仕様をしてはいけない。 3.2.2. Reporting of Unrecognized Parameters If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it MUST put the Unrecognized Parameter parameter(s) in the INIT ACK chunk sent in response to the INIT chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g., due to lack of resources), an Unrecognized Parameter would NOT be included with any ABORT being sent to the sender of the INIT. INIT chunkの受信者がunrecognized parameterを検出し、Section 3.2.1に従って報告する場合、INIT chunkの応答としてINIT ACK chunkに Unrecognized Parameter parametersを付与すること。 INIT chunkの受信者がassociationの確立していない場合(リソース不足などにより)、送信者へのABORTには Unrecognized Parameter が含まれていないことに注意せよ。 If the receiver of an INIT ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the Unrecognized Parameters error cause with the COOKIE ECHO chunk sent in response to the INIT ACK chunk. If the receiver of the INIT ACK cannot bundle the COOKIE ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE ACK has been received. INIT ACK chunkの受信者が認識できないパラメータを検出し、Section 3.2.1に従って報告する場合、INIT ACK chunの応答のCOOKIE ECHO chunkで Unrecognized Parameters を含むERROR chunkをbundleすること。 INIT ACKの受信者がERROR chunkをCOOKIE ECHO chunkにbundleできない場合、ERROR chunkはCOOKIE ACKの受信前に分けて送られてもよい。 Note Any time a COOKIE ECHO is sent in a packet, it MUST be the first chunk. COOKIE ECHOをパケットで送信するときはそれは最初のchunkであること。 3.3. SCTP Chunk Definitions This section defines the format of the different SCTP chunk types. SCTP chunk typeのフォーマットを定義する。 Stewart Standards Track [Page 21] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.1. Payload Data (DATA) (0) The following format MUST be used for the DATA chunk 下記のフォーマットはDATAチャンクに使うこと。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Reserved|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / User Data (seq n of Stream S) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 5 bits Should be set to all 0 s and ignored by the receiver. 0を設定し、受信者は無視すること U bit 1 bit The (U)nordered bit, if set to 1 , indicates that this is an unordered DATA chunk, and there is no Stream Sequence Number assigned to this DATA chunk. Therefore, the receiver MUST ignore the Stream Sequence Number field. 順不同のbit。1が設定された場合、DATA chunkは順不同であることを示し、SSNはDATA chunkはない。 そのため、受信者はSSN fieldを無視すること。 After reassembly (if necessary), unordered DATA chunks MUST be dispatched to the upper layer by the receiver without any attempt to reorder. 必要ならばreassemblyの後、順不同のDATA chunkは順序制御なしに受信者によって上位レイヤに転送されること。 If an unordered user message is fragmented, each fragment of the message MUST have its U bit set to 1 . 順不同のユーザデータがフラグメントされた場合、各フラグメントはU bitに1がセットされる。 B bit 1 bit The (B)eginning fragment bit, if set, indicates the first fragment of a user message. fragmentの開始bit。セットされた場合、ユーザメッセージの最初のフラグメントを示す。 E bit 1 bit The (E)nding fragment bit, if set, indicates the last fragment of a user message. fragmentの最終bit。セットされた場合、ユーザメッセージの最後のフラグメントを示す。 Stewart Standards Track [Page 22] RFC 4960 Stream Control Transmission Protocol September 2007 An unfragmented user message shall have both the B and E bits set to 1 . Setting both B and E bits to 0 indicates a middle fragment of a multi-fragment user message, as summarized in the following table fragmentされていないユーザメッセージはB、E bitに1を設定すること。 BとEに0が設定されることは、フラグメントの中間であることを示す。 要約を下記のテーブルに示す。 B E Description ============================================================ | 1 0 | First piece of a fragmented user message | +----------------------------------------------------------+ | 0 0 | Middle piece of a fragmented user message | +----------------------------------------------------------+ | 0 1 | Last piece of a fragmented user message | +----------------------------------------------------------+ | 1 1 | Unfragmented message | ============================================================ | Table 1 Fragment Description Flags | ============================================================ When a user message is fragmented into multiple chunks, the TSNs are used by the receiver to reassemble the message. This means that the TSNs for each fragment of a fragmented user message MUST be strictly sequential. ユーザメッセージが複数のチャンクにfragmentされる場合、TSNがメッセージをreassembleするために受信者に使用される。 これはfragmentされたユーザメッセージの各fragmentのTSNは正確に連続していることを意味している。 Length 16 bits (unsigned integer) This field indicates the length of the DATA chunk in bytes from the beginning of the type field to the end of the User Data field excluding any padding. A DATA chunk with one byte of user data will have Length set to 17 (indicating 17 bytes). このfieldにはpaddingを除いたType filedの開始からUser Data fieldの最後までのバイト数で、DATA chunkの長さを表す。 1バイトのユーザデータをもつDATA chunkはLengthに17が設定される。(17byteを表す) A DATA chunk with a User Data field of length L will have the Length field set to (16 + L) (indicating 16+L bytes) where L MUST be greater than 0. Lが0より大きいとき、長さLのUser Data fieldをもつDATA chunkはLength filedに16 + Lが設定される。(16 + Lbyteを示す。) TSN 32 bits (unsigned integer) This value represents the TSN for this DATA chunk. The valid range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0 after reaching 4294967295. DATA chunkのTSNを表す。 TSNの範囲は0～4294967295である。 TSNは4294967295に達すると0に戻る。 Stream Identifier S 16 bits (unsigned integer) Identifies the stream to which the following user data belongs. user dataが属するstreamを識別する。 Stream Sequence Number n 16 bits (unsigned integer) This value represents the Stream Sequence Number of the following user data within the stream S. Valid range is 0 to 65535. Stream Sのuser dataのSSNを表す。範囲は0～65535。 Stewart Standards Track [Page 23] RFC 4960 Stream Control Transmission Protocol September 2007 When a user message is fragmented by SCTP for transport, the same Stream Sequence Number MUST be carried in each of the fragments of the message. SCTPにfragmentされた場合、同じSSNがメッセージの各fragmentに設定されること。 Payload Protocol Identifier 32 bits (unsigned integer) This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities, as well as by the peer application, to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network). Note that this field is NOT touched by an SCTP implementation; therefore, its byte order is NOT necessarily big endian. The upper layer is responsible for any byte order conversions to this field. この値はapplicationか上位レイヤにより指定されたprotocol identifierを表す。 この値は上位レイヤから渡され、peerに送られる。 この識別子はSCTPでは使われないが、DATA chunkで送信される情報のタイプを識別するためnetwork entity、peer applicationで使われる。 このfiledはfragmentのDATA chunkにでも送信されること。 このfieldはSCTPに関与されないことに注意せよ。バイトオーダーはビッグエンディアンである必要はない。 上位レイヤはこのfieldのバイトオーダー変換を担う。 The value 0 indicates that no application identifier is specified by the upper layer for this payload data. 0はこのpayload dataに上位レイヤによってapplication identifierが指定されていないことを示す。 User Data variable length This is the payload user data. The implementation MUST pad the end of the data to a 4-byte boundary with all-zero bytes. Any padding MUST NOT be included in the Length field. A sender MUST never add more than 3 bytes of padding. payload user data。4-byte boundaryのためall 0でpaddingすること。 paddingはLength fieldに含めないこと。 送信者は3byteを超えるpaddingを加えないこと。 3.3.2. Initiation (INIT) (1) This chunk is used to initiate an SCTP association between two endpoints. The format of the INIT chunk is shown below このchunkは2つのエンドポイント間のSCTP associationの初期化に使用する。 INIT chunkのformatを下記に示す。 Stewart Standards Track [Page 24] RFC 4960 Stream Control Transmission Protocol September 2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Streams | Number of Inbound Streams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Optional/Variable-Length Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The INIT chunk contains the following parameters. Unless otherwise noted, each parameter MUST only be included once in the INIT chunk. INIT chunkには下記のパラメータが含まれている。 各パラメータは一つだけINIT chunkに含まれること。 Fixed Parameters Status ---------------------------------------------- Initiate Tag Mandatory Advertised Receiver Window Credit Mandatory Number of Outbound Streams Mandatory Number of Inbound Streams Mandatory Initial TSN Mandatory Variable Parameters Status Type Value ------------------------------------------------------------- IPv4 Address (Note 1) Optional 5 IPv6 Address(Note 1) Optional 6 Cookie Preservative Optional 9 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Host Name Address (Note 3) Optional 11 Supported Address Types (Note 4) Optional 12 Note 1 The INIT chunks can contain multiple addresses that can be IPv4 and/or IPv6 in any combination. Note 1 INIT chunkはIPv4 and/or IPv6の任意の組み合わせで複数のアドレスを含むことができる。 Note 2 The ECN Capable field is reserved for future use of Explicit Congestion Notification. ECN Capable filedはExplicit Congestion Notificationの今後の仕様のためのreserve領域。 Note 3 An INIT chunk MUST NOT contain more than one Host Name Address parameter. Moreover, the sender of the INIT MUST NOT combine any other address types with the Host Name Address in the INIT. The receiver of INIT MUST ignore any other address types if the Host Name Address parameter is present in the received INIT chunk. INIT chunkは複数のHost Name Addressパラメータを含んではいけない。 INITの送信者はINITのHost Name Addressを他のアドレスタイプと組み合わせてはいけない。 Host Name Addressパラメータが受信したINIT chunkに存在する場合、INITの受信者は他のアドレスタイプを無視すること。 Stewart Standards Track [Page 25] RFC 4960 Stream Control Transmission Protocol September 2007 Note 4 This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type. このパラメータが存在する場合、送信エンドポイントがサポートできるすべてのアドレスタイプを指定する。 このパラメータが存在しない場合、送信エンドポイントが任意のアドレスタイプをサポートできることを示す。 IMPLEMENTATION NOTE If an INIT chunk is received with known parameters that are not optional parameters of the INIT chunk, then the receiver SHOULD process the INIT chunk and send back an INIT ACK. The receiver of the INIT chunk MAY bundle an ERROR chunk with the COOKIE ACK chunk later. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT chunk. INIT chunkがINIT chunkのオプションでない既知のパラメータとともに受信された場合、受信側はINIT chunkを処理し、INIT ACKを送信すること。 INIT chunkの受信者はCOOKIE ACK chunでERROR chunkをbundleしてもよい。 実装の制限では、INIT chunkに対してABORT chunkを返す。 The Chunk Flags field in INIT is reserved, and all bits in it should be set to 0 by the sender and ignored by the receiver. The sequence of parameters within an INIT can be processed in any order. INITのChunk Flag fieldはreserveであり、送信者によって0が設定され、受信者は無視する。 INITのパラメータは順序は任意の順序で処理できる。 Initiate Tag 32 bits (unsigned integer) The receiver of the INIT (the responding end) records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the receiver of the INIT transmits within this association. INITの受信者はInitiate Tag パラメータの値を記録する。 この値はINITの受信者がassociation中に送信するすべてのSCTPパケットのVerification Tag fieldに設定すること。 The Initiate Tag is allowed to have any value except 0. See Section 5.3.1 for more on the selection of the tag value. Initiate Tagは0以外の値をもつこと。 tag valueの選択についてはSection 5.2.1参照。 If the value of the Initiate Tag in a received INIT chunk is found to be 0, the receiver MUST treat it as an error and close the association by transmitting an ABORT. 受信したINIT chunkのInitiate Tagの値に0を見つけた場合、受信者はエラーとして扱い、ABORTを送信してassociationを終了する。 Advertised Receiver Window Credit (a_rwnd) 32 bits (unsigned integer) This value represents the dedicated buffer space, in number of bytes, the sender of the INIT has reserved in association with this window. During the life of the association, this buffer space SHOULD NOT be lessened (i.e., dedicated buffers taken away from this association); however, an endpoint MAY change the value of a_rwnd it sends in SACK chunks. INITの送信者がassociationのwindow用に確保しているバッファ領域のバイト数。 Assosiationの存続中、このバッファスペースは減らされないこと(バッファはassosiationから取り除かれないこと)。ただし、エンドポイントはSACK chunkで送るa_rwndの値を変更してもよい。 Number of Outbound Streams (OS) 16 bits (unsigned integer) Defines the number of outbound streams the sender of this INIT chunk wishes to create in this association. The value of 0 MUST NOT be used. INIT chunkの送信者がassociationで作成するoutbound stream数を定義する。 0は使用してはいけない。 Note A receiver of an INIT with the OS value set to 0 SHOULD abort the association. OSが0に設定されたINITの受信者はassociationをabortすること。 Stewart Standards Track [Page 26] RFC 4960 Stream Control Transmission Protocol September 2007 Number of Inbound Streams (MIS) 16 bits (unsigned integer) Defines the maximum number of streams the sender of this INIT chunk allows the peer end to create in this association. The value 0 MUST NOT be used. INIT chunkの送信者がpeer側で作成されるassociationで許可する最大のstream数を定義する。 0を使用しないこと。 Note There is no negotiation of the actual number of streams but instead the two endpoints will use the min(requested, offered). See Section 5.1.1 for details. Stream数のネゴシエーションはしないが、代わりに2エンドポイントはmin(requested, offered)を使用する。詳細はSection 5.1.1参照。 Note A receiver of an INIT with the MIS value of 0 SHOULD abort the association. MISが0のINITの受信者はassociationをabortすること。 Initial TSN (I-TSN) 32 bits (unsigned integer) Defines the initial TSN that the sender will use. The valid range is from 0 to 4294967295. This field MAY be set to the value of the Initiate Tag field. 送信側が使用するTSNの初期値を定義する。 範囲は0～4294967295。このフィールドはInitiate Tag fieldの値を設定してもよい。 3.3.2.1. Optional/Variable-Length Parameters in INIT The following parameters follow the Type-Length-Value format as defined in Section 3.2.1. Any Type-Length-Value fields MUST come after the fixed-length fields defined in the previous section. 下記のパラメータはSection 3.2.1で定義されたType-Length-Valueフォーマットに従うこと。 Type-Length-Value fieldは前のSectionで定義された固定長フィールドの後にあること。 IPv4 Address Parameter (5) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Address 32 bits (unsigned integer) Contains an IPv4 address of the sending endpoint. It is binary encoded. 送信側のIPv4アドレスが含まれる。binary encodeである。 Stewart Standards Track [Page 27] RFC 4960 Stream Control Transmission Protocol September 2007 IPv6 Address Parameter (6) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Address 128 bits (unsigned integer) Contains an IPv6 [RFC2460] address of the sending endpoint. It is binary encoded. 送信側のIPv4アドレスが含まれる。binary encodeである。 Note A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291], but should instead use an IPv4 Address parameter for an IPv4 address. 送信者はIPv4マップ IPv6アドレスを使用してはいけない。 IPv4でIPv4 address parameterを使用すること。 Combined with the Source Port Number in the SCTP common header, the value passed in an IPv4 or IPv6 Address parameter indicates a transport address the sender of the INIT will support for the association being initiated. That is, during the life time of this association, this IP address can appear in the source address field of an IP datagram sent from the sender of the INIT, and can be used as a destination address of an IP datagram sent from the receiver of the INIT. SCTP common headerのSource Port Numberと組み合わされ、Transport addressのIPv4 or IPv6 アドレスパラメータの値はassociationを示す。 すなわち、associationの生存時間中、このIPアドレスはINIT送信者の送信したIP datagramの送信アドレスとなり、INIT受信側から送信されたIP datagramの宛先アドレスとして使用される。 More than one IP Address parameter can be included in an INIT chunk when the INIT sender is multi-homed. Moreover, a multi- homed endpoint may have access to different types of network; thus, more than one address type can be present in one INIT chunk, i.e., IPv4 and IPv6 addresses are allowed in the same INIT chunk. INIT送信側がmulti-homeの場合、複数のIPアドレスパラメータがINIT chunkに含まれる。 さらに、multi-home エンドポイントはネットワークの異なるタイプのアクセスがあってもよい。 従って、一つのINIT chunkに複数のアドレスタイプが存在してよい。すなわちIPv4、IPv6アドレスが同一のINIT chunkであることが許容される。 If the INIT contains at least one IP Address parameter, then the source address of the IP datagram containing the INIT chunk and any additional address(es) provided within the INIT can be used as destinations by the endpoint receiving the INIT. If the INIT does not contain any IP Address parameters, the endpoint receiving the INIT MUST use the source address associated with the received IP datagram as its sole destination address for the association. INITが1つ以上のIPアドレスを含む場合、INIT内のaddress、INITを含むIP datagramのsource addressがINITを受信したエンドポイントに宛先として使用される。 INITがIP アドレスパラメータを含んでいない場合、INITを受信したエンドポイントはassociationに受信したIP datagramの送信元IPアドレスを宛先アドレスとして使用すること。 Note that not using any IP Address parameters in the INIT and INIT ACK is an alternative to make an association more likely to work across a NAT box. INIT、INIT ACKのIPアドレスパラメータを使用していないが、associationがNAT boxを経由するためである。 Stewart Standards Track [Page 28] RFC 4960 Stream Control Transmission Protocol September 2007 Cookie Preservative (9) The sender of the INIT shall use this parameter to suggest to the receiver of the INIT for a longer life-span of the State Cookie. INITの送信側はState Cookieのlife-spanをINITの受信側に提示するため、このパラメータを使用すること。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suggested Cookie Life-Span Increment (msec.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Suggested Cookie Life-Span Increment 32 bits (unsigned integer) This parameter indicates to the receiver how much increment in milliseconds the sender wishes the receiver to add to its default cookie life-span. default cookie life-spanに受信側が追加するms単位の増分を受信側に示す。 This optional parameter should be added to the INIT chunk by the sender when it reattempts establishing an association with a peer to which its previous attempt of establishing the association failed due to a stale cookie operation error. The receiver MAY choose to ignore the suggested cookie life-span increase for its own security reasons. このオプションパラメータは送信者がピアとのcookieが古くなったエラーによりassociationを確立するとき、INIT chunkに追加すること。 受信側はセキュリティのため、提示されたcookie life-span増加を無視してもよい。 Host Name Address (11) The sender of INIT uses this parameter to pass its Host Name (in place of its IP addresses) to its peer. The peer is responsible for resolving the name. Using this parameter might make it more likely for the association to work across a NAT box. INITの送信者はピアにHost Name(IP addressの代わり)を渡すために使われる。 ピアは名前解決をする必要がある。このパラメータの使用によりNAT boxを経由してassociationを作成できる。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 11 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Host Name / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Host Name variable length This field contains a host name in host name syntax per RFC 1123 Section 2.1 [RFC1123]. The method for resolving the host name is out of scope of SCTP. このフィールドはRFC 1123 Section 2.1の host name syntax のhost nameが含まれる。 ホスト名の解決方法はSCTPのスコープ外である。 Stewart Standards Track [Page 29] RFC 4960 Stream Control Transmission Protocol September 2007 Note At least one null terminator is included in the Host Name string and must be included in the length. 1以上のnull終端がHost Name stringに含まれ、lengthに含まれること。 Supported Address Types (12) The sender of INIT uses this parameter to list all the address types it can support. INITの送信者はサポートできるすべてのアドレスタイプの一覧のためこのパラメータを使用する。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 12 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type #1 | Address Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ Address Type 16 bits (unsigned integer) This is filled with the type value of the corresponding address TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11). 対応するアドレス TLVのタイプの値が設定される。 3.3.3. Initiation Acknowledgement (INIT ACK) (2) The INIT ACK chunk is used to acknowledge the initiation of an SCTP association. INIT ACK chunkはSCTP associationの開始をacknowledgeするために使用される。 The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable parameters The State Cookie and the Unrecognized Parameter INIT ACKのパラメータはINIT chunkと同様に定義される。 2つの可変パラメータを使用する。State Cookie、Unrecognized Parameter。 Stewart Standards Track [Page 30] RFC 4960 Stream Control Transmission Protocol September 2007 The format of the INIT ACK chunk is shown below 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Streams | Number of Inbound Streams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Optional/Variable-Length Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Initiate Tag 32 bits (unsigned integer) The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the INIT ACK receiver transmits within this association. INIT ACKの受信者はInitiate Tagの値を記録する。 この値はassociationでINIT ACK受信者が送信するすべてのSCTPパケットのVerification Tagに設定されること。 The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value. Initiate Tagは0を設定してはいけない。Initiate Tagの値についてはSection 5.3.1参照。 If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0, the receiver MUST destroy the association discarding its TCB. The receiver MAY send an ABORT for debugging purpose. 受信したINIT ACK chunkのInitiate Tagの値が0の場合、受信者はassociationを破棄すること。受信者はデバッグのためABORTを送ってもよい。 Advertised Receiver Window Credit (a_rwnd) 32 bits (unsigned integer) This value represents the dedicated buffer space, in number of bytes, the sender of the INIT ACK has reserved in association with this window. During the life of the association, this buffer space SHOULD NOT be lessened (i.e., dedicated buffers taken away from this association). INIT ACKの送信者がassociationのwindow用に確保しているバッファ領域のバイト数。 Associationの存続中、このバッファスペースは減らされないこと(バッファはassosiationから取り除かれないこと)。 Stewart Standards Track [Page 31] RFC 4960 Stream Control Transmission Protocol September 2007 Number of Outbound Streams (OS) 16 bits (unsigned integer) Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST NOT be used, and the value MUST NOT be greater than the MIS value sent in the INIT chunk. INIT ACK chunkの送信者がassociationで作成するoutbound stream数を定義する。 0は使用してはいけない。INIT chunkで送信されたMIS値より大きくしてはいけない。 Note A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB. OSに0が設定されたINIT ACKの受信者はassociationを削除し、TCBを破棄すること。 Number of Inbound Streams (MIS) 16 bits (unsigned integer) Defines the maximum number of streams the sender of this INIT ACK chunk allows the peer end to create in this association. The value 0 MUST NOT be used. INIT ACK chunkの送信者がpeer側で作成されるassociationで許可する最大のstream数を定義する。 0を使用しないこと。 Note There is no negotiation of the actual number of streams but instead the two endpoints will use the min(requested, offered). See Section 5.1.1 for details. Stream数のネゴシエーションはしないが、代わりに2エンドポイントはmin(requested, offered)を使用する。詳細はSection 5.1.1参照。 Note A receiver of an INIT ACK with the MIS value set to 0 SHOULD destroy the association discarding its TCB. MISに0が設定されたINIT ACKの受信者はassociationを削除し、TCBを破棄すること。 Initial TSN (I-TSN) 32 bits (unsigned integer) Defines the initial TSN that the INIT ACK sender will use. The valid range is from 0 to 4294967295. This field MAY be set to the value of the Initiate Tag field. INIT ACKの送信側が使用するTSNの初期値を定義する。 範囲は0～4294967295。このフィールドはInitiate Tag fieldの値を設定してもよい。 Fixed Parameters Status ---------------------------------------------- Initiate Tag Mandatory Advertised Receiver Window Credit Mandatory Number of Outbound Streams Mandatory Number of Inbound Streams Mandatory Initial TSN Mandatory Variable Parameters Status Type Value ------------------------------------------------------------- State Cookie Mandatory 7 IPv4 Address (Note 1) Optional 5 IPv6 Address (Note 1) Optional 6 Unrecognized Parameter Optional 8 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Host Name Address (Note 3) Optional 11 Note 1 The INIT ACK chunks can contain any number of IP address parameters that can be IPv4 and/or IPv6 in any combination. INIT ACK chunkは任意の組み合わせでIPv4/IPv6アドレスを複数含むことができる。 Note 2 The ECN Capable field is reserved for future use of Explicit Congestion Notification. ECN fieldはExplicit Congestion Notification(明示的輻輳通知)のためにreserveされている。 Stewart Standards Track [Page 32] RFC 4960 Stream Control Transmission Protocol September 2007 Note 3 The INIT ACK chunks MUST NOT contain more than one Host Name Address parameter. Moreover, the sender of the INIT ACK MUST NOT combine any other address types with the Host Name Address in the INIT ACK. The receiver of the INIT ACK MUST ignore any other address types if the Host Name Address parameter is present. INIT ACK chunkは複数のHost Name Addressパラメータを含んではいけない。INIT ACKの送信者はINIT ACKのHost Name Addressを他のアドレスタイプと組み合わせてはいけない。 Host Name Addressパラメータが受信したINIT ACK chunkに存在する場合、INIT ACKの受信者は他のアドレスタイプを無視すること。 IMPLEMENTATION NOTE An implementation MUST be prepared to receive an INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the State Cookie AND the variable address list. For example if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK. 実装では、State Cookieと可変長アドレスリストのため1500byte以上のINIT ACKを受信する準備をすること。 例えば、INITの送信者が送りたいIPv4アドレスを1000個持っている場合、INIT ACKでencodeすると8000byte以上は必要になる。 IMPLEMENTATION NOTE If an INIT ACK chunk is received with known parameters that are not optional parameters of the INIT ACK chunk, then the receiver SHOULD process the INIT ACK chunk and send back a COOKIE ECHO. The receiver of the INIT ACK chunk MAY bundle an ERROR chunk with the COOKIE ECHO chunk. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT ACK chunk. INIT ACK chunkがINIT ACK chunkのオプションでない既知のパラメータとともに受信された場合、受信側はINIT ACK chunkを処理し、COOKIE ECHOを送信すること。 INIT ACK chunkの受信者はCOOKIE ECHO chunkでERROR chunkをbundleしてもよい。 実装の制限では、INIT ACK chunkに対してABORT chunkを返してもよい。 In combination with the Source Port carried in the SCTP common header, each IP Address parameter in the INIT ACK indicates to the receiver of the INIT ACK a valid transport address supported by the sender of the INIT ACK for the life time of the association being initiated. SCTP common header内のSource Portと組み合わせ、INIT ACK内の各IP AddressパラメータはINIT ACKの受信側にINIT ACKの送信者がサポートしてるassociationで有効なtransport addressを示す。 If the INIT ACK contains at least one IP Address parameter, then the source address of the IP datagram containing the INIT ACK and any additional address(es) provided within the INIT ACK may be used as destinations by the receiver of the INIT ACK. If the INIT ACK does not contain any IP Address parameters, the receiver of the INIT ACK MUST use the source address associated with the received IP datagram as its sole destination address for the association. INIT ACKが一つ以上IP Address paramterを含んでいる場合、INIT ACKに含まれるIPアドレスとIP datagramの送信元アドレスはINIT ACKの受信側に宛先として使用されてよい。 INIT ACKがIP address paramterを含まない場合、INIT ACKの受信側は受信したIP datagramの送信元IPアドレスをassociationの宛先アドレスとして使用すること。 The State Cookie and Unrecognized Parameters use the Type-Length- Value format as defined in Section 3.2.1 and are described below. The other fields are defined the same as their counterparts in the INIT chunk. State CookieとUnrecognized Parmterは Section 3.2.1と下記に定義されたType-Length-Value formatを使用する。 他のfiledはINIT chunkの対応するfieldと同様に定義される。 3.3.3.1. Optional or Variable-Length Parameters State Cookie Parameter Type Value 7 Parameter Length Variable size, depending on size of Cookie. Stewart Standards Track [Page 33] RFC 4960 Stream Control Transmission Protocol September 2007 Parameter Value This parameter value MUST contain all the necessary state and parameter information required for the sender of this INIT ACK to create the association, along with a Message Authentication Code (MAC). See Section 5.1.3 for details on State Cookie definition. このparamterはINIT ACKの送信者がassociation作成に必要なparameterとstateをMessage Authentication Code(MAC)とともに含むこと。 State Cookieの定義の詳細は5.1.3 Unrecognized Parameter Parameter Type Value 8 Parameter Length Variable size. Parameter Value This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter that has a value that indicates it should be reported to the sender. This parameter value field will contain unrecognized parameters copied from the INIT chunk complete with Parameter Type, Length, and Value fields. INITが送信側に報告するべき未認識のパラメータを含んでいる場合、このパラメータはINIT chunkの送信側に返される。 このparamter value field はParamter Type、Length、ValueをINIT chunkからコピーした未認識のパラメータを含む。
https://w.atwiki.jp/lmes2/pages/223.html
Javascript TIPS デバッグ Visual Studioで静的HTMLページのJavaScriptコードをデバッグするには？ － ＠IT エンコードとデコード とほほのCookie入門 / エンコードとデコード
https://w.atwiki.jp/saikouon_dokoda/pages/629.html
調査楽曲数 1 か行 タイトル 地低 地高 裏低 裏高 備考 コンプリケイション mid1B hiB