RFC3103 日本語訳
3103 Realm Specific IP: Protocol Specification. M. Borella, D.Grabelsky, J. Lo, K. Taniguchi. October 2001. (Format: TXT=115855 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Borella
Request for Comments: 3103 D. Grabelsky
Category: Experimental CommWorks
J. Lo
Candlestick Networks
K. Taniguchi
NEC USA
October 2001
Borellaがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3103年のD.Grabelskyカテゴリ: 実験用CommWorks J.最低気温燭台はNEC米国2001年10月にK.谷口をネットワークでつなぎます。
Realm Specific IP: Protocol Specification
分野の特定のIP: プロトコル仕様
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
IESG Note
IESG注意
The IESG notes that the set of documents describing the RSIP technology imply significant host and gateway changes for a complete implementation. In addition, the floating of port numbers can cause problems for some applications, preventing an RSIP-enabled host from interoperating transparently with existing applications in some cases (e.g., IPsec). Finally, there may be significant operational complexities associated with using RSIP. Some of these and other complications are outlined in section 6 of the RFC 3102, as well as in the Appendices of RFC 3104. Accordingly, the costs and benefits of using RSIP should be carefully weighed against other means of relieving address shortage.
IESGは、RSIP技術を説明するドキュメントのセットが完全な実現のために重要なホストとゲートウェイ変化を含意することに注意します。 さらに、ポートナンバーの浮動はいくつかのアプリケーションのために問題を起こすことができます、いくつかの場合(例えば、IPsec)、RSIPによって可能にされたホストが既存のアプリケーションで透明に共同利用するのを防いで。 最終的に、RSIPを使用すると関連している重要な操作上の複雑さがあるかもしれません。 これらと他のいくつかの複雑さがRFC3102のセクション6、およびRFC3104のAppendicesに概説されています。 それに従って、RSIPを使用するコストと利益は慎重にアドレス不足を救う他の手段に比較考量されるべきです。
Abstract
要約
This document presents a protocol with which to implement Realm Specific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port. In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway.
このドキュメントはRealm Specific IP(RSIP)を実行するプロトコルを提示します。 ここに定義されたプロトコルはRSIPホストとゲートウェイの間のリソースの交渉を許します、ホストが、ゲートウェイが世界的なネットワーク存在を確立するためにパラメタを記述するいくつかを賃貸できるように。 このプロトコルは、応用層を作動させて、それ自身のTCPかUDPポートを使用するように設計されています。 特に、ゲートウェイは、ゲートウェイで流れ方針を励行されることができるように、プロトコルでアドレシングと管理パラメータをホストに割り当てることができます。
Borella, et al. Experimental [Page 1] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[1ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . 7 6. Host / Gateway Relationships . . . . . . . . . . . . . . . . 7 7. Gateway Flow Policy and State . . . . . . . . . . . . . . . . 8 7.1. Local Flow Policy . . . . . . . . . . . . . . . . . . . . . 9 7.2. Remote Flow Policy . . . . . . . . . . . . . . . . . . . . 9 7.3. Gateway State . . . . . . . . . . . . . . . . . . . . . . . 10 8. Parameter Specification and Formats . . . . . . . . . . . . . 11 8.1. Address . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.2. Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.3. Lease Time . . . . . . . . . . . . . . . . . . . . . . . . 13 8.4. Client ID . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.5. Bind ID . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.6. Tunnel Type . . . . . . . . . . . . . . . . . . . . . . . . 14 8.7. RSIP Method . . . . . . . . . . . . . . . . . . . . . . . . 14 8.8. 8.8. Error . . . . . . . . . . . . . . . . . . . . . . . . 14 8.9. Flow Policy . . . . . . . . . . . . . . . . . . . . . . . . 15 8.10. Indicator . . . . . . . . . . . . . . . . . . . . . . . . 15 8.11. Message Counter . . . . . . . . . . . . . . . . . . . . . 16 8.12. Vendor Specific Parameter . . . . . . . . . . . . . . . . 16 9. Message Types . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. ERROR_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 17 9.2. REGISTER_REQUEST . . . . . . . . . . . . . . . . . . . . . 18 9.3. REGISTER_RESPONSE . . . . . . . . . . . . . . . . . . . . . 19 9.4. DE-REGISTER_REQUEST . . . . . . . . . . . . . . . . . . . . 19 9.5. DE-REGISTER_RESPONSE . . . . . . . . . . . . . . . . . . . 20 9.6. ASSIGN_REQUEST_RSA-IP . . . . . . . . . . . . . . . . . . . 21 9.7. ASSIGN_RESPONSE_RSA-IP . . . . . . . . . . . . . . . . . . 22 9.8. ASSIGN_REQUEST_RSAP-IP . . . . . . . . . . . . . . . . . . 23 9.9. ASSIGN_RESPONSE_RSAP-IP . . . . . . . . . . . . . . . . . . 26 9.10. EXTEND_REQUEST . . . . . . . . . . . . . . . . . . . . . . 27 9.11. EXTEND_RESPONSE . . . . . . . . . . . . . . . . . . . . . 28 9.12. FREE_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 28 9.13. FREE_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 29 9.14. QUERY_REQUEST . . . . . . . . . . . . . . . . . . . . . . 30 9.15. QUERY_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 31 9.16. LISTEN_REQUEST . . . . . . . . . . . . . . . . . . . . . . 32 9.17. LISTEN_RESPONSE . . . . . . . . . . . . . . . . . . . . . 35 10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.1. Use of Message Counters . . . . . . . . . . . . . . . . . 36 10.2. RSIP Host and Gateway Failure Scenarios . . . . . . . . . 37 10.3. General Gateway Policy . . . . . . . . . . . . . . . . . . 38 10.4. Errors Not From the RSIP Protocol . . . . . . . . . . . . 39
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 3 2。 要件. . . . . . . . . . . . . . . . 4 3の仕様。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 4。 構造. . . . . . . . . . . . . . . . . . . . . . . . 5 5。 プロトコル. . . . . . . . . . . . . . . . . . . . . 7 6を輸送してください。 ホスト/ゲートウェイ関係. . . . . . . . . . . . . . . . 7 7。 ゲートウェイ流れ方針と状態. . . . . . . . . . . . . . . . 8 7.1。 局所流方針. . . . . . . . . . . . . . . . . . . . . 9 7.2。 リモート流れ方針. . . . . . . . . . . . . . . . . . . . 9 7.3。 ゲートウェー州. . . . . . . . . . . . . . . . . . . . . . . 10 8。 パラメタ仕様と形式. . . . . . . . . . . . . 11 8.1。 .118.2を記述してください。 ポート. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.3。 時間. . . . . . . . . . . . . . . . . . . . . . . . 13 8.4を賃貸してください。 クライアントID. . . . . . . . . . . . . . . . . . . . . . . . . 13 8.5。 ID. . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.6を縛ってください。 タイプ. . . . . . . . . . . . . . . . . . . . . . . . 14 8.7にトンネルを堀ってください。 RSIP方法. . . . . . . . . . . . . . . . . . . . . . . . 14 8.8。 8.8. 誤り. . . . . . . . . . . . . . . . . . . . . . . . 14 8.9。 流れ方針. . . . . . . . . . . . . . . . . . . . . . . . 15 8.10。 インディケータ. . . . . . . . . . . . . . . . . . . . . . . . 15 8.11。 メッセージカウンタ. . . . . . . . . . . . . . . . . . . . . 16 8.12。 業者の特定のパラメタ. . . . . . . . . . . . . . . . 16 9。 メッセージは.169.1をタイプします。 誤り_応答. . . . . . . . . . . . . . . . . . . . . . 17 9.2。 _要求. . . . . . . . . . . . . . . . . . . . . 18 9.3を登録してください。 _応答. . . . . . . . . . . . . . . . . . . . . 19 9.4を登録してください。 反-_要求. . . . . . . . . . . . . . . . . . . . 19 9.5を登録してください。 反-_応答. . . . . . . . . . . . . . . . . . . 20 9.6を登録してください。 _要求_RSA IP. . . . . . . . . . . . . . . . . . . 21 9.7を割り当ててください。 _応答_RSA IP. . . . . . . . . . . . . . . . . . 22 9.8を割り当ててください。 _要求_RSAP IP. . . . . . . . . . . . . . . . . . 23 9.9を割り当ててください。 _応答_RSAP IP. . . . . . . . . . . . . . . . . . 26 9.10を割り当ててください。 _要求. . . . . . . . . . . . . . . . . . . . . . 27 9.11を広げてください。 _応答. . . . . . . . . . . . . . . . . . . . . 28 9.12を広げてください。 _要求. . . . . . . . . . . . . . . . . . . . . . . 28 9.13を解放してください。 _応答. . . . . . . . . . . . . . . . . . . . . . 29 9.14を解放してください。 _要求. . . . . . . . . . . . . . . . . . . . . . 30 9.15について質問してください。 _応答. . . . . . . . . . . . . . . . . . . . . . 31 9.16について質問してください。 _要求. . . . . . . . . . . . . . . . . . . . . . 32 9.17を聴いてください。 _応答. . . . . . . . . . . . . . . . . . . . . 35 10を聴いてください。 議論. . . . . . . . . . . . . . . . . . . . . . . . . 36 10.1。 メッセージの使用は.36 10.2を打ち返します。 RSIPホストとゲートウェイ失敗シナリオ. . . . . . . . . 37 10.3。 一般ゲートウェイ方針. . . . . . . . . . . . . . . . . . 38 10.4。 RSIPプロトコル. . . . . . . . . . . . 39でないのからの誤り
Borella, et al. Experimental [Page 2] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[2ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
10.5. Address and Port Requests and Allocation . . . . . . . . . 40 10.6. Local Gateways and Flow Policy Interaction . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . 40 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 14. Appendix A: RSIP Error Numbers . . . . . . . . . . . . . . . 42 15. Appendix B: Message Types . . . . . . . . . . . . . . . . . 44 16. Appendix C: Example RSIP host/gateway transactions . . . . . 45 17. Appendix D: Example RSIP host state diagram . . . . . . . . 50 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 19. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53 20. Full Copyright Statement . . . . . . . . . . . . . . . . . . 54
10.5. 要求と配分. . . . . . . . . 40 10.6を記述して、移植してください。 地方のゲートウェイと流れ方針相互作用. . . . . . . . 40 11。 セキュリティ問題. . . . . . . . . . . . . . . . . . 40 12。 IANA問題. . . . . . . . . . . . . . . . . . . . 41 13。 承認. . . . . . . . . . . . . . . . . . . . . . 41 14。 付録A: RSIPエラー番号. . . . . . . . . . . . . . . 42 15。 付録B: メッセージは.44 16をタイプします。 付録C: 例のRSIPホスト/ゲートウェイ取引. . . . . 45 17。 付録D: 例のRSIPは州のダイヤグラム. . . . . . . . 50 18をホスティングします。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 52 19。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 53 20。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 54
1. Introduction
1. 序論
Network Address Translation (NAT) has gained popularity as a method of separating public and private address spaces, and alleviating network address shortages. A NAT translates the addresses of packets leaving a first routing realm to an address from a second routing realm, and performs the reverse function for packets entering the first routing realm from the second routing realm. This translation is performed transparently to the hosts in either space, and may include modification of TCP/UDP port numbers and IP addresses in packets that traverse the NAT.
ネットワークAddress Translation(NAT)は公共の、そして、個人的なアドレス空間を切り離して、ネットワーク・アドレス不足を軽減する方法として人気を獲得しました。 NATは、2番目のルーティング分野から最初のルーティング分野をアドレスに出るパケットのアドレスを翻訳して、パケットのために2番目のルーティング分野から最初のルーティング分野に入りながら、逆の機能を実行します。 この翻訳は、スペースで透明にホストに実行されて、NATを横断するパケットにTCP/UDPポートナンバーとIPアドレスの変更を含むかもしれません。
While a NAT does not require hosts to be aware of the translation, it will require an application layer gateway (ALG) for any protocol that transmits IP addresses or port numbers in packet payloads (such as FTP). Additionally, a NAT will not work with protocols that require IP addresses and ports to remain unmodified between the source and destination hosts, or protocols that prevent such modifications from occurring (such as some IPsec modes, or application-layer end-to-end encryption).
NATは、ホストが翻訳を意識しているのを必要としませんが、それはパケットペイロード(FTPなどの)のIPアドレスかポートナンバーを伝えるどんなプロトコルのためにも、応用層ゲートウェイ(ALG)を必要とするでしょう。 さらに、NATはIPアドレスとポートがソースとあて先ホストの間で変更されていないままで残っているのを必要とするプロトコル、またはそのような変更が起こるのを防ぐプロトコル(いくらかのIPsecなどのモード、または応用層終端間暗号化)で働かないでしょう。
An alternative to a NAT is an architecture that allows the hosts within the first (e.g., private) routing realm to directly use addresses and other routing parameters from the second (e.g., public) routing realm. Thus, RSIP [RSIP-FRAME] has been defined as a method for address sharing that exhibits more transparency than NAT. In particular, RSIP requires that an RSIP gateway (a router or gateway between the two realms) assign at least one address from the second routing realm, and perhaps some other resources, to each RSIP host. An RSIP host is a host in the first routing realm that needs to establish end-to-end connectivity to a host, entity or device in the second routing realm. Thus, the second routing realm is not directly
NATへの代替手段は直接2(例えば、公衆)番目のルーティング分野からのアドレスと他のルーティングパラメタを使用する最初(例えば、兵卒)のルーティング分野の中にホストを許容する構造です。 したがって、RSIP[RSIP-FRAME]はNATより多くの透明を示すアドレス共有のための方法と定義されました。 特に、RSIPは、RSIPゲートウェイ(2つの分野の間のルータかゲートウェイ)が2番目のルーティング分野、および恐らくある他のリソースからの少なくとも1つのアドレスを割り当てるのを必要とします、それぞれのRSIPホストに。 RSIPホストは2番目のルーティング分野で終わりから終わりへの接続性をホスト、実体または装置に確立する必要がある最初のルーティング分野のホストです。 したがって、2番目のルーティング分野は直接そうではありません。
Borella, et al. Experimental [Page 3] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[3ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
accessible from the RSIP host, but this system allows packets to maintain their integrity from the RSIP host to their destination. ALGs are not required in the RSIP gateway.
RSIPホストからアクセスしやすいです、このシステムだけで、パケットはRSIPホストからそれらの目的地まで彼らの保全を維持できます。 ALGsはRSIPゲートウェイで必要ではありません。
RSIP requires that hosts be modified so that they place some number of layer three, layer four or other values from those assigned by the RSIP gateway in each packet bound for the second routing realm.
RSIPが、ホストが変更されるのを必要とするので、彼らは2番目のルーティング分野に向かっている各パケットでRSIPゲートウェイによって割り当てられたものから何らかの数の層three、層fourまたは他の値を置きます。
This document discusses a method for assigning parameters to an RSIP host from an RSIP gateway. The requirements, scope, and applicability of RSIP, as well as its interaction with other layer 3 protocols, are discussed in a companion framework document [RSIP- FRAME]. Extensions to this protocol that enable end-to-end IPsec are discussed in [RSIP-IPSEC].
このドキュメントはパラメタをRSIPゲートウェイからRSIPホストに割り当てるための方法について議論します。 仲間枠組みのドキュメント[RSIP- FRAME]で要件(範囲、RSIPの適用性、および他の層の3プロトコルとのその相互作用)について、議論します。 [RSIP-IPSEC]でこのプロトコルへの終わりから終わりへのIPsecを有効にする拡大について議論します。
2. Specification of Requirements
2. 要件の仕様
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "SHALL", "SHALL NOT", "MAY" and "MAY NOT" that appear in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「」、“SHALL"、「」、本書では現れる「5月」と「5月のNOT」は[RFC2119]で説明されるように解釈されることであるべきです。
3. Terminology
3. 用語
Private Realm
私設の分野
A routing realm that uses private IP addresses from the ranges
(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) specified in
[RFC1918], or addresses that are non-routable from the Internet.
範囲からのプライベートIPアドレスを使用するルーティング分野、(10.0 .0 16が)中で指定した8、.0/172.16.0 12、.0/192.168.0.0/[RFC1918]、またはインターネットから非発送可能であるアドレス。
Public Realm
公共部門
A routing realm with unique network addresses assigned by the
Internet Assigned Number Authority (IANA) or an equivalent address
registry.
ユニークなネットワーク・アドレスがISOCの機関の一つで(IANA)によって割り当てられているルーティング分野か同等なアドレス登録。
RSIP Host
RSIPホスト
A host within the private realm that acquires publicly unique
parameters from an RSIP gateway through the use of the RSIP
client/server protocol.
RSIPゲートウェイからRSIPクライアント/サーバプロトコルの使用で公的にユニークなパラメタを取得する私設の分野の中のホスト。
RSIP Gateway
RSIPゲートウェイ
A router situated on the boundary between a private realm and a
public realm and owns one or more public IP addresses. An RSIP
gateway is responsible for public parameter management and
assignment to RSIP hosts. An RSIP gateway may act as a NAT router
for hosts within the private realm that are not RSIP enabled.
ルータは、私設の分野と公共部門の間の境界に位置して、1つ以上の公共のIPアドレスを所有しています。 RSIPホストにとって、RSIPゲートウェイは公立のパラメタ管理と課題に原因となります。 RSIPゲートウェイは私設の分野の中のRSIPでないホストのためのNATルータとして可能にされるのに作動するかもしれません。
Borella, et al. Experimental [Page 4] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[4ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
RSIP Client
RSIPクライアント
An application program that performs the client portion of the
RSIP client/server protocol. An RSIP client application MUST
exist on all RSIP hosts, and MAY exist on RSIP gateways.
RSIPクライアント/サーバプロトコルのクライアント部分を実行するアプリケーション・プログラム。 RSIPクライアント利用は、すべてのRSIPホストの上に存在しなければならなくて、RSIPゲートウェイの上に存在するかもしれません。
RSIP Server
RSIPサーバ
An application program that performs the server portion of the
RSIP client/server protocol. An RSIP server application MUST
exist on all RSIP gateways.
RSIPクライアント/サーバプロトコルのサーバ部分を実行するアプリケーション・プログラム。 RSIPサーバ・アプリケーションはすべてのRSIPゲートウェイの上に存在しなければなりません。
RSA-IP: Realm Specific Address IP
RSA-IP: 分野の特定のアドレスIP
An RSIP method in which each RSIP host is allocated a unique IP
address from the public realm. Discussed in detail in [RSIP-
FRAME]
固有のIPアドレスが公共部門からそれぞれのRSIPホストに割り当てられるRSIP方法。 詳細に、中では、議論します。[RSIPフレーム]
RSAP-IP: Realm Specific Address and Port IP
RSAP-IP: 分野の特定のアドレスとポートIP
An RSIP method in which each RSIP host is allocated an IP address
(possibly shared with other RSIP hosts) and some number of per-
address unique ports from the public realm. Discussed in detail
in [RSIP-FRAME]
中のIPアドレス(ことによると他のRSIPホストと共有される)と何らかの数がそれぞれのRSIPホストに割り当てられるRSIP方法、-、公共部門からユニークなポートを記述してください。 詳細に、中では、議論します。[RSIP-フレーム]
Binding
付きます。
An association of some combination of a local address, one or more
local ports, a remote address, and a remote port with an RSIP
host.
RSIPホストがいるローカルアドレスの何らかの組み合わせの協会、1つ以上の地方のポート、リモートアドレス、および遠く離れたポート。
Resource
リソース
A general way to refer to an item that an RSIP host leases from an
RSIP gateway; e.g., an address or port.
RSIPホストがRSIPゲートウェイから賃貸する商品を示す一般的な方法。 例えば、アドレスかポート。
All other terminology found in this document is consistent with that of [RFC2663] and [RSIP-FRAME].
本書では見つけられた他のすべての用語が[RFC2663]と[RSIP-FRAME]のものと一致しています。
4. Architecture
4. 構造
For simplicity, in the remainder of this document we will assume that the RSIP hosts in the first routing realm (network) use private (e.g., see [RFC1918]) IP addresses, and that the second routing realm (network) uses public IP addresses. (This assumption is made without loss of generality and the ensuing discussion applies to more general
簡単さのために、このドキュメントの残りでは、私たちは、最初のルーティング分野(ネットワーク)のRSIPホストが個人的な(例えば、[RFC1918]を見る)IPアドレスを使用して、2番目のルーティング分野(ネットワーク)が公共のIPアドレスを使用すると思うつもりです。 (この仮定は一般性の喪失なしでされて、続く議論は、より多くの一般に適用されます。
Borella, et al. Experimental [Page 5] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[5ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
cases.) The RSIP gateway connects the public and private realms and contains interfaces to both. Other NAT terminology found in this document is defined in [RFC2663].
ケース。) RSIPゲートウェイは、公共の、そして、私設の分野を接続して、両方にインタフェースを含んでいます。 本書では見つけられた他のNAT用語は[RFC2663]で定義されます。
The diagram below describes an exemplary reference architecture for RSIP.
以下のダイヤグラムはRSIPのために模範的参照構造について説明します。
RSIP Host RSIP Gateway Host
RSIPホストRSIPゲートウェイホスト
Xa Na Nb Yb
[X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
( Network ) ( Network )
Xa Na Nb Yb[X]------( Addr sp. A)----[N]-----( Addr sp. B)-------[Y](ネットワーク)(ネットワーク)
Hosts X and Y belong to different addressing realms A and B, respectively, and N is an RSIP gateway (which may also perform NAT functions). N has two interfaces: Na on address space A, and Nb on address space B. N may have a pool of addresses in address space B which it can assign to or lend to X and other hosts in address space
ホストXとYはそれぞれ異なったアドレシング分野AとBに属します、そして、NはRSIPゲートウェイ(また、NAT機能を実行するかもしれない)です。 Nには、2つのインタフェースがあります: アドレス空間Aに関するNa、およびNがアドレス空間でそれが割り当てることができるアドレス空間Bにおけるアドレスのプールを持っているか、またはXと他のホストを与えるかもしれないアドレス空間B.のNb
A. These addresses are not shown above, but they can be denoted as Nb1, Nb2, Nb3 and so on.
A. これらのアドレスは上に示されませんが、Nb1、Nb2、Nb3などとしてそれらを指示できます。
Host X, needing to establish an end-to-end connection to a network entity Y situated within address space B, first negotiates and obtains assignment of the resources from the RSIP gateway. Upon assignment of these parameters, the RSIP gateway creates a mapping, of X's addressing information and the assigned resources. This binding enables the RSIP gateway to correctly de-multiplex and forward inbound traffic generated by Y for X. A lease time is associated with each bind.
アドレス空間Bの中に位置したネットワーク実体Yに終わりから終わりとの接続を確立するのが必要であることで、ホストXは、最初に、RSIPゲートウェイからリソースの課題を交渉して、得ます。 これらのパラメタの課題のときに、RSIPゲートウェイはXのアドレス指定情報と割り当てられたリソースに関するマッピングを作成します。 この結合は、RSIPゲートウェイが反-正しく多重送信されるのを可能にします、そして、YでX.Aリース時間に発生する前進のインバウンドトラフィックは各ひもに関連しています。
Using the public parameters assigned by the RSIP gateway, RSIP hosts tunnel data packets across address space A to the RSIP gateway. The RSIP gateway acts as the end point of such tunnels, stripping off the outer headers and routing the inner packets onto the public realm. As mentioned above, an RSIP gateway maintains a mapping of the assigned public parameters as demultiplexing fields for uniquely mapping them to RSIP host private addresses. When a packet from the public realm arrives at the RSIP gateway and it matches a given set of demultiplexing fields, then the RSIP gateway will tunnel it to the appropriate RSIP host. The tunnel headers of outbound packets from X to Y, given that X has been assigned Nb, are as follows:
RSIPゲートウェイによって割り当てられた公共のパラメタを使用して、RSIPはアドレス空間Aの向こう側にトンネルデータ・パケットをRSIPゲートウェイに接待します。 RSIPゲートウェイはそのようなトンネル、外側のヘッダーを全部はぎ取って、およびルーティングのエンドポイントとして内側のパケットに公共部門に作用します。 以上のように、逆多重化が唯一それらを写像するためにRSIPホストとしてプライベート・アドレスをさばくとき、RSIPゲートウェイは割り当てられた公共のパラメタに関するマッピングを維持します。 公共部門からのパケットがRSIPゲートウェイに到着して、与えられたセットの逆多重化分野を合わせると、RSIPゲートウェイは適切なRSIPホストにそれにトンネルを堀るでしょう。 NbがXに割り当てられたなら、外国行きのXからYまでのパケットのトンネルヘッダーは以下の通りです:
+---------+---------+---------+
| X -> Na | Nb -> Y | payload |
+---------+---------+---------+
+---------+---------+---------+ | X->Na| Nb->Y| ペイロード| +---------+---------+---------+
Borella, et al. Experimental [Page 6] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[6ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
There are two basic flavors of RSIP: RSA-IP and RSAP-IP. RSIP hosts and gateways MUST support RSAP-IP and MAY support RSA-IP. Details of RSA-IP and RSAP-IP are found in [RSIP-FRAME].
RSIPの2つの基本的な風味があります: RSA-IPとRSAP-IP。 RSIPホストとゲートウェイは、RSAP-IPを支持しなければならなくて、RSA-IPを支持するかもしれません。 RSA-IPとRSAP-IPの細部は[RSIP-FRAME]で見つけられます。
5. Transport Protocol
5. トランスポート・プロトコル
RSIP is an application layer protocol that requires the use of a transport layer protocol for end-to-end delivery of packets.
RSIPはトランスポート層プロトコルの終わりから終わりへのパケットの配信の使用を必要とする応用層プロトコルです。
RSIP gateways MUST support TCP, and SHOULD support UDP. Due to the fact that RSIP may be deployed across a wide variety of network links, RSIP hosts SHOULD support TCP, because of TCP's robustness across said variety of links. However, RSIP hosts MAY support UDP instead of TCP, or both UDP and TCP.
RSIPゲートウェイはTCPを支持しなければなりません、そして、SHOULDはUDPを支持します。 RSIPがさまざまなネットワークリンクの向こう側に配備されるかもしれないという事実のため、RSIPはSHOULDサポートTCPを接待します、前述のバラエティーのリンクの向こう側のTCPの丈夫さのために。 しかしながら、RSIPホストはTCP、または両方の代わりにUDPを支持するかもしれません。UDPとTCP。
For RSIP hosts and gateways using UDP, timeout and retransmissions MUST occur. We recommend a binary exponential backoff scheme with an initial duration of 12.5 ms, and a maximum of six retries (seven total attempts before failure). However, these parameters MAY be adjusted or tuned for specific link types or scenarios.
RSIPホストとUDPを使用するゲートウェイに関しては、タイムアウトと「再-トランスミッション」は現れなければなりません。 私たちは12.5ms、および最大6つの再試行(失敗の前の7つの総試み)の初期の持続時間で2進の指数のbackoff計画を推薦します。 しかしながら、これらのパラメタは、特定のリンク型かシナリオのために調整されるか、または調整されるかもしれません。
Once a host and gateway have established a registration using either TCP or UDP, they may not switch between the two protocols for the duration of the registration. The decision of whether to use TCP or UDP is made by the client, and is determined by the transport protocol of the first packet sent by a client in a successful registration procedure.
ホストとゲートウェイがTCPかUDPのどちらかを使用することでいったん登録を確立すると、彼らは登録の持続時間のために2つのプロトコルを切り換えないかもしれません。 TCPかUDPを使用するかどうかに関する決定は、クライアントによってされて、うまくいっている登録手順でクライアントによって送られた最初のパケットのトランスポート・プロトコルで決定します。
6. Host / Gateway Relationships
6. ホスト/ゲートウェイ関係
An RSIP host can be in exactly one of three fundamental relationships with respect to an RSIP gateway:
RSIPゲートウェイに関してちょうど3つの基本的な関係の1つにはRSIPホストがいることができます:
Unregistered: The RSIP gateway does not know of the RSIP host's
existence, and it will not forward or deliver globally addressed
packets on behalf of the host. The only valid RSIP-related action
for an RSIP host to perform in this state is to request
registration with an RSIP gateway.
登録されていない: RSIPゲートウェイがRSIPホストの存在を知らないで、それは、ホストを代表してグローバルに記述されたパケットを、進めもしませんし、届けもしないでしょう。 RSIPホストがこの状態で実行する唯一の有効なRSIP関連の動作はRSIPゲートウェイによる登録を要求することです。
Registered: The RSIP gateway knows of the RSIP host and has assigned
it a client ID and has specified the flow policies that it
requires of the host. However, no resources, such as addresses or
ports, have been allocated to the host, and the gateway will not
forward or deliver globally addressed packets on behalf of the
host. All registrations have an associated lease time. If this
lease time expires, the RSIP host automatically reverts to the
unregistered state.
登録される: RSIPゲートウェイは、RSIPホストを知って、クライアントIDをそれに割り当てて、それがホストに必要とする流れ方針を指定しました。 しかしながら、アドレスかポートなどのリソースを全くホストに割り当てていなくて、ゲートウェイは、ホストを代表してグローバルに記述されたパケットを、進めもしませんし、届けもしないでしょう。 すべての登録証明書が関連リース時間を過します。 このリース時間が期限が切れるなら、RSIPホストは自動的に登録されていない状態に先祖帰りをします。
Borella, et al. Experimental [Page 7] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[7ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
Assigned: The RSIP gateway has granted one or more bindings of
resources to the host. The gateway will forward and deliver
globally addressed packets on behalf of the host. Each binding
has an associated lease time. If this lease time expires, the
binding is automatically revoked.
割り当てられる: RSIPゲートウェイはホストのリソースの1つ以上の結合を承諾しました。 ゲートウェイは、ホストを代表してグローバルに記述されたパケットを、進めて、届けるでしょう。 各結合は関連リース時間を過します。 このリース時間が期限が切れるなら、結合は自動的に取り消されます。
Architectures in which an RSIP host is simultaneously registered with more than one RSIP gateway are possible. In such cases, an RSIP host may be in different relationships with different RSIP gateways at the same time.
RSIPホストが同時に1RSIP門以上に登録される構造は可能です。 そのような場合、同時に、異なったRSIPゲートウェイとの異なった関係にはRSIPホストがいるかもしれません。
An RSIP gateway MAY redirect an RSIP host to use a tunnel endpoint for data traffic that is not the RSIP gateway itself, or perhaps is a different interface on the RSIP gateway. This is done by specifying the tunnel endpoint's address as part of an assignment. In such an architecture, it is desirable (though not necessary) for the RSIP gateway to have a method with which to notify the tunnel endpoint of assignments, and the expiration status of these assignments.
RSIPゲートウェイは、RSIPゲートウェイ自体でない、または恐らくRSIPゲートウェイの上の異なったインタフェースであるデータ通信量にトンネル終点を使用するためにRSIPホストを向け直すかもしれません。 課題の一部としてトンネル終点のアドレスを指定することによって、これをします。 そのような構造では、RSIPゲートウェイには課題のトンネル終点、およびこれらの課題の満了状態に通知する方法があるのは、望ましいです(必要ではありませんが)。
Lease times for bindings and registrations are managed as follows. All lease times are given in units of seconds from the current time, indicating a time in the future at which the lease will expire. These expiration times are used in the ensuing discussion.
結合と登録証明書のためのリース時間は以下の通り管理されます。 ユニットの秒に現在の時間からすべてのリース回を与えます、リースが期限が切れる未来に時間を示して。 これらの満了時間は続く議論に使用されます。
An initial expiration time (R) is given to a registration. Under this registration, multiple bindings may be established, each with their own expiration times (B1, B2, ...). When each binding is established or extended, the registration expiration time is adjusted so that the registration will last at least as long as the longest lease. In other words, when binding Bi is established or extended, the following calculation is performed: R = max(R, Bi).
初期の満了時間(R)を登録に与えます。 この登録で、複数の結合がそれぞれそれら自身の満了時代(B1、B2)で確立しているかもしれません。 各結合が確立されるか、または広げられるとき、登録満了時間は、登録が最も長いリースと少なくとも同じくらい長い間続くように、調整されます。 言い換えれば、拘束力があるBiが設立されるか、または広げられるとき、以下の計算は実行されます: R=最大である、(R、両性愛者、)
Under this scheme, a registration will never expire while any binding's lease is still valid. However, a registration may expire when the last binding's lease expires, or at some point thereafter.
この計画の下では、どんな結合のリースもまだ有効である間、登録は決して期限が切れないでしょう。 しかしながら、登録は、最後の結合のリースが期限が切れるとき、期限が切れるか、またはその後、いくつかを指すかもしれません。
7. Gateway Flow Policy and State
7. ゲートウェイ流れ方針と状態
Since an RSIP gateway is likely to reside on the boundary between two or more different administrative domains, it is desirable to enable an RSIP gateway to be able to enforce flow-based policy. In other words, an RSIP gateway should have the ability to explicitly control which local addresses and ports are used to communicate with remote addresses and ports.
RSIPゲートウェイが2つ以上の異なった管理ドメインの間の境界に住んでいそうであるので、RSIPゲートウェイが流れベースの方針を実施できるのを可能にするのは望ましいです。 言い換えれば、RSIPゲートウェイには、どのローカルのアドレスとポートがリモートアドレスとポートで交信するのに使用されるかを明らかに制御する能力があるはずです。
In the following, macro-flow policy refers to controlling flow policy at the granularity level of IP addresses, while micro-flow policy refers to controlling flow policy at the granularity of IP address
以下では、マクロ流動方針はIPアドレスの粒状レベルで流れ方針を制御するのを示します、マイクロ流れ方針がIPアドレスの粒状で流れ方針を制御するのを示しますが
Borella, et al. Experimental [Page 8] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[8ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
and port tuples. Of course there may be no policy at all, which indicates that the RSIP gateway does not care about the flow parameters used by RSIP hosts. We consider two levels of local flow policy and three levels of remote flow policy.
そして、tuplesを移植してください。 もちろん、方針が全くないかもしれません、RSIPゲートウェイがRSIPホストによって使用された流れパラメタを心配しないのを示すどれ。 私たちはリモート流れ方針の局所流方針と3つのレベルの2つのレベルを考えます。
7.1. Local Flow Policy
7.1. 局所流方針
Local flow policy determines the granularity of control that an RSIP gateway has over the local addressing parameters that an RSIP host uses for particular sessions.
局所流方針はRSIPゲートウェイがRSIPホストが特定のセッションに使用するローカルのアドレシングパラメタの上に持っているコントロールの粒状を決定します。
Since an RSIP host must use at least an IP address allocated by the gateway, the loosest level of local flow policy is macro-flow based. Under local macro-flow policy, an RSIP host is allocated an IP address (RSA-IP) or an IP address and one or more ports to use with it (RSAP-IP). However, the host may use the ports as it desires for establishing sessions with public hosts.
RSIPホストが少なくともゲートウェイによって割り当てられたIPアドレスを使用しなければならないので、最もゆるいレベルの局所流方針は基づくマクロ流動です。 ローカルのマクロ流動方針の下では、それ(RSAP-IP)と共に使用するIPアドレス(RSA-IP)かIPアドレスと1つ以上のポートをRSIPホストに割り当てます。 しかしながら、ホストは公共のホストとのセッションを確立するために望んでいるようにポートを使用するかもしれません。
Under micro-flow policy, a host is allocated exactly one port at a time. The host may request more ports, also one at a time. This policy gives the gateway very tight control over local port use, although it affords the host less flexibility.
マイクロ流れ方針の下では、まさに一度に1つのポートにホストを割り当てます。 ホストは一度に一つも、より多くのポートを要求するかもしれません。 より少ない柔軟性をホストに提供しますが、この方針は地方のポート使用の非常にきつい支配力をゲートウェイに与えます。
Note that only local macro-flow policy can be used with RSA-IP, while either local macro-flow or local micro-flow policy may be used with RSAP-IP.
RSA-IPと共にローカルのマクロ流動方針しか使用できないことに注意してください、地方のマクロ流動かローカルのマイクロ流れ方針のどちらかがRSAP-IPと共に使用されるかもしれませんが。
Examples of how RSIP flow policy operates are given in Appendix C.
RSIP流れ方針がどう作動するかに関する例はAppendix Cで出されます。
7.2. Remote Flow Policy
7.2. リモート流れ方針
Remote flow policy determines the granularity of control that an RSIP gateway has over the remote (public) hosts with which an RSIP host communicates. In particular, remote flow policy dictates what level of detail that a host must specify addressing parameters of a remote host or application before the RSIP gateway allows the host to communicate with that host or application.
リモート流れ方針はRSIPゲートウェイがRSIPホストと交信するリモートな(公共の)ホストの上に持っているコントロールの粒状を決定します。 特に、リモート流れ方針は、そのホストかアプリケーションとホストがRSIPゲートウェイがホストを許容する前にリモートホストかアプリケーションのパラメタを記述しながら指定しなければならないという詳細のどんなレベルを伝えたらよいかを決めます。
The simplest and loosest form of flow policy is no policy at all. In other words, the RSIP gateway allocates addressing parameters to the host, and the host may use these parameters to communicate with any remote host, without explicitly notifying the gateway.
最も簡単で最もゆるいフォームの流れ方針は全く方針ではありません。 言い換えれば、RSIPゲートウェイはアドレシングパラメタをホストに割り当てます、そして、ホストはどんなリモートホストともコミュニケートするのにこれらのパラメタを使用するかもしれません、明らかにゲートウェイに通知しないで。
Macro-flow policy requires that the host identify the remote address of the host that it wishes to communicate with as part of its request for local addressing parameters. If the request is granted, the host MUST use the specified local parameters only with the remote address specified, and MUST NOT communicate with the remote address using any
マクロ流動方針は、ホストがそれがローカルのアドレシングパラメタに関する要求の一部としてコミュニケートしたがっているホストのリモートアドレスを特定するのを必要とします。 要求が承諾されるなら、ホストは、指定されるリモートアドレスだけと共に指定されたローカルのパラメタを使用しなければならなくて、いずれも使用するリモートアドレスで交信してはいけません。
Borella, et al. Experimental [Page 9] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[9ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
local parameters but the ones allocated. However, the host may contact any port number at the remote host without explicitly notifying the gateway.
ローカルのパラメタにもかかわらず、割り当てられたもの。 しかしながら、明らかにゲートウェイに通知しないで、ホストはリモートホストにおけるどんなポートナンバーにも連絡するかもしれません。
Micro-flow policy requires that the host identify the remote address and port of the host that it wishes to communicate with as part of its request for local addressing parameters. If the request is granted, the host MUST use the specified local parameters only with the remote address and port specified, and MUST NOT communicate with the remote address and port using any local parameters but the ones allocated.
マイクロ流れ方針は、ホストがそれがローカルのアドレシングパラメタに関する要求の一部としてコミュニケートしたがっているホストのリモートアドレスとポートを特定するのを必要とします。 要求が承諾されるなら、ホストは、指定されるリモートアドレスとポートだけと共に指定されたローカルのパラメタを使用しなければならなくて、どんなローカルのパラメタも使用するリモートアドレスとポートにもかかわらず、割り当てるもので交信してはいけません。
Remote flow policy is implemented in both the ingress and egress directions, with respect to the location of the RSIP gateway.
リモート流れ政策はイングレスと出口指示の両方で実施されます、RSIPゲートウェイの位置に関して。
7.3. Gateway State
7.3. ゲートウェー州
An RSIP gateway must maintain state for all RSIP hosts and their assigned resources. The amount and type of state maintained depends on the local and remote flow policy. The required RSIP gateway state will vary based on the RSIP method, but will always include the chosen method's demultiplexing parameters.
RSIPゲートウェイは、すべてのRSIPのための状態がホストと彼らの割り当てられたリソースであることを支持しなければなりません。 維持された状態の量とタイプは地方の、そして、リモートな流れ方針を当てにします。 必要なRSIPゲートウェイ州は、RSIP方法に基づいて異なりますが、いつも選ばれた方法の逆多重化パラメタを含めるでしょう。
7.3.1. RSA-IP State
7.3.1. RSA-IP状態
An RSIP gateway serving an RSIP host using the RSA-IP method MUST maintain the following minimum state to ensure proper mapping of incoming packets to RSIP hosts:
RSIPホストに飲食物をRSA-IP方法を使用することで出すRSIPゲートウェイは入って来るパケットの適切なマッピングをRSIPホストに保証するために以下の最小の状態を維持しなければなりません:
- Host's private address
- Host's assigned public address(es)
- ホストのプライベート・アドレス--ホストは場内放送を割り当てました。(es)
7.3.2. RSAP-IP State
7.3.2. RSAP-IP状態
An RSIP gateway serving an RSIP host using the RSAP-IP method MUST maintain the following minimum state to ensure proper mapping of incoming packets to RSIP hosts:
RSIPホストに飲食物をRSAP-IP方法を使用することで出すRSIPゲートウェイは入って来るパケットの適切なマッピングをRSIPホストに保証するために以下の最小の状態を維持しなければなりません:
- Host's private address
- Host's assigned public address(es)
- Host's assigned port(s) per address
- ホストのプライベート・アドレス--ホストは場内放送(es)を割り当てました--ホストは1アドレスあたりのポートを割り当てました。
7.3.3. Flow State
7.3.3. 流れ状態
Regardless of whether the gateway is using RSA-IP or RSAP-IP, additional state is necessary if either micro-flow based or macro- flow based remote policy is used.
ゲートウェイがRSA-IPかRSAP-IPを使用しているかどうかにかかわらず、どちらかのベースかマクロ流動が基礎づけたマイクロ流れのリモート方針が使用されているなら、追加状態が必要です。
Borella, et al. Experimental [Page 10] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[10ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
If the gateway is using macro-flow based remote policy, the following state must be maintained:
ゲートウェイがリモートな状態で基づくマクロ流動方針を使用しているなら、以下の状態を維持しなければなりません:
- Remote host's address
- リモートホストのアドレス
If the gateway is using micro-flow based remote policy, the following state must be maintained:
ゲートウェイがマイクロ流れるベースのリモート方針を使用しているなら、以下の状態を維持しなければなりません:
- Remote host's address
- Remote host's port
- リモートホストのアドレス--リモートホストのポート
More state MAY be used by an RSIP gateway if desired. For example, ToS/DS bytes may be recorded in order to facilitate quality of service support.
望まれているなら、より多くの状態がRSIPゲートウェイによって使用されるかもしれません。 例えば、ToS/DSバイトは、サービスの質サポートを容易にするために記録されるかもしれません。
8. Parameter Specification and Formats
8. パラメタ仕様と形式
In this section we define the formats for RSIP parameters. Each RSIP message contains one or more parameters that encode the information passed between the host and gateway. The general format of all parameters is TLV (type-length-value) consisting of a 1-byte type followed by a 2-byte length followed by a 'length' byte value as shown below.
このセクションで、私たちはRSIPパラメタのためにフォーマットを定義します。 それぞれのRSIPメッセージはホストとゲートウェイの間で通過された情報をコード化する1つ以上のパラメタを含んでいます。 すべてのパラメタの一般形式は以下に示すようにTLV'長さ'バイトがあとに続いた2バイトの長さがあとに続いた1バイトのタイプから成る(タイプ長さの価値)価値です。
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 | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値… +-+-+-+-+-+-+-+-+-+-+-+
The value field may be divided into a number of other fields as per the type of the parameter. Note that the length field encodes the number of bytes in the value field, NOT the overall number of bytes in the parameter.
値の分野はパラメタのタイプに従って他の多くの分野に分割されるかもしれません。 長さの分野がパラメタのバイトの総合的な数ではなく、値の分野のバイト数をコード化することに注意してください。
8.1. Address
8.1. アドレス
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 | Length | Addrtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address...
+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =1をタイプしてください。| 長さ| Addrtype| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス… +-+-+-+-+-+-+-+-+-+-+-+
Borella, et al. Experimental [Page 11] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[11ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
The address parameter contains addressing information, either an IPv4 address or netmask, an IPv6 address or netmask, or a fully qualified domain name (FQDN). The Addrtype field is 1 byte in length, indicating the type of address.
アドレスパラメタはアドレス指定情報(IPv4アドレスか、ネットマスクか、IPv6アドレスかネットマスクか完全修飾ドメイン名(FQDN)のどちらか)を含んでいます。 アドレスのタイプを示して、長さはAddrtype分野が1バイトです。
Addrtype Length of address field (in bytes)
---- --------------------------------
0 Reserved 0
1 IPv4 4
2 IPv4 netmask 4
3 IPv6 16
4 FQDN varies
アドレス・フィールド(バイトによる)のAddrtype Length---- -------------------------------- 0 4 3IPv6 16 4FQDNが変える予約された0 1IPv4 4 2 IPv4ネットマスク
For FQDN (Fully qualified domain name), the length of the address field will be one less than the value of the length field, and the name will be represented as an ASCII string (no terminating character).
アドレス・フィールドの長さは長さの分野の値よりそれほどFQDN(完全修飾ドメイン名)に関しては、1になるでしょう、そして、名前はASCIIストリング(キャラクタを終えない)として表されるでしょう。
In some cases, it is necessary to specify a "don't care" value for an address. This is signified by a setting the length field to 1 and omitting the value field.
いくつかの場合、「気にかけないでください」という値をアドレスに指定するのが必要です。 これは、長さが1としてさばく設定によって意味されていて、値の分野を省略しています。
It is not valid for a host to request an address with an FQDN type as its local address (See specification of ASSIGN_REQUEST_RSA-IP and ASSIGN_REQUEST_RSAP-IP, below).
ホストがローカルアドレス(以下でASSIGN_REQUEST_RSA-IPとASSIGN_REQUEST_RSAP-IPの仕様を見る)としてFQDNタイプでアドレスを要求するのは、有効ではありません。
8.2. Ports
8.2. ポート
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 | Length | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port number | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =2をタイプしてください。| 長さ| 数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ポートナンバー| ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ports parameter encodes zero or more TCP or UDP ports. When a single port is specified, the value of the number field is 1 and there is one port field following the number field. When more than one port is specified, the value of the number field will indicate the total number of ports contained, and the parameter may take one of two forms. If there is one port field, the ports specified are considered to be contiguous starting at the port number specified in the port field. Alternatively, there may be a number of port fields equal to the value of the number field. The number of port fields can be extrapolated from the length field.
パラメタエンコードがゼロに合わせるか、または、より多くのTCPかUDPが移植するポート。 単一のポートが指定されるとき、ナンバーフィールドの値は1です、そして、ナンバーフィールドに続く1つのポート分野があります。 1つ以上のポートが指定されるとき、ナンバーフィールドの値は、ポートの総数が含んだのを示すでしょう、そして、パラメタは2つのフォームの1つを取るかもしれません。1つのポート分野があれば、ポート分野で指定されたポートナンバーで始まって、指定されたポートが隣接であると考えられます。 あるいはまた、ナンバーフィールドの値と等しい多くのポート分野があるかもしれません。 長さの分野からポート分野の数を推定できます。
Borella, et al. Experimental [Page 12] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[12ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
In some cases, it is necessary to specify a don't care value for one or more ports (e.g., when a client application is using ephemeral source ports). This is accomplished by setting the length field to 1, setting the number field to the number of ports necessary, and omitting all port fields. The value of the number field MUST be greater than or equal to one.
いくつかの場合、それがaを指定するのが値について気にかけないのが1つ以上のポートに必要です(例えば、クライアントアプリケーションはいつはかないソースポートを使用していますか)。 これは長さの分野を1に設定することによって、達成されます、ポートの数に必要なナンバーフィールドを設定して、すべてのポート分野を省略して。 ナンバーフィールドの値は1以上でなければなりません。
If micro-flow based policy applies to a given ports parameter, it MUST contain exactly one port field.
ベースの方針が与えられたポートに当てはまるマイクロ流れパラメタであるなら、それはまさに1つのポート分野を含まなければなりません。
8.3. Lease Time
8.3. リース時間
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 = 3 | Length = 4 | Lease time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =3をタイプしてください。| 長さ=4| リース時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リース時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The lease time parameter specifies the length, in seconds, of an RSIP host registration or parameter binding.
リース時間パラメタはRSIPホスト登録かパラメタ結合の秒に長さを指定します。
8.4. Client ID
8.4. クライアントID
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 = 4 | Length = 4 | Client ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =4をタイプしてください。| 長さ=4| クライアントID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The client ID parameter specifies an RSIP client ID. Client ID's by an RSIP gateway to differentiate RSIP hosts.
クライアントIDパラメタはRSIPクライアントIDを指定します。 クライアントIDがRSIPホストを差別化するRSIPゲートウェイのそばにあります。
8.5. Bind ID
8.5. IDを縛ってください。
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 = 4 | Bind ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bind ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =5をタイプしてください。| 長さ=4| IDを縛ってください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDを縛ってください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bind ID parameter specifies an RSIP bind ID. Bind ID's are used by RSIP hosts and gateways to differentiate an RSIP host's bindings.
ひものIDパラメタはRSIPひものIDを指定します。 Bind IDのものはRSIPホストとゲートウェイによって使用されて、RSIPホストの結合を差別化します。
Borella, et al. Experimental [Page 13] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[13ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
8.6. Tunnel Type
8.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 = 1 | Tunnel type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =6をタイプしてください。| 長さ=1| トンネルタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The tunnel type parameter specifies the type of tunnel used between an RSIP host and an RSIP gateway. Defined tunnel types are:
トンネル型引数はRSIPホストとRSIPゲートウェイの間で使用されるトンネルのタイプを指定します。 定義されたトンネルタイプは以下の通りです。
Tunnel Type
-----------
0 Reserved
1 IP-IP
2 GRE
3 L2TP
トンネルタイプ----------- 0 1予約されたIP-IP2GRE3L2TP
8.7. RSIP Method
8.7. RSIPメソッド
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 = 7 | Length = 1 | RSIP method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =7をタイプしてください。| 長さ=1| RSIPメソッド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RSIP method parameter specifies an RSIP method. Defined RSIP methods are:
RSIPメソッドパラメタはRSIPメソッドを指定します。 定義されたRSIPメソッドは以下の通りです。
RSIP method
-----------
0 Reserved
1 RSA-IP
2 RSAP-IP
RSIPメソッド----------- 0 1予約されたRSA-IP2RSAP-IP
8.8. Error
8.8. 誤り
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Length = 2 | Error |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error |
+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =8をタイプしてください。| 長さ=2| 誤り| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 誤り| +-+-+-+-+-+-+-+-+
The error parameter specifies an error. The currently defined error values are presented in Appendix A.
エラー・パラメータは誤りを指定します。 現在定義された誤り値はAppendix Aに提示されます。
Borella, et al. Experimental [Page 14] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[14ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
8.9. Flow Policy
8.9. 流れ方針
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 = 2 | Local |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote |
+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =9をタイプしてください。| 長さ=2| ローカル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リモート| +-+-+-+-+-+-+-+-+
The flow policy parameter specifies both the local and remote flow policy.
流れ方針パラメタは地方の、そして、リモートな流れ方針を指定します。
Defined local flow policies are:
定義された局所流方針は以下の通りです。
Local Flow Policy
-----------------
0 Reserved
1 Macro flows
2 Micro flows
局所流方針----------------- 0 1Macroの予約された流れ2Microは流れます。
Defined remote flow policies are:
定義されたリモート流れ方針は以下の通りです。
Remote Flow Policy
------------------
0 Reserved
1 Macro flows
2 Micro flows
3 No policy
リモート流れ方針------------------ 0 1回の予約されたMacro流れ2Micro流れ3いいえ方針
8.10. Indicator
8.10. インディケータ
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 | Length = 2 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =10をタイプしてください。| 長さ=2| 値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値| +-+-+-+-+-+-+-+-+
An indicator parameter is a general-purpose parameter, the use of which is defined by the message that it appears in. An RSIP message that uses an indicator parameter MUST define the meaning and interpretation of all of the indicator's possible values.
インディケータパラメタは汎用パラメタです。それの使用はそれが現れるメッセージによって定義されます。 インディケータパラメタを使用するRSIPメッセージはインディケータの可能な値のすべての意味と解釈を定義しなければなりません。
Borella, et al. Experimental [Page 15] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[15ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
8.11. Message Counter
8.11. メッセージカウンタ
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Length = 4 | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =11をタイプしてください。| 長さ=4| カウンタ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | カウンタ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A message counter parameter is used to mark RSIP messages with sequentially-increasing values. Message counters MUST be used with UDP, in order to facilitate reliability.
メッセージカウンタ・パラメータは、連続して増加する値をRSIPメッセージに付けるのに使用されます。 信頼性を容易にするのにUDPと共にメッセージカウンタを使用しなければなりません。
8.12. Vendor Specific Parameter
8.12. ベンダーの特定のパラメタ
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 | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | Subtype | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =12をタイプしてください。| 長さ| ベンダーID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダーID| Subtype| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The vendor specific parameter is used to encode parameters that are defined by a particular vendor. The vendor ID field is the vendor- specific ID assigned by IANA. Subtypes are defined and used by each vendor as necessary. An RSIP host or gateway SHOULD silently ignore vendor-specific messages that it does not understand.
ベンダーの特定のパラメタは、特定のベンダーによって定義されるパラメタをコード化するのに使用されます。 ベンダーID分野はIANAによって割り当てられたベンダーの特定のIDです。 血液型亜型は、必要に応じて各ベンダーによって定義されて、使用されます。 RSIPホストかゲートウェイSHOULDが静かに、分からないというベンダー特有のメッセージを無視します。
9. Message Types
9. メッセージタイプ
RSIP messages consist of three mandatory fields, version, message type, and overall length, followed by one or more required parameters, followed in turn by zero or more optional parameters. In an RSIP message, all required parameters MUST appear in the exact order specified below. Optional parameters MAY appear in any order. Message format is shown below:
RSIPメッセージは3つの義務的な分野から成ります、とバージョン、メッセージタイプ、および全長は1か、より多くの必要なゼロが順番にあとに続いたパラメタか以上の任意のパラメタで後をつけました。 RSIPメッセージでは、すべての必要なパラメタが正確なオーダーで以下で指定されているように見えなければなりません。 任意のパラメタは順不同に現れるかもしれません。 メッセージ・フォーマットは以下に示されます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message type | Overall length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameters...
+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| メッセージタイプ| 全長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パラメタ… +-+-+-+-+-+-+-+-+-+-+
Borella, et al. Experimental [Page 16] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[16ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
The version number field is a single byte and specifies the RSIP version number that is being used. The current RSIP version number is 1.
バージョンナンバーフィールドは、1バイトであり、使用されているRSIPバージョン番号を指定します。 現在のRSIPバージョン番号は1です。
The message type field is a single byte and specifies the message contained in the current packet. There may be only one message per packet. Message types are given numerical assignments in Appendix B.
メッセージタイプ分野は、1バイトであり、現在のパケットに含まれたメッセージを指定します。 1パケットあたり1つのメッセージしかないかもしれません。 Appendix Bの数字の課題をメッセージタイプに与えます。
The overall length field is two bytes and contains the number of bytes in the RSIP message, including the three mandatory fields.
全長分野は、2バイトであり、RSIPメッセージのバイト数を含んでいます、3つの義務的な分野を含んでいて。
Most parameters are only allowed to appear once in each message. The exceptions are as follows:
ほとんどのパラメタが各メッセージに一度現れることができるだけです。 例外は以下の通りです:
- Multiple address parameters MUST appear in ASSIGN_REQUEST_RSA-
IP, ASSIGN_RESPONSE_RSA-IP, ASSIGN_REQUEST_RSAP-IP,
ASSIGN_RESPONSE_RSAP-IP, LISTEN_REQUEST and LISTEN_RESPONSE.
- 複数のアドレスパラメタがASSIGN_REQUEST_RSA IP、ASSIGN_RESPONSE_RSA IP、ASSIGN_REQUEST_RSAP IP、ASSIGN_RESPONSE_RSAP IP、LISTEN_REQUEST、およびLISTEN_RESPONSEに現れなければなりません。
- Multiple ports parameters MUST appear in ASSIGN_REQUEST_RSAP-
IP, ASSIGN_RESPONSE_RSAP-IP, LISTEN_REQUEST and
LISTEN_RESPONSE.
- 複数のポートパラメタがASSIGN_REQUEST_RSAP IP、ASSIGN_RESPONSE_RSAP IP、LISTEN_REQUEST、およびLISTEN_RESPONSEに現れなければなりません。
- Multiple RSIP method and tunnel type parameters MAY appear in
RESISTER_RESPONSE.
- 複数のRSIPメソッドとトンネル型引数はRESISTER_RESPONSEに現れるかもしれません。
- Multiple address parameters and multiple indicator parameters
MAY appear in QUERY_REQUEST and QUERY_RESPONSE.
- 複数のアドレスパラメタと複数のインディケータパラメタがQUERY_REQUESTとQUERY_RESPONSEに現れるかもしれません。
The following message types are defined in BNF. Required parameters are enclosed in <> and MUST appear. Optional parameters are enclosed in [] and MAY appear. Not all message types need to be implemented in order to be RSIP compliant. For example, an RSIP host and/or gateway may not support LISTEN_REQUEST and LISTEN_RESPONSE, or may only support RSAP-IP and not RSA-IP.
以下のメッセージタイプはBNFで定義されます。 必要なパラメタは、<>に同封されて、現れなければなりません。 任意のパラメタは、[]に同封されて、現れるかもしれません。 すべてのメッセージタイプが、RSIP対応であるために実装される必要があるというわけではありません。 例えば、RSIPホスト、そして/または、ゲートウェイは、LISTEN_REQUESTとLISTEN_がRESPONSEであるとサポートしないか、またはRSA-IPではなく、RSAP-IPをサポートするだけであるかもしれません。
9.1. ERROR_RESPONSE
9.1. 誤り_応答
9.1.1. Description
9.1.1. 記述
An ERROR_RESPONSE is used to provide error messages from an RSIP gateway to an RSIP host. Usually, errors indicate that the RSIP gateway cannot or will not perform an action or allocate resources on behalf of the host. If the error is related to a particular client ID or bind ID, these associated parameters MUST be included. Multiple errors MAY NOT be reported in the same ERROR_RESPONSE. In situations where more than one error has occurred, the RSIP gateway MUST choose only one error to report.
ERROR_RESPONSEは、RSIPホストへのRSIPゲートウェイからエラーメッセージを提供するのに使用されます。 通常、誤りは、RSIPゲートウェイが割り当てないことができませんし、動作を実行もしませんし、ホストを代表してリソースを割り当てもしないのを示します。 誤りが特定のクライアントIDかひものIDに関連されるなら、これらの関連パラメタを含まなければなりません。 複数の誤りは同じERROR_RESPONSEで報告されないかもしれません。 1つ以上の誤りが発生した状況で、RSIPゲートウェイは、報告するために1つの誤りだけを選ばなければなりません。
Borella, et al. Experimental [Page 17] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[17ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
9.1.2. Format
9.1.2. 形式
<ERROR_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Error>
[Message Counter]
[Client ID]
[Bind ID]
<誤り_応答>:、:= <バージョン><メッセージタイプ><全長><誤り>[メッセージカウンタ][クライアントID][Bind ID]
9.1.3. Behavior
9.1.3. 振舞い
An ERROR_RESPONSE message MUST only be transmitted by an RSIP gateway. An RSIP host that detects an error in a message received from an RSIP gateway MUST silently discard the message. There are no error conditions that can be caused by an ERROR_RESPONSE. An ERROR_RESPONSE is typically transmitted in response to a request from an RSIP host, but also may be transmitted asynchronously by an RSIP gateway.
RSIPゲートウェイでERROR_RESPONSEメッセージを送るだけでよいです。 RSIPゲートウェイから受け取られたメッセージにおける誤りを検出するRSIPホストは静かにメッセージを捨てなければなりません。 ERROR_RESPONSEによって引き起こされる場合があるエラー条件が全くありません。 ERROR_RESPONSEはRSIPホストからの要求に対応して通常伝えられますが、RSIPゲートウェイによって非同期にまた伝えられるかもしれません。
9.2. REGISTER_REQUEST
9.2. レジスタ_要求
9.2.1. Description
9.2.1. 記述
The REGISTER_REQUEST message is used by an RSIP host to establish registration with an RSIP gateway. An RSIP host MUST register before it requests resources or services from an RSIP gateway. Once an RSIP host has registered with an RSIP gateway, it may not register again until it has de-registered from that gateway.
REGISTER_REQUESTメッセージは、RSIPゲートウェイによる登録を証明するのにRSIPホストによって使用されます。 RSIPゲートウェイからリソースかサービスを要求する前にRSIPホストは登録しなければなりません。 RSIPホストがいったんRSIPゲートウェイとともに記名すると、それは再び反-そのゲートウェイから登録するまで登録されないかもしれません。
9.2.2. Format
9.2.2. 形式
<REGISTER_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
[Message Counter]
<レジスタ_要求>:、:= <バージョン><メッセージタイプ><全長>。[メッセージカウンタ]
9.2.3. Behavior
9.2.3. 振舞い
The following message-specific error conditions exist:
以下のメッセージ特有のエラー条件は存在しています:
- If the host is already registered with the gateway, the gateway
MUST respond with an ERROR_RESPONSE containing the
ALREADY_REGISTERED error and the RSIP host's client ID.
- ホストが既にゲートウェイに登録されるなら、ERROR_RESPONSEがALREADY_REGISTERED誤りとRSIPホストのクライアントIDを含んでいて、ゲートウェイは応じなければなりません。
- If the gateway's policy will not allow the host to register,
the gateway MUST respond with an ERROR_RESPONSE containing the
REGISTRATION_DENIED error.
- ホストがゲートウェイの方針で登録できないなら、ERROR_RESPONSEがREGISTRATION_DENIED誤りを含んでいて、ゲートウェイは応じなければなりません。
Borella, et al. Experimental [Page 18] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[18ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
9.3. REGISTER_RESPONSE
9.3. _応答を登録してください。
9.3.1. Description
9.3.1. 記述
The REGISTER_RESPONSE message is used by an RSIP gateway to confirm the registration of an RSIP host, and to provide a client ID, flow policy, and possibly a message counter and one or more RSIP methods and/or tunnel types.
REGISTER_RESPONSEメッセージはRSIPゲートウェイによって使用されて、RSIPホストの登録を確認して、1つ以上のクライアントID、そして/または、流れ方針とことによるとメッセージカウンタとRSIPメソッド、トンネルタイプを提供します。
9.3.2. Format
9.3.2. 形式
<REGISTER_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Lease time>
<Flow Policy>
[Message Counter]
[RSIP Method]...
[Tunnel Type]...
<レジスタ_応答>:、:= <バージョン><Message Type><Overall Length><Client ID><Lease時間><Flow Policy>[メッセージCounter][RSIP Method]… [トンネルタイプ]…
9.3.3. Behavior
9.3.3. 振舞い
An RSIP gateway MUST assign a different client ID to each host that is simultaneously registered with it. The RSIP gateway MAY respond with one or more RSIP methods and tunnel types that it supports. If an RSIP method is not specified, RSAP-IP MUST be assumed. If a tunnel type is not specified, IP-IP MUST be assumed.
RSIPゲートウェイは同時にそれに登録される各ホストに異なったクライアントIDを割り当てなければなりません。 RSIPゲートウェイはそれがサポートする1つ以上のRSIPメソッドとトンネルタイプで応じるかもしれません。 RSIPメソッドが指定されないなら、RSAP-IPを想定しなければなりません。 トンネルタイプが指定されないなら、IP-IPを想定しなければなりません。
9.4. DE-REGISTER_REQUEST
9.4. 反-レジスタ_要求
9.4.1. Description
9.4.1. 記述
The DE-REGISTER_REQUEST message is used by an RSIP host to de- register with an RSIP gateway. If a host de-registers from the assigned state, all of the host's bindings are revoked. The host SHOULD NOT de-register from the unregistered state.
_REQUESTが通信させるDE-REGISTERは、反-RSIPゲートウェイに登録するのにRSIPホストによって使用されます。 ホストが反-割り当てられた状態から登録するなら、ホストの結合のすべてが取り消されます。 ホストSHOULD NOTは反-登録されていない状態から登録します。
9.4.2. Format
9.4.2. 形式
<DE-REGISTER_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]
<反-レジスタ_は>を要求します:、:= <Version><Messageタイプ><全長><クライアントID>。[メッセージカウンタ]
Borella, et al. Experimental [Page 19] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[19ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
9.4.3. Behavior
9.4.3. 振舞い
The following message-specific error conditions exist:
以下のメッセージ特有のエラー条件は存在しています:
- If the host is not registered with the gateway, the gateway
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- ホストがゲートウェイに登録されないなら、ERROR_RESPONSEがREGISTER_FIRST誤りを含んでいて、ゲートウェイは応じなければなりません。
- If the message contains an incorrect client ID, the gateway
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- メッセージが不正確なクライアントIDを含んでいるなら、ERROR_RESPONSEがBAD_CLIENT_ID誤りを含んでいて、ゲートウェイは応じなければなりません。
If there are no errors that result from this message, the gateway MUST respond with an appropriate DE-REGISTER_RESPONSE. Upon de- registering a host, an RSIP gateway must delete all binds associated with that host and return their resources to the pool of free resources. Once a host has de-registered, it may not use any of the RSIP gateway's resources without registering again.
このメッセージから生じる誤りが全くなければ、ゲートウェイは適切なDE REGISTER_RESPONSEと共に応じなければなりません。 反-ホストを登録すると、RSIPゲートウェイは、そのホストに関連しているすべてのひもを削除して、無料のリソースのプールにそれらのリソースを返さなければなりません。 ホストが反-いったん登録すると、再び登録しないで、それはRSIPゲートウェイのリソースのいずれも使用しないかもしれません。
9.5. DE-REGISTER_RESPONSE
9.5. 反-_応答を登録してください。
9.5.1. Description
9.5.1. 記述
The DE-REGISTER_RESPONSE message is used by an RSIP gateway to confirm the de-registration of an RSIP host or to force an RSIP host to relinquish all of its bindings and terminate its relationship with the RSIP gateway. Upon receiving a DE-REGISTER_RESPONSE message, an RSIP host MUST stop all use of the resources that have been allocated to it by the gateway.
_RESPONSEが通信させるDE-REGISTERはRSIPゲートウェイによって使用されて、RSIPホストの反-登録を確認するか、またはRSIPホストが結合のすべてを放棄して、RSIPゲートウェイとの関係を終えるのを強制します。 _RESPONSEメッセージ、RSIPホストはDE-REGISTERを受けるとゲートウェイによってそれに割り当てられたリソースのすべての使用を止めなければなりません。
9.5.2. Format
9.5.2. 形式
<DE-REGISTER_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]
<反-レジスタ_応答>:、:= <Version><Messageタイプ><全長><クライアントID>。[メッセージカウンタ]
9.5.3. Behavior
9.5.3. 振舞い
An RSIP gateway MUST send a DE-REGISTER_RESPONSE in response to a valid DE-REGISTER_REQUEST. An RSIP gateway MUST send a DE- REGISTER_RESPONSE to an RSIP host when that host's registration lease time times out. An RSIP gateway SHOULD send a DE-REGISTER_RESPONSE if it detects that it will no longer be able to perform RSIP functionality for a given host. An RSIP host MUST be ready to accept a DE-REGISTER_RESPONSE at any moment.
RSIPゲートウェイは有効なDE REGISTER_REQUESTに対応してDE REGISTER_RESPONSEを送らなければなりません。そのホストの登録が時間回の賃借を許可するとき、RSIPゲートウェイはDE REGISTER_RESPONSEをRSIPホストに送らなければなりません。 SHOULDがそれであるならDE REGISTER_RESPONSEを送るRSIPゲートウェイはそれを検出します。それは与えられたホストのためにもうRSIPの機能性を実行できないでしょう。 RSIPホストはいつ何時、DE REGISTER_RESPONSEを受け入れる準備ができているに違いありません。
Borella, et al. Experimental [Page 20] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[20ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
9.6. ASSIGN_REQUEST_RSA-IP
9.6. _要求_RSA-IPを割り当ててください。
9.6.1. Description
9.6.1. 記述
The ASSIGN_REQUEST_RSA-IP message is used by an RSIP host to request resources to use with RSA-IP. Note that RSA-IP cannot be used in combination with micro-flow based local policy.
RSA-IPが通信させるASSIGN_REQUEST_はリソースがRSA-IPと共に使用するよう要求するRSIPホストによって使用されます。 地方であることで基づくマイクロ流れ方針と組み合わせてRSA-IPを使用できないことに注意してください。
9.6.2. Format
9.6.2. 形式
<ASSIGN_REQUEST_RSA-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Address (remote)>
<Ports (remote)>
[Message Counter]
[Lease Time]
[Tunnel Type]
<案配_は_RSA-IP>を要求します:、:= <Version><Messageタイプ><全長><クライアントID><は、(地方)の>の<アドレス(リモート)の><港が(リモート)の>[メッセージカウンタ][リース時間]であると扱います。[トンネルタイプ]
9.6.3. Behavior
9.6.3. 振舞い
The RSIP host specifies two address parameters. The RSIP host may request a particular local address by placing that address in the first address parameter. To indicate that it has no preference for local address, the RSIP host may place a "don't care" value in the address parameter.
RSIPホストは2つのアドレスパラメタを指定します。 RSIPホストは、最初のアドレスパラメタにそのアドレスを置くことによって、特定のローカルアドレスを要求するかもしれません。 それがローカルアドレスのためにどちらでもよいのを示すために、RSIPホストは「気にかけないでください」という値をアドレスパラメタに置くかもしれません。
If macro-flow based remote policy is used, the host MUST specify the remote address that it will use this binding (if granted) to contact; however, the remote port number MAY remain unspecified. If micro- flow based remote policy is used, the host MUST specify the remote address and port number that it will use this binding (if granted) to contact. If no flow policy is used, the RSIP host may place a "don't care" value in the value fields of the respective address and ports parameters.
リモートな状態で基づくマクロ流動方針が使用されているなら、ホストはそれが連絡するのに、この結合(与えるなら)を使用するリモートアドレスを指定しなければなりません。 しかしながら、リモートポートナンバーは不特定のままで残るかもしれません。 ミクロが流れるならベースのリモート方針が使用されている、ホストはそれが連絡するのに、この結合(与えるなら)を使用するリモートアドレスとポートナンバーを指定しなければなりません。 どんな流れ方針も使用されていないなら、RSIPホストは、「気にかけないでください」という値をそれぞれのアドレスの値の分野に置くかもしれなくて、パラメタを移植します。
The following message-specific error conditions exist:
以下のメッセージ特有のエラー条件は存在しています:
- If the host is not registered with the gateway, the gateway
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- ホストがゲートウェイに登録されないなら、ERROR_RESPONSEがREGISTER_FIRST誤りを含んでいて、ゲートウェイは応じなければなりません。
- If the message contains an incorrect client ID, the gateway
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- メッセージが不正確なクライアントIDを含んでいるなら、ERROR_RESPONSEがBAD_CLIENT_ID誤りを含んでいて、ゲートウェイは応じなければなりません。
Borella, et al. Experimental [Page 21] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[21ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
- If the local address parameter is a don't care value and the
RSIP gateway cannot allocate ANY addresses, the RSIP gateway
MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
- RSIPゲートウェイは、ローカルアドレスパラメタがaであるなら値について気にかけないで、どんなアドレスも割り当てることができません、そして、ERROR_RESPONSEがLOCAL_ADDR_UNAVAILABLE誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
- If the local address parameter is not a don't care value there
are three possible error conditions:
- ローカルアドレスパラメタがaが値について気にかけないということでないなら、3つの可能なエラー条件があります:
o If the RSIP gateway cannot allocate ANY addresses, it MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
o RSIPゲートウェイがどんなアドレスも割り当てることができないなら、ERROR_RESPONSEがLOCAL_ADDR_UNAVAILABLE誤りを含んでいて、それは応じなければなりません。
o If the RSIP gateway cannot allocate the requested address
because it is in use, the RSIP gateway MUST respond with an
ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.
o それが使用中であるのでRSIPゲートウェイが要求されたアドレスを割り当てることができないなら、ERROR_RESPONSEがLOCAL_ADDR_椚瀬誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
o If the RSIP gateway cannot allocate the requested address
because it is not allowed by policy, the RSIP gateway MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNALLOWED error.
o それが方針で許容されていないのでRSIPゲートウェイが要求されたアドレスを割り当てることができないなら、ERROR_RESPONSEがLOCAL_ADDR_UNALLOWED誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
- If macro-flow based remote policy is used and the requested
remote address is not allowed by the RSIP gateway's policy, the
RSIP gateway MUST respond with an ERROR_RESPONSE containing the
REMOTE_ADDR_UNALLOWED error.
- リモートな状態で基づくマクロ流動方針が使用されていて、要求されたリモートアドレスがRSIPゲートウェイの方針で許容されていないなら、ERROR_RESPONSEがREMOTE_ADDR_UNALLOWED誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
- If micro-flow based remote policy is used and the requested
remote address / port pair is not allowed by the RSIP gateway's
policy, the RSIP gateway MUST respond with an ERROR_RESPONSE
containing the REMOTE_ADDRPORT_UNALLOWED error.
- マイクロ流れるベースのリモート方針が使用されていて、要求された遠く離れたアドレス/ポート組がRSIPゲートウェイの方針で許容されていないなら、ERROR_RESPONSEがREMOTE_ADDRPORT_UNALLOWED誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
- If an unsupported or unallowed tunnel type is specified, the
RSIP gateway MUST respond with an ERROR_RESPONSE containing the
BAD_TUNNEL_TYPE error.
- サポートされないか非許容されたトンネルタイプが指定されるなら、ERROR_RESPONSEがBAD_TUNNEL_TYPE誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
- If the host has not specified local or remote address or port
information in enough detail, the RSIP gateway MUST respond
with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION
error.
- ホストが十分な詳細にローカルの、または、リモートなアドレスかポート情報を指定していないなら、ERROR_RESPONSEがFLOW_POLICY_VIOLATION誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
9.7. ASSIGN_RESPONSE_RSA-IP
9.7. _応答_RSA-IPを割り当ててください。
9.7.1. Description
9.7.1. 記述
The ASSIGN_RESPONSE_RSA-IP message is used by an RSIP gateway to deliver parameter assignments to an RSIP host using RSA-IP. A host- wise unique bind ID, lease time, and tunnel type must be provided for every assignment.
RSA-IPが通信させるASSIGN_RESPONSE_はRSIPゲートウェイによって使用されて、RSA-IPを使用することでパラメタ課題をRSIPホストに提供します。 ホストの賢明なユニークなひものID、リース時間、およびトンネルタイプをあらゆる課題に提供しなければなりません。
Borella, et al. Experimental [Page 22] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[22ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
9.7.2. Format
9.7.2. 形式
<ASSIGN_RESPONSE_RSA-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Address (remote)>
<Ports (remote)>
<Lease Time>
<Tunnel Type>
[Address (tunnel endpoint)]
[Message Counter]
9.7.3. Behavior
<案配_応答_RSA-IP>:、:= (リモート)の(リモート)の<バージョン><Message Type><Overall Length><Client ID><Bind ID><Address(地方の)の<Lease Time><Tunnel Type><Address><Ports>>[アドレス(トンネル終点)][メッセージCounter]、9.7、.3 振舞い
If no remote flow policy is used, the RSIP gateway MUST use "don't care" values for the remote address and ports parameters. If macro- flow based remote policy is used, the remote address parameter MUST contain the address specified in the associated request, and the remote ports parameter MUST contain a "don't care" value. If micro- flow based remote policy is used, the remote address and remote ports parameters MUST contain the address and port information specified in the associated request.
どんなリモート流れ方針も使用されていないなら、RSIPゲートウェイは、リモートアドレスに「気にかけないでください」という値を使用しなければならなくて、パラメタを移植します。 流れが基礎づけたマクロのリモート方針が使用されているなら、リモートアドレスパラメタは関連要求で指定されたアドレスを含まなければなりません、そして、リモートポートパラメタは「気にかけないでください」という値を含まなければなりません。 ミクロが流れるなら、ベースのリモート方針は使用されています、そして、リモートアドレスと遠く離れたポートパラメタはアドレスを含まなければなりません、そして、ポート情報は関連要求で指定しました。
If the host detects an error or otherwise does not "understand" the gateway's response, it SHOULD send a FREE_REQUEST with the bind ID from the said ASSIGN_RESPONSE_RSA-IP. This will serve to help synchronize the states of the host and gateway.
ホストは、誤りを検出するか、または別の方法でゲートウェイの応答を「理解していません」、それ。SHOULDはひものIDと共に前述の_ASSIGN_RESPONSE RSA-IPから無料_REQUESTを送ります。 これは、ホストとゲートウェイの州を連動させるのを助けるのに役立つでしょう。
The address of a tunnel endpoint that is not the RSIP gateway MAY be specified. If this parameter is not specified, the RSIP gateway MUST be assumed to be the tunnel endpoint.
RSIPゲートウェイでないトンネル終点のアドレスは指定されるかもしれません。 このパラメタが指定されないなら、トンネル終点であるとRSIPゲートウェイを思わなければなりません。
9.8. ASSIGN_REQUEST_RSAP-IP
9.8. _要求_RSAP-IPを割り当ててください。
9.8.1. Description
9.8.1. 記述
The ASSIGN_REQUEST_RSAP-IP message is used by an RSIP host to request resources to use with RSAP-IP. The RSIP host specifies two address and two port parameters, the first of each, respectively, refer to the local address and port(s) that will be used, and the second of each, respectively, refer to the remote address and port(s) that will be contacted.
RSAP-IPが通信させるASSIGN_REQUEST_はリソースがRSAP-IPと共に使用するよう要求するRSIPホストによって使用されます。 RSIPホストが2アドレスを指定して、2は、それぞれパラメタ、それぞれの1番目を移植して、それぞれローカルアドレス、使用されるポート、およびそれぞれの2番目について言及して、リモートアドレスを参照して、連絡される(s)を移植します。
Borella, et al. Experimental [Page 23] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[23ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
9.8.2. Format
9.8.2. 形式
<ASSIGN_REQUEST_RSAP-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
[Message Counter]
[Lease Time]
[Tunnel Type]
<案配_は_RSAP-IP>を要求します:、:= タイプ><全長><クライアントID><が、(地方)の><ポートが(地方)の><アドレス(リモート)><であると扱うという<バージョン><メッセージは(リモート)の>[メッセージカウンタ][リース時間]を移植します。[トンネルタイプ]
9.8.3. Behavior
9.8.3. 振舞い
An RSIP host may request a particular local address by placing that address in the value field of the first address parameter. The RSIP host may request particular local ports by placing them in the first port parameter. To indicate that it has no preference for local address or ports, the RSIP host may place a "don't care" value in the respective address or ports parameters.
RSIPホストは、最初のアドレスパラメタの値の分野にそのアドレスを置くことによって、特定のローカルアドレスを要求するかもしれません。 RSIPホストは、最初のポートパラメタにそれらを置くことによって、特定の地方のポートを要求するかもしれません。 それがローカルアドレスかポートにどちらでもよいのを示すために、RSIPホストは、「気にかけないでください」という値をそれぞれのアドレスに置くかもしれないか、またはパラメタを移植します。
If macro-flow based remote policy is used, the host MUST specify the remote address that it will use this binding (if granted) to contact; however, the remote port number(s) MAY remain unspecified. If micro-flow based remote policy is used, the host MUST specify the remote address and port number(s) that it will use this binding (if granted) to contact. If no flow policy is used, the RSIP host may place a value of all 0's in the value fields of the respective address or port parameters.
リモートな状態で基づくマクロ流動方針が使用されているなら、ホストはそれが連絡するのに、この結合(与えるなら)を使用するリモートアドレスを指定しなければなりません。 しかしながら、リモートポートナンバーは不特定のままで残るかもしれません。 マイクロ流れるベースのリモート方針が使用されているなら、ホストはそれが連絡するのに、この結合(与えるなら)を使用するリモートアドレスとポートナンバーを指定しなければなりません。 どんな流れ方針も使用されていないなら、RSIPホストは、それぞれのアドレスの値の分野のすべての0の値を置くか、またはパラメタを移植するかもしれません。
The following message-specific error conditions exist:
以下のメッセージ特有のエラー条件は存在しています:
- If the host is not registered with the gateway, the gateway
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- ホストがゲートウェイに登録されないなら、ERROR_RESPONSEがREGISTER_FIRST誤りを含んでいて、ゲートウェイは応じなければなりません。
- If the message contains an incorrect client ID, the gateway
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- メッセージが不正確なクライアントIDを含んでいるなら、ERROR_RESPONSEがBAD_CLIENT_ID誤りを含んでいて、ゲートウェイは応じなければなりません。
- If the local address parameter is a don't care value and the
RSIP gateway cannot allocate ANY addresses, the RSIP gateway
MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
- RSIPゲートウェイは、ローカルアドレスパラメタがaであるなら値について気にかけないで、どんなアドレスも割り当てることができません、そして、ERROR_RESPONSEがLOCAL_ADDR_UNAVAILABLE誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
Borella, et al. Experimental [Page 24] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[24ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
- If the local address parameter is not a don't care value there
are five possible error conditions:
- ローカルアドレスパラメタがaが値について気にかけないということでないなら、5つの可能なエラー条件があります:
o If the RSIP gateway cannot allocate ANY addresses, it MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
o RSIPゲートウェイがどんなアドレスも割り当てることができないなら、ERROR_RESPONSEがLOCAL_ADDR_UNAVAILABLE誤りを含んでいて、それは応じなければなりません。
o If the RSIP gateway cannot allocate the requested address
because it is in use, the RSIP gateway MUST respond with an
ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.
o それが使用中であるのでRSIPゲートウェイが要求されたアドレスを割り当てることができないなら、ERROR_RESPONSEがLOCAL_ADDR_椚瀬誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
o If the RSIP gateway cannot allocate the requested address
because it is not allowed by policy, the RSIP gateway MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNALLOWED error.
o それが方針で許容されていないのでRSIPゲートウェイが要求されたアドレスを割り当てることができないなら、ERROR_RESPONSEがLOCAL_ADDR_UNALLOWED誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
o If the RSIP gateway cannot allocate a requested address /
port tuple because it is in use, the RSIP gateway MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDRPORT_INUSE error.
o それが使用中であるのでRSIPゲートウェイが要求されたアドレス/ポートtupleを割り当てることができないなら、ERROR_RESPONSEがLOCAL_ADDRPORT_椚瀬誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
o If the RSIP gateway cannot allocate a requested address /
port tuple because it is not allowed by policy, the RSIP
gateway MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDRPORT_UNALLOWED error.
o それが方針で許容されていないのでRSIPゲートウェイが要求されたアドレス/ポートtupleを割り当てることができないなら、ERROR_RESPONSEがLOCAL_ADDRPORT_UNALLOWED誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
- If the RSIP host requests a number of ports (greater that one),
but does not specify particular port numbers (i.e., uses "don't
care" values) the RSIP gateway cannot grant the entire request,
the RSIP gateway MUST return an ERROR_RESPONSE containing the
LOCAL_ADDRPORT_UNAVAILABLE error.
- RSIPホストがポートの数を要求する、(すばらしさ、それ) RSIPゲートウェイが全体の要求を承諾できない指定港番号(すなわち、「気にかけないでください」という値を使用する)を指定しない以外のいずれのRSIPゲートウェイもLOCAL_ADDRPORT_UNAVAILABLE誤りを含むERROR_RESPONSEを返してはいけません。
- If macro-flow based remote policy is used and the requested
remote address is not allowed by the RSIP gateway's policy, the
RSIP gateway MUST respond with an ERROR_RESPONSE containing the
REMOTE_ADDR_UNALLOWED error.
- リモートな状態で基づくマクロ流動方針が使用されていて、要求されたリモートアドレスがRSIPゲートウェイの方針で許容されていないなら、ERROR_RESPONSEがREMOTE_ADDR_UNALLOWED誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
- If micro-flow based remote policy is used and the requested
remote address / port pair is not allowed by the RSIP gateway's
policy, the RSIP gateway MUST respond with an ERROR_RESPONSE
containing the REMOTE_ADDRPORT_UNALLOWED error.
- マイクロ流れるベースのリモート方針が使用されていて、要求された遠く離れたアドレス/ポート組がRSIPゲートウェイの方針で許容されていないなら、ERROR_RESPONSEがREMOTE_ADDRPORT_UNALLOWED誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
- If an unsupported or unallowed tunnel type is specified, the
RSIP gateway MUST respond with an ERROR_RESPONSE containing the
BAD_TUNNEL_TYPE error.
- サポートされないか非許容されたトンネルタイプが指定されるなら、ERROR_RESPONSEがBAD_TUNNEL_TYPE誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
Borella, et al. Experimental [Page 25] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[25ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
- If the host has not specified local or remote address or port
information in enough detail, the RSIP gateway MUST respond
with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION
error.
- ホストが十分な詳細にローカルの、または、リモートなアドレスかポート情報を指定していないなら、ERROR_RESPONSEがFLOW_POLICY_VIOLATION誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
9.9. ASSIGN_RESPONSE_RSAP-IP
9.9. _応答_RSAP-IPを割り当ててください。
9.9.1. Description
9.9.1. 記述
The ASSIGN_RESPONSE_RSAP-IP message is used by an RSIP gateway to deliver parameter assignments to an RSIP host. A host-wise unique bind ID, lease time, and tunnel type must be provided for every assignment.
RSAP-IPが通信させるASSIGN_RESPONSE_はRSIPゲートウェイによって使用されて、パラメタ課題をRSIPホストに提供します。 ホスト的なユニークなひものID、リース時間、およびトンネルタイプをあらゆる課題に提供しなければなりません。
9.9.2. Format
9.9.2. 形式
<ASSIGN_RESPONSE_RSAP-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<Lease Time>
<Tunnel Type>
[Address (tunnel endpoint)]
[Message Counter]
<案配_応答_RSAP-IP>:、:= (地方)の(リモート)の(リモート)の<バージョン><Message Type><Overall Length><Client ID><Bind ID><Address(地方の)の<Lease Time><Tunnel Type><Ports><Address><Ports>>[アドレス(トンネル終点)][メッセージカウンタ]
9.9.3. Behavior
9.9.3. 振舞い
Regardless of local flow policy, a local address and port(s) MUST be assigned to the host. If macro-flow based local policy is used, the host is assigned an address and one or more ports. If micro-flow based local policy is used, the host is assigned an address and exactly one port.
局所流方針にかかわらず、ローカルアドレスとポートをホストに割り当てなければなりません。 地方であることで基づくマクロ流動方針が使用されているなら、アドレスと1つ以上のポートがホストに割り当てられます。 地方であることで基づくマイクロ流れ方針が使用されているなら、アドレスとまさに1つのポートがホストに割り当てられます。
If no remote flow policy is used, the RSIP gateway MUST use "don't care" values for the remote address and ports parameters. If macro- flow based remote policy is used, the remote address parameter MUST contain the address specified in the associated request, and the remote ports parameter must contain a "don't care" value. If micro- flow based remote policy is used, the remote address and remote ports parameters MUST contain the address and port information specified in the associated request.
どんなリモート流れ方針も使用されていないなら、RSIPゲートウェイは、リモートアドレスに「気にかけないでください」という値を使用しなければならなくて、パラメタを移植します。 流れが基礎づけたマクロのリモート方針が使用されているなら、リモートアドレスパラメタは関連要求で指定されたアドレスを含まなければなりません、そして、リモートポートパラメタは「気にかけないでください」という値を含まなければなりません。 ミクロが流れるなら、ベースのリモート方針は使用されています、そして、リモートアドレスと遠く離れたポートパラメタはアドレスを含まなければなりません、そして、ポート情報は関連要求で指定しました。
Borella, et al. Experimental [Page 26] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[26ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
If the host detects an error or otherwise does not "understand" the gateway's response, it SHOULD send a FREE_REQUEST with the bind ID from the said ASSIGN_RESPONSE_RSAP-IP. This will serve to help synchronize the states of the host and gateway.
ホストは、誤りを検出するか、または別の方法でゲートウェイの応答を「理解していません」、それ。SHOULDはひものIDと共に前述の_ASSIGN_RESPONSE RSAP-IPから無料_REQUESTを送ります。 これは、ホストとゲートウェイの州を連動させるのを助けるのに役立つでしょう。
The address of a tunnel endpoint that is not the RSIP gateway MAY be specified. If this parameter is not specified, the RSIP gateway MUST be assumed to be the tunnel endpoint.
RSIPゲートウェイでないトンネル終点のアドレスは指定されるかもしれません。 このパラメタが指定されないなら、トンネル終点であるとRSIPゲートウェイを思わなければなりません。
9.10. EXTEND_REQUEST
9.10. _要求を広げてください。
9.10.1. Description
9.10.1. 記述
The EXTEND_REQUEST message is used to request a lease extension to a current bind. It may be used with both RSA-IP and RSAP-IP. The host MUST specify its client ID and the bind ID in question, and it MAY suggest a lease time to the gateway.
EXTEND_REQUESTメッセージは、現在のひもにリース拡大を要求するのに使用されます。 それはRSA-IPとRSAP-IPの両方と共に使用されるかもしれません。 ホストはクライアントIDと問題のひものIDを指定しなければなりません、そして、それはリース時間をゲートウェイに示すかもしれません。
9.10.2. Format
9.10.2. 形式
<EXTEND_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
[Lease Time]
[Message Counter]
<は_要求>を広げています:、:= <Version><Messageタイプ><全長><クライアントID><Bind ID>[リース時間][メッセージカウンタ]
9.10.3. Behavior
9.10.3. 振舞い
The following message-specific error conditions exist:
以下のメッセージ特有のエラー条件は存在しています:
- If the host is not registered with the gateway, the gateway
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- ホストがゲートウェイに登録されないなら、ERROR_RESPONSEがREGISTER_FIRST誤りを含んでいて、ゲートウェイは応じなければなりません。
- If the message contains an incorrect client ID, the gateway
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- メッセージが不正確なクライアントIDを含んでいるなら、ERROR_RESPONSEがBAD_CLIENT_ID誤りを含んでいて、ゲートウェイは応じなければなりません。
- If the message contains an incorrect bind ID, the gateway MUST
respond with an ERROR_RESPONSE containing the BAD_BIND_ID
error.
- メッセージが不正確なひものIDを含んでいるなら、ERROR_RESPONSEがBAD_BIND_ID誤りを含んでいて、ゲートウェイは応じなければなりません。
Borella, et al. Experimental [Page 27] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[27ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
If the RSIP gateway grants an extension to the host's lease, it MUST RESPOND with an appropriate EXTEND_RESPONSE message. If the lease is not renewed, the RSIP gateway MAY let it implicitly expire by doing nothing or make it explicitly expire by sending an appropriate FREE_RESPONSE message.
RSIPであるなら、ゲートウェイはホストのリースに拡大を承諾して、それは適切なEXTEND_RESPONSEメッセージがあるMUST RESPONDです。 リースが更新されないなら、RSIPゲートウェイで、何もしないことによってそれとなく期限が切れるか、またはそれは、適切な無料_RESPONSEメッセージを送ることによって、明らかに期限が切れるかもしれません。
9.11. EXTEND_RESPONSE
9.11. _応答を広げてください。
9.11.1. Description
9.11.1. 記述
The EXTEND_RESPONSE message is used by an RSIP gateway to grant a requested lease extension. The gateway MUST specify the client ID of the host, the bind ID in question, and the new assigned lease time.
EXTEND_RESPONSEメッセージはRSIPゲートウェイによって使用されて、要求されたリース拡大を承諾します。 ゲートウェイはホストのクライアントID、問題のひものID、および新しい割り当てられたリース時間を指定しなければなりません。
9.11.2. Format
9.11.2. 形式
<EXTEND_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Lease Time>
[Message Counter]
<は_応答>を広げています:、:= <バージョン><メッセージタイプ><全長><クライアントID><ひものID><リース時間>。[メッセージカウンタ]
9.11.3. Behavior
9.11.3. 振舞い
The RSIP gateway will determine lease time as per its local policy. The returned time is to be interpreted as the number of seconds before the lease expires, counting from the time at which the message is sent/received.
RSIPゲートウェイはローカルの方針に従ってリース時間を測定するでしょう。 返された時間はリースが期限が切れる前に秒数として解釈されることです、メッセージが送るか、または受信されている時から数えて。
9.12. FREE_REQUEST
9.12. 無料の_要求
9.12.1. Description
9.12.1. 記述
The FREE_REQUEST message is used by an RSIP host to free a binding. The given bind ID identifies the bind to be freed. Resources may only be freed using the granularity of a bind ID.
無料_REQUESTメッセージは、結合を解放するのにRSIPホストによって使用されます。 与えられたひものIDは、解放されるためにひもを特定します。 リソースは、ひものIDの粒状を使用することで解放されるだけであるかもしれません。
9.12.2. Format
9.12.2. 形式
<FREE_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
[Message Counter]
<の無料_要求>:、:= <Version><Messageタイプ><全長><クライアントID><Bind ID>。[メッセージカウンタ]
Borella, et al. Experimental [Page 28] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[28ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
9.12.3. Behavior
9.12.3. 振舞い
The following message-specific error conditions exist:
以下のメッセージ特有のエラー条件は存在しています:
- If the host is not registered with the gateway, the gateway
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- ホストがゲートウェイに登録されないなら、ERROR_RESPONSEがREGISTER_FIRST誤りを含んでいて、ゲートウェイは応じなければなりません。
- If the message contains an incorrect client ID, the gateway
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- メッセージが不正確なクライアントIDを含んでいるなら、ERROR_RESPONSEがBAD_CLIENT_ID誤りを含んでいて、ゲートウェイは応じなければなりません。
- If the message contains an incorrect bind ID, the gateway MUST
respond with an ERROR_RESPONSE containing the BAD_BIND_ID
error.
- メッセージが不正確なひものIDを含んでいるなら、ERROR_RESPONSEがBAD_BIND_ID誤りを含んでいて、ゲートウェイは応じなければなりません。
If a host receives an error in response to a FREE_REQUEST, this may indicate that the host and gateway's states have become unsynchronized. Therefore, the host SHOULD make an effort to resynchronize, such as freeing resources then re-requesting them, or de-registering then re-registering.
ホストが無料_REQUESTに対応して誤りを受けるなら、これは、ホストとゲートウェイの州が非連動するようになったのを示すかもしれません。 したがって、ホストSHOULDは次にそれらを再要求するリソースを解放するのなどように再連動させる取り組みか反-登録を次に、再登録するようにします。
9.13. FREE_RESPONSE
9.13. 無料の_応答
9.13.1. Description
9.13.1. 記述
The FREE_RESPONSE message is used by an RSIP gateway to acknowledge a FREE_REQUEST sent by an RSIP host, and to asynchronously deallocate resources granted to an RSIP host.
無料_RESPONSEメッセージはRSIPゲートウェイによって使用されて、REQUESTがRSIPホストで送った無料_を承認して、RSIPホストに与えられたリソースを非同期に「反-割り当て」ます。
9.13.2. Format
9.13.2. 形式
<FREE_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
[Message Counter]
<の無料の_応答>:、:= <Version><Messageタイプ><全長><クライアントID><Bind ID>。[メッセージカウンタ]
9.13.3. Behavior
9.13.3. 振舞い
An RSIP host must always be ready to accept a FREE_RESPONSE, even if its lease on the specified bind ID is not yet expired.
RSIPホストはいつも無料_RESPONSEを受け入れる準備ができているに違いありません、指定されたひものIDにおけるリースがまだ吐き出されないでも。
Borella, et al. Experimental [Page 29] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[29ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
9.14. QUERY_REQUEST
9.14. 質問_要求
9.14.1. Description
9.14.1. 記述
A QUERY_REQUEST message is used by an RSIP host to ask an RSIP gateway whether or not a particular address or network is local or remote. The host uses this information to determine whether to contact the host(s) directly (in the local case), or via RSIP (in the remote case).
QUERY_REQUESTメッセージは、特定のアドレスかネットワークがローカルである、またはリモートであるかどうかRSIPゲートウェイに尋ねるのにRSIPホストによって使用されます。 ホストは、直接(ローカルの場合で)かRSIP(リモート場合における)を通してホストに連絡するかどうか決定するのにこの情報を使用します。
This message defines an indicator parameter with a 1-byte value field and 2 defined values:
このメッセージは1バイトの値の分野でインディケータパラメタを定義します、そして、2は値を定義しました:
- 1 address
- 2 network
- 1つのアドレス--2ネットワーク
9.14.2. Format
9.14.2. 形式
<QUERY_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]
[Address Tuple]...
[Network Tuple]...
where
<質問_要求>:、:= <Version><Messageタイプ><全長><クライアントID>[メッセージカウンタ][アドレスTuple]… [ネットワークTuple]… どこ
<Address Tuple> ::= <Indicator (address)>
<Address>
<アドレスTuple>:、:= <インディケータ(アドレス)><アドレス>。
<Network Tuple> ::= <Indicator (network)>
<Address (network)>
<Address (netmask)>
<ネットワークTuple>:、:= <インディケータ(ネットワーク)><アドレス(ネットワーク)><アドレス(ネットマスク)>。
9.14.3. Behavior
9.14.3. 振舞い
One or more address or network tuples may be specified. Each tuple encodes a request regarding the locality (local or remote) of the encoded address or network. If no tuple is specified, the RSIP gateway should interpret the message as a request for all tuples that it is willing to provide. Note that the FQDN form of the address parameter cannot be used to specify the address of a network, and only the netmask form of the address parameter can be used to specify the netmask of a network.
1つ以上のアドレスかネットワークtuplesが指定されるかもしれません。 各tupleはコード化されたアドレスかネットワークにおける(地方かリモート)の場所に関する要求をコード化します。 tupleが全く指定されないなら、RSIPゲートウェイはすべてのtuplesを求める提供しても構わないと思っているという要求としてメッセージを解釈するはずです。 ネットワークのアドレスを指定するのにアドレスパラメタのFQDNフォームを使用できないで、ネットワークに関するネットマスクを指定するのにアドレスパラメタのネットマスクフォームだけを使用できることに注意してください。
If an RSIP gateway cannot determine whether a queried host or network is local or remote, it SHOULD transmit a QUERY_RESPONSE with no response specified for the said host or network.
RSIPゲートウェイであるなら質問されたホストかネットワークがローカルである、またはリモートであるかを決定できません、それ。SHOULDは前述のホストかネットワークに指定された応答なしでQUERY_RESPONSEを伝えます。
Borella, et al. Experimental [Page 30] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[30ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
The following message-specific error conditions exist:
以下のメッセージ特有のエラー条件は存在しています:
- If the host is not registered with the gateway, the gateway
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- ホストがゲートウェイに登録されないなら、ERROR_RESPONSEがREGISTER_FIRST誤りを含んでいて、ゲートウェイは応じなければなりません。
- If the message contains an incorrect client ID, the gateway
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- メッセージが不正確なクライアントIDを含んでいるなら、ERROR_RESPONSEがBAD_CLIENT_ID誤りを含んでいて、ゲートウェイは応じなければなりません。
9.15. QUERY_RESPONSE
9.15. 質問_応答
9.15.1. Description
9.15.1. 記述
A QUERY_RESPONSE message is used by an RSIP gateway to answer a QUERY_REQUEST from an RSIP host.
QUERY_RESPONSEメッセージはRSIPゲートウェイによって使用されて、RSIPホストからQUERY_REQUESTに答えます。
This message defines an indicator parameter with a 1-byte value field and 4 defined values:
このメッセージは1バイトの値の分野でインディケータパラメタを定義します、そして、4は値を定義しました:
- 1 local address
- 2 local network
- 3 remote address
- 4 remote network
- 1 2ローカルアドレス--企業内情報通信網--3のリモートアドレス--4のリモートネットワーク
9.15.2. Format
9.15.2. 形式
<QUERY_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]
[Local Address Tuple]...
[Local Network Tuple]...
[Remote Address Tuple]...
[Remote Network Tuple]...
<質問_応答>:、:= <Version><Messageタイプ><全長><クライアントID>[メッセージカウンタ][ローカルアドレスTuple]… [企業内情報通信網Tuple]… [リモートアドレスTuple]… [リモートネットワークTuple]…
where
どこ
<Local Address Tuple> ::= <Indicator (local address)>
<Address>
<ローカルアドレスTuple>:、:= <インディケータ(ローカルアドレス)><Address>。
<Local Network Tuple> ::= <Indicator (local network)>
<Address (network)>
<Address (netmask)>
<企業内情報通信網Tuple>:、:= <インディケータ(企業内情報通信網)><Address(ネットワーク)><Address(ネットマスク)>。
<Remote Address Tuple> ::= <Indicator (remote address)>
<Address>
<のリモートアドレスTuple>:、:= <インディケータ(リモートアドレス)><Address>。
Borella, et al. Experimental [Page 31] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[31ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
<Remote Network Tuple> ::= <Indicator (remote network)>
<Address (network)>
<Address (netmask)>
<のリモートネットワークTuple>:、:= <インディケータ(リモートネットワーク)><Address(ネットワーク)><Address(ネットマスク)>。
9.15.3. Behavior
9.15.3. 振舞い
An RSIP gateway has some leeway in how it responds to a QUERY_REQUEST. It may just provide the information requested, if it can provide such information. It may provide its complete list of address and networks, in order to minimize the number of requests that the host needs to perform in the future. How an RSIP gateway responds may depend on network traffic considerations as well.
RSIPゲートウェイには、どうQUERY_REQUESTに応じるかの何らかの余裕があります。それはただそのような情報を提供できるなら要求された情報を提供するかもしれません。 それはアドレスとネットワークに関する全リストを提供するかもしれません、ホストが、将来働く必要があるという要求の数を最小にするために。 RSIPゲートウェイがどう応じるかはまた、ネットワークトラフィック問題によるかもしれません。
If an RSIP gateway sends a QUERY_RESPONSE that does not contain any tuples, or a QUERY_RESPONSE that does not contain a tuple that applies to an associated tuple in the associated QUERY_REQUEST, this should be interpreted that the RSIP gateway does not know whether the queried host or network is local or remote. Appropriate host behavior upon receipt of such a message is to assume that the queried host or network is remote.
RSIPゲートウェイが関連QUERY_REQUESTに関連tupleに適用されるtupleを含まないどんなtuples、またはQUERY_RESPONSEも含まないQUERY_RESPONSEを送るなら、これは解釈されるべきです。RSIPゲートウェイは、質問されたホストかネットワークがローカルである、またはリモートであるかを知りません。 そのようなメッセージを受け取り次第適切なホストの振舞いは質問されたホストかネットワークがリモートであると仮定することです。
Note that an RSIP gateway is not expected to maintain a complete list of all remote hosts and networks. In fact, a typical RSIP gateway will only maintain a list of the networks and hosts that it knows are local (private with respect to the RSIP host).
RSIPゲートウェイがすべてのリモートホストとネットワークに関する全リストを維持しないと予想されることに注意してください。 事実上、典型的なRSIPゲートウェイはネットワークとそれがローカルであることを知っているホストのリストを(RSIPホストに関して個人的)であるのに維持するだけでしょう。
9.16. LISTEN_REQUEST
9.16. _要求を聴いてください。
9.16.1. Description
9.16.1. 記述
A LISTEN_REQUEST message is sent by an RSIP host that wants to register a service on a particular address and port number. The host must include its client ID, local address parameter and ports parameters, and remote address and ports parameters. The client MAY suggest a lease time and one or more tunnel types.
LISTEN_REQUESTメッセージは特定のアドレスとポートナンバーにサービスを登録したがっているRSIPホストによって送られます。 ホストは、クライアントID、ローカルアドレスパラメタとポートパラメタ、およびリモートアドレスを含まなければならなくて、パラメタを移植します。 クライアントは、リース時間と1つ以上のトンネルがタイプされることを提案するかもしれません。
Borella, et al. Experimental [Page 32] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[32ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
9.16.2. Format
9.16.2. 形式
<LISTEN_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
[Message Counter]
[Lease Time]
[Tunnel Type]...
<は_要求>を聴きます:、:= タイプ><全長><クライアントID><が、(地方)の><ポートが(地方)の><アドレス(リモート)><であると扱うという<バージョン><メッセージは(リモート)の>[メッセージカウンタ][リース時間][トンネルタイプ]を移植します…
9.16.3. Behavior
9.16.3. 振舞い
If the host wants to listen on a particular address or port, it may specify these in the address and ports parameters. Otherwise it may leave one or both of these parameters with "don't care" values.
ホストが特定のアドレスかポートの上で聴きたいなら、それは、アドレスでこれらを指定するかもしれなくて、パラメタを移植します。 さもなければ、それは「気にかけないでください」という値があるパラメタにこれらの1か両方を残すかもしれません。
If no remote flow policy is being used, the host MUST fill both the remote address and ports parameters with "don't care" values. If macro-flow based remote policy is used, the host MUST specify the remote address, but MAY or MAY NOT specify the remote port(s). If micro-flow based remote policy is used, the host MUST specify the remote address and ports parameter.
どんなリモート流れ方針も使用されていないなら、ホストは「気にかけないでください」という値で両方のリモートアドレスとポートパラメタをいっぱいにしなければなりません。 リモートな状態で基づくマクロ流動方針が使用されているなら、ホストは、リモートアドレスを指定しなければなりませんが、遠く離れたポートを指定するかもしれません。 マイクロ流れるベースのリモート方針が使用されているなら、ホストは、リモートアドレスを指定しなければならなくて、パラメタを移植します。
Once a LISTEN_REQUEST has been granted, the RSIP gateway MUST forward all packets destined to the address and port in question to the host, even if the remote host address and port tuple has not been previously contacted by the host.
いったんLISTEN_REQUESTを与えると、RSIPゲートウェイはホストにとって、問題のアドレスとポートに運命づけられたすべてのパケットを進めなければなりません、リモートホストのアドレスとポートtupleが以前にホストによって連絡されていなくても。
LISTEN_REQUEST is not necessary for RSA-IP.
LISTEN_REQUESTはRSA-IPに必要ではありません。
The following message-specific error conditions exist:
以下のメッセージ特有のエラー条件は存在しています:
- If the host is not registered with the gateway, the gateway
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- ホストがゲートウェイに登録されないなら、ERROR_RESPONSEがREGISTER_FIRST誤りを含んでいて、ゲートウェイは応じなければなりません。
- If the message contains an incorrect client ID, the gateway
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- メッセージが不正確なクライアントIDを含んでいるなら、ERROR_RESPONSEがBAD_CLIENT_ID誤りを含んでいて、ゲートウェイは応じなければなりません。
- If the local address parameter is a don't care value and the
RSIP gateway cannot allocate ANY addresses, the RSIP gateway
MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
- RSIPゲートウェイは、ローカルアドレスパラメタがaであるなら値について気にかけないで、どんなアドレスも割り当てることができません、そして、ERROR_RESPONSEがLOCAL_ADDR_UNAVAILABLE誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
Borella, et al. Experimental [Page 33] RFC 3103 RSIP Protocol Specification October 2001
Borella、他 実験的な[33ページ]RFC3103RSIPは仕様2001年10月に議定書を作ります。
- If the local address parameter is not a don't care value there
are five possible error conditions:
- ローカルアドレスパラメタがaが値について気にかけないということでないなら、5つの可能なエラー条件があります:
o If the RSIP gateway cannot allocate ANY addresses, it MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
o RSIPゲートウェイがどんなアドレスも割り当てることができないなら、ERROR_RESPONSEがLOCAL_ADDR_UNAVAILABLE誤りを含んでいて、それは応じなければなりません。
o If the RSIP gateway cannot allocate the requested address
because it is in use, the RSIP gateway MUST respond with an
ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.
o それが使用中であるのでRSIPゲートウェイが要求されたアドレスを割り当てることができないなら、ERROR_RESPONSEがLOCAL_ADDR_椚瀬誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
o If the RSIP gateway cannot allocate the requested address
because it is not allowed by policy, the RSIP gateway MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNALLOWED error.
o それが方針で許容されていないのでRSIPゲートウェイが要求されたアドレスを割り当てることができないなら、ERROR_RESPONSEがLOCAL_ADDR_UNALLOWED誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
o If the RSIP gateway cannot allocate the requested address /
port tuple because it is in use, the RSIP gateway MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDRPORT_INUSE error.
o それが使用中であるのでRSIPゲートウェイが要求されたアドレス/ポートtupleを割り当てることができないなら、ERROR_RESPONSEがLOCAL_ADDRPORT_椚瀬誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
o If the RSIP gateway cannot allocate the requested address /
port tuple because it is not allowed by policy, the RSIP
gateway MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDRPORT_UNALLOWED error.
o それが方針で許容されていないのでRSIPゲートウェイが要求されたアドレス/ポートtupleを割り当てることができないなら、ERROR_RESPONSEがLOCAL_ADDRPORT_UNALLOWED誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
- If macro-flow based remote policy is used and the requested
remote address is not allowed by the RSIP gateway's policy, the
RSIP gateway MUST respond with an ERROR_RESPONSE containing the
REMOTE_ADDR_UNALLOWED error.
- リモートな状態で基づくマクロ流動方針が使用されていて、要求されたリモートアドレスがRSIPゲートウェイの方針で許容されていないなら、ERROR_RESPONSEがREMOTE_ADDR_UNALLOWED誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
- If micro-flow based remote policy is used and the requested
remote address / port pair is not allowed by the RSIP gateway's
policy, the RSIP gateway MUST respond with an ERROR_RESPONSE
containing the REMOTE_ADDRPORT_UNALLOWED error.
- マイクロ流れるベースのリモート方針が使用されていて、要求された遠く離れたアドレス/ポート組がRSIPゲートウェイの方針で許容されていないなら、ERROR_RESPONSEがREMOTE_ADDRPORT_UNALLOWED誤りを含んでいて、RSIPゲートウェイは応じなければなりません。
- If an unsupported or unallowed tunnel type is specified, the
RSIP gateway MUST respond with an ERROR_RESPONSE containing the
BAD_TUNNEL_TYPE error.
- If an unsupported or unallowed tunnel type is specified, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the BAD_TUNNEL_TYPE error.
- If the host has not specified local or remote address or port
information in enough detail, the RSIP gateway MUST respond
with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION
error.
- If the host has not specified local or remote address or port information in enough detail, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION error.
Borella, et al. Experimental [Page 34] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 34] RFC 3103 RSIP Protocol Specification October 2001
9.17. LISTEN_RESPONSE
9.17. LISTEN_RESPONSE
9.17.1. Description
9.17.1. Description
A LISTEN_RESPONSE message is used by an RSIP gateway to respond to a LISTEN_REQUEST message from an RSIP host. The RSIP gateway MUST issue a bind ID, and specify the address and port which have been granted to the host. The gateway must also specify a tunnel type and lease time.
A LISTEN_RESPONSE message is used by an RSIP gateway to respond to a LISTEN_REQUEST message from an RSIP host. The RSIP gateway MUST issue a bind ID, and specify the address and port which have been granted to the host. The gateway must also specify a tunnel type and lease time.
If no remote flow policy is being used, the gateway MUST fill both the remote address and ports parameters with "don't care" values. If macro-flow based remote policy is used, the gateway MUST specify the remote address, but MAY or MAY NOT specify the remote port(s). If micro-flow based remote policy is used, the gateway MUST specify the remote address and ports parameter.
If no remote flow policy is being used, the gateway MUST fill both the remote address and ports parameters with "don't care" values. If macro-flow based remote policy is used, the gateway MUST specify the remote address, but MAY or MAY NOT specify the remote port(s). If micro-flow based remote policy is used, the gateway MUST specify the remote address and ports parameter.
9.17.2. Format
9.17.2. Format
<LISTEN_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<Tunnel Type>
<Lease Time>
[Address (tunnel endpoint)]
[Message Counter]
<LISTEN_RESPONSE> ::= <Version> <Message Type> <Overall Length> <Client ID> <Bind ID> <Address (local)> <Ports (local)> <Address (remote)> <Ports (remote)> <Tunnel Type> <Lease Time> [Address (tunnel endpoint)] [Message Counter]
9.17.3. Behavior
9.17.3. Behavior
If no remote flow policy is being used, the gateway MUST fill both the remote address and ports parameters with "don't care" values. If macro-flow based remote policy is used, the gateway MUST specify the remote address, but MAY or MAY NOT specify the remote port(s). If micro-flow based remote policy is used, the gateway MUST specify the remote address and ports parameter.
If no remote flow policy is being used, the gateway MUST fill both the remote address and ports parameters with "don't care" values. If macro-flow based remote policy is used, the gateway MUST specify the remote address, but MAY or MAY NOT specify the remote port(s). If micro-flow based remote policy is used, the gateway MUST specify the remote address and ports parameter.
The address of a tunnel endpoint that is not the RSIP gateway MAY be specified. If this parameter is not specified, the RSIP gateway MUST be assumed to be the tunnel endpoint.
The address of a tunnel endpoint that is not the RSIP gateway MAY be specified. If this parameter is not specified, the RSIP gateway MUST be assumed to be the tunnel endpoint.
Borella, et al. Experimental [Page 35] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 35] RFC 3103 RSIP Protocol Specification October 2001
10. Discussion
10. Discussion
10.1. Use of Message Counters, Timeouts, and Retransmissions
10.1. Use of Message Counters, Timeouts, and Retransmissions
Message counters are conceptually similar to sequence numbers. They are necessary to facilitate reliability when UDP is the transport protocol. Each UDP message is marked with a message counter. When such a message is transmitted, the message is stored in a "last message" buffer. For RSIP hosts, a timer is set to expire at the appropriate timeout value.
Message counters are conceptually similar to sequence numbers. They are necessary to facilitate reliability when UDP is the transport protocol. Each UDP message is marked with a message counter. When such a message is transmitted, the message is stored in a "last message" buffer. For RSIP hosts, a timer is set to expire at the appropriate timeout value.
General rules:
General rules:
- When an RSIP host transmits a message with a message counter
value of n, the RSIP gateway's response will contain a message
counter value of n.
- When an RSIP host transmits a message with a message counter value of n, the RSIP gateway's response will contain a message counter value of n.
- An RSIP host will not increment its message counter value to
n+1 until it receives a message from the RSIP gateway with a
message counter value of n.
- An RSIP host will not increment its message counter value to n+1 until it receives a message from the RSIP gateway with a message counter value of n.
- An RSIP gateway begins all sessions with a message counter
value of 1.
- An RSIP gateway begins all sessions with a message counter value of 1.
- If the message counter value reaches the maximum possible 32-
bit value, it will wrap around to 1, not 0.
- If the message counter value reaches the maximum possible 32- bit value, it will wrap around to 1, not 0.
- If a message with a message counter value of n is transmitted
by an RSIP host, but a timer expires before a response to that
message is received, the copy of the message (from the "last
message" buffer) is retransmitted.
- If a message with a message counter value of n is transmitted by an RSIP host, but a timer expires before a response to that message is received, the copy of the message (from the "last message" buffer) is retransmitted.
- When an RSIP gateway receives a duplicate copy of a message
with a message counter value of n, it transmits the contents of
its "last message" buffer.
- When an RSIP gateway receives a duplicate copy of a message with a message counter value of n, it transmits the contents of its "last message" buffer.
- When the RSIP gateway transmits an asynchronous RSIP message
(an RSIP message for which there was no request by the RSIP
host), a message counter value of 0 MUST be used. Note that
only three RSIP messages can be transmitted asynchronously:
ERROR_RESPONSE, DE-REGISTER_RESPONSE, and FREE_RESPONSE. These
messages may also be transmitted in response to an RSIP host
request, so their message counter values MAY be non-zero.
- When the RSIP gateway transmits an asynchronous RSIP message (an RSIP message for which there was no request by the RSIP host), a message counter value of 0 MUST be used. Note that only three RSIP messages can be transmitted asynchronously: ERROR_RESPONSE, DE-REGISTER_RESPONSE, and FREE_RESPONSE. These messages may also be transmitted in response to an RSIP host request, so their message counter values MAY be non-zero.
- If a message counter is not present in a message from an RSIP
host, but is required, the RSIP gateway MUST respond with an
ERROR_RESPONSE containing the MESSAGE_COUNTER_REQUIRED error.
- If a message counter is not present in a message from an RSIP host, but is required, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the MESSAGE_COUNTER_REQUIRED error.
Borella, et al. Experimental [Page 36] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 36] RFC 3103 RSIP Protocol Specification October 2001
10.2. RSIP Host and Gateway Failure Scenarios
10.2. RSIP Host and Gateway Failure Scenarios
When either the RSIP host or gateway suffers from an unrecoverable failure, such as a crash, all RSIP-related state will be lost. In this section, we describe the sequence of events that will occur in both host and gateway failures, and how the host and gateway re- synchronize.
When either the RSIP host or gateway suffers from an unrecoverable failure, such as a crash, all RSIP-related state will be lost. In this section, we describe the sequence of events that will occur in both host and gateway failures, and how the host and gateway re- synchronize.
10.2.1. Host Failure
10.2.1. Host Failure
After a host failure, the host will reboot and be unaware of any RSIP state held on its behalf at the gateway.
After a host failure, the host will reboot and be unaware of any RSIP state held on its behalf at the gateway.
If the host does not immediately attempt to re-establish a session, it may receive RSIP packets on the RSIP client application port that it was using before it rebooted. If an RSIP client application is not active on this port, these packets will be responded to with ICMP port unreachable messages. If TCP is the transport protocol, it is likely that the connection will be terminated with a TCP RST. If an RSIP client is active on this port, it will not recognize the session that these packets belong to, and it SHOULD silently ignore them.
If the host does not immediately attempt to re-establish a session, it may receive RSIP packets on the RSIP client application port that it was using before it rebooted. If an RSIP client application is not active on this port, these packets will be responded to with ICMP port unreachable messages. If TCP is the transport protocol, it is likely that the connection will be terminated with a TCP RST. If an RSIP client is active on this port, it will not recognize the session that these packets belong to, and it SHOULD silently ignore them.
The RSIP host may also receive packets from a remote host with which it was communicating before it rebooted. These packets will be destined to the RSIP tunnel interface, which should not exist. Thus they SHOULD be silently discarded by the RSIP host's stack, or the RSIP host will transmit appropriate ICMP messages to the tunnel endpoint (e.g., the RSIP gateway). The behavior of the system with respect to sessions that were active before the reboot should be similar to that of a publically addressable non-RSIP host that reboots.
The RSIP host may also receive packets from a remote host with which it was communicating before it rebooted. These packets will be destined to the RSIP tunnel interface, which should not exist. Thus they SHOULD be silently discarded by the RSIP host's stack, or the RSIP host will transmit appropriate ICMP messages to the tunnel endpoint (e.g., the RSIP gateway). The behavior of the system with respect to sessions that were active before the reboot should be similar to that of a publically addressable non-RSIP host that reboots.
Upon rebooting, an RSIP host may attempt to establish a new RSIP session with the RSIP gateway. Upon receiving the REGISTER_REQUEST message, the RSIP gateway will be able to determine that, as far as it is concerned, the RSIP host is already registered. Thus, it will transmit an ERROR_RESPONSE with the ALREADY_REGISTERED message. Upon receipt of this message, the RSIP host will know the client ID of its old registration, and SHOULD immediately transmit a DE- REGISTER_REQUEST using this client ID. After this is accomplished, the states of the RSIP host and gateway have been synchronized, and a new RSIP session may be established.
Upon rebooting, an RSIP host may attempt to establish a new RSIP session with the RSIP gateway. Upon receiving the REGISTER_REQUEST message, the RSIP gateway will be able to determine that, as far as it is concerned, the RSIP host is already registered. Thus, it will transmit an ERROR_RESPONSE with the ALREADY_REGISTERED message. Upon receipt of this message, the RSIP host will know the client ID of its old registration, and SHOULD immediately transmit a DE- REGISTER_REQUEST using this client ID. After this is accomplished, the states of the RSIP host and gateway have been synchronized, and a new RSIP session may be established.
If the RSIP host does not de-register itself from the RSIP gateway, it will eventually receive a DE-REGISTER_RESPONSE from the gateway, when the gateway times out the host's session. Since the DE- REGISTER_RESPONSE will refer to a client ID that has no meaning to
If the RSIP host does not de-register itself from the RSIP gateway, it will eventually receive a DE-REGISTER_RESPONSE from the gateway, when the gateway times out the host's session. Since the DE- REGISTER_RESPONSE will refer to a client ID that has no meaning to
Borella, et al. Experimental [Page 37] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 37] RFC 3103 RSIP Protocol Specification October 2001
the host, the host SHOULD silently ignore such a message. At this point, the states of the RSIP host and gateway have been synchronized, and a new RSIP session may be established.
the host, the host SHOULD silently ignore such a message. At this point, the states of the RSIP host and gateway have been synchronized, and a new RSIP session may be established.
10.2.2. Gateway Failure
10.2.2. Gateway Failure
After a gateway failure, the gateway will reboot and be unaware of any RSIP state held by an RSIP host.
After a gateway failure, the gateway will reboot and be unaware of any RSIP state held by an RSIP host.
Since the gateway will not attempt to contact any of its RSIP hosts, a problem will first be detected when either an RSIP host sends an RSIP message to the gateway, an RSIP host sends tunneled data to the gateway, or data from a remote host intended for an RSIP host arrives.
Since the gateway will not attempt to contact any of its RSIP hosts, a problem will first be detected when either an RSIP host sends an RSIP message to the gateway, an RSIP host sends tunneled data to the gateway, or data from a remote host intended for an RSIP host arrives.
In the first case, the RSIP gateway SHOULD immediately response to all messages (except for a REGISTER_REQUEST) with an ERROR_RESPONSE with a REGISTER_FIRST error. Upon receipt of such a message, an RSIP host MUST interpret the message as an indication of a loss of synchronization between itself and the RSIP gateway. The RSIP host SHOULD immediately transmit a DE-REGISTRATION_REQUEST with its old client ID (which will generate another error, but this error SHOULD be ignored by the host). At this point, the states of the RSIP host and gateway have been synchronized, and a new RSIP session may be established.
In the first case, the RSIP gateway SHOULD immediately response to all messages (except for a REGISTER_REQUEST) with an ERROR_RESPONSE with a REGISTER_FIRST error. Upon receipt of such a message, an RSIP host MUST interpret the message as an indication of a loss of synchronization between itself and the RSIP gateway. The RSIP host SHOULD immediately transmit a DE-REGISTRATION_REQUEST with its old client ID (which will generate another error, but this error SHOULD be ignored by the host). At this point, the states of the RSIP host and gateway have been synchronized, and a new RSIP session may be established.
In the second case, all data that an RSIP host sends to the tunneled interface of an RSIP server will either (1) be discarded silently, (2) responded to with an ICMP Destination Unreachable message, such as "Communication Administratively Prohibited", or (3) blindly routed to the intended destination. In all of the above cases, the RSIP gateway will not have an explicit method to notify the RSIP host of the problem. To prevent a long term communications outage, small lease times of several minutes can be set by the RSIP gateway.
In the second case, all data that an RSIP host sends to the tunneled interface of an RSIP server will either (1) be discarded silently, (2) responded to with an ICMP Destination Unreachable message, such as "Communication Administratively Prohibited", or (3) blindly routed to the intended destination. In all of the above cases, the RSIP gateway will not have an explicit method to notify the RSIP host of the problem. To prevent a long term communications outage, small lease times of several minutes can be set by the RSIP gateway.
In the third case, the RSIP gateway SHOULD discard all incoming packets and/or respond with ICMP Port Unreachable messages.
In the third case, the RSIP gateway SHOULD discard all incoming packets and/or respond with ICMP Port Unreachable messages.
10.3. General Gateway Policy
10.3. General Gateway Policy
There is a significant amount of RSIP gateway policy that may be implemented, but is beyond the scope of this document. We expect that most of this policy will be site-specific or implementation- specific and therefore do not make any recommendations. Examples of general gateway policy include:
There is a significant amount of RSIP gateway policy that may be implemented, but is beyond the scope of this document. We expect that most of this policy will be site-specific or implementation- specific and therefore do not make any recommendations. Examples of general gateway policy include:
- How ports are allocated to RSIP hosts.
- Preferred length of lease times.
- How ports are allocated to RSIP hosts. - Preferred length of lease times.
Borella, et al. Experimental [Page 38] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 38] RFC 3103 RSIP Protocol Specification October 2001
- How flow policy is applied to which hosts.
- How an RSIP gateway with multiple public IP addresses that may
be leased by RSIP clients determines how to partition
and/or lease these addresses.
- How flow policy is applied to which hosts. - How an RSIP gateway with multiple public IP addresses that may be leased by RSIP clients determines how to partition and/or lease these addresses.
10.4. Errors Not From the RSIP Protocol
10.4. Errors Not From the RSIP Protocol
Once an RSIP host and gateway have established a relationship and the host is assigned resources to use, error may occur due to the host's misuse of the resources or its attempting to use unassigned resources. The following error behavior is defined:
Once an RSIP host and gateway have established a relationship and the host is assigned resources to use, error may occur due to the host's misuse of the resources or its attempting to use unassigned resources. The following error behavior is defined:
- If a host attempts to use a local address which it has not been
allocated, the RSIP gateway MUST drop the associated packet(s)
and send the host an ERROR_RESPONSE containing the
LOCAL_ADDR_UNALLOWED error.
- If a host attempts to use a local address which it has not been allocated, the RSIP gateway MUST drop the associated packet(s) and send the host an ERROR_RESPONSE containing the LOCAL_ADDR_UNALLOWED error.
- If a host attempts to use a local address / port tuple which it
has not been allocated, the RSIP gateway MUST drop the
associated packet(s) and send the host an ERROR_RESPONSE
containing the LOCAL_ADDRPORT_UNALLOWED error.
- If a host attempts to use a local address / port tuple which it has not been allocated, the RSIP gateway MUST drop the associated packet(s) and send the host an ERROR_RESPONSE containing the LOCAL_ADDRPORT_UNALLOWED error.
- If a host attempts to contact a remote address which has not
been properly specified or otherwise approved (e.g., via an
ASSIGN_RESPONSE_RSAP-IP and macro or micro based remote flow
policy), the RSIP gateway MUST drop the associated packet(s)
and send the host an ERROR_RESPONSE containing the
REMOTE_ADDR_UNALLOWED error.
- If a host attempts to contact a remote address which has not been properly specified or otherwise approved (e.g., via an ASSIGN_RESPONSE_RSAP-IP and macro or micro based remote flow policy), the RSIP gateway MUST drop the associated packet(s) and send the host an ERROR_RESPONSE containing the REMOTE_ADDR_UNALLOWED error.
- If a host attempts to contact a remote address / port tuple
which has not been properly specified or otherwise approved
(e.g., via an ASSIGN_RESPONSE_RSAP-IP and micro based remote
flow policy), the RSIP gateway MUST drop the associated
packet(s) and send the host an ERROR_RESPONSE containing the
REMOTE_ADDRPORT_UNALLOWED error.
- If a host attempts to contact a remote address / port tuple which has not been properly specified or otherwise approved (e.g., via an ASSIGN_RESPONSE_RSAP-IP and micro based remote flow policy), the RSIP gateway MUST drop the associated packet(s) and send the host an ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED error.
- If a host attempts to establish or use an improper tunnel type,
the RSIP gateway MUST respond with an ERROR_RESPONSE containing
the BAD_TUNNEL_TYPE error.
- If a host attempts to establish or use an improper tunnel type, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the BAD_TUNNEL_TYPE error.
- If the RSIP gateway's detects a local fault which prevents its
RSIP server module from continuing operation, the RSIP gateway
MUST respond with an ERROR_RESPONSE containing the
INTERNAL_SERVER_ERROR error.
- If the RSIP gateway's detects a local fault which prevents its RSIP server module from continuing operation, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the INTERNAL_SERVER_ERROR error.
Borella, et al. Experimental [Page 39] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 39] RFC 3103 RSIP Protocol Specification October 2001
10.5. Address and Port Requests and Allocation
10.5. Address and Port Requests and Allocation
Regardless of local flow policy, an RSIP host may "suggest" that it would like to use a particular local address and/or port number in a particular binding. An RSIP gateway that cannot grant such a request, because the specified resources are already in use, MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_INUSE or LOCAL_ADDRPORT_INUSE values.
Regardless of local flow policy, an RSIP host may "suggest" that it would like to use a particular local address and/or port number in a particular binding. An RSIP gateway that cannot grant such a request, because the specified resources are already in use, MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_INUSE or LOCAL_ADDRPORT_INUSE values.
10.6. Local Gateways and Flow Policy Interaction
10.6. Local Gateways and Flow Policy Interaction
An RSIP host may initialize a publically accessible gateway (such as an FTP or HTTP gateway) by transmitting a LISTEN_REQUEST message to an RSIP gateway and receiving a LISTEN_RESPONSE. However, unless no remote flow policy is used, the gateway will have to specify the address or address and port of a single remote host that will be allowed to contact it. Obviously, such as restriction is not very useful for hosts that require their gateways to be accessible by any remote host.
An RSIP host may initialize a publically accessible gateway (such as an FTP or HTTP gateway) by transmitting a LISTEN_REQUEST message to an RSIP gateway and receiving a LISTEN_RESPONSE. However, unless no remote flow policy is used, the gateway will have to specify the address or address and port of a single remote host that will be allowed to contact it. Obviously, such as restriction is not very useful for hosts that require their gateways to be accessible by any remote host.
This indicates that there is a conflict between flow-based policy and support for gateways. The main purpose of enforcing flow-based policy for LISTEN_REQUESTs is that it allows an RSIP gateway tight control over how an RSIP host uses ports and the associated accounting. For example, an RSIP host, operating under remote micro-flow based policy and using a protocol such as FTP, will have to specify the address and port that it will receive FTP data on, as well as the address and port that the gateway will transmit data from, in a LISTEN_REQUEST.
This indicates that there is a conflict between flow-based policy and support for gateways. The main purpose of enforcing flow-based policy for LISTEN_REQUESTs is that it allows an RSIP gateway tight control over how an RSIP host uses ports and the associated accounting. For example, an RSIP host, operating under remote micro-flow based policy and using a protocol such as FTP, will have to specify the address and port that it will receive FTP data on, as well as the address and port that the gateway will transmit data from, in a LISTEN_REQUEST.
In general, an RSIP gateway may not allow arbitrary hosts to start public gateways because of the traffic and security concerns. Thus, we recommend that if remote micro-flow based policy is used, that an RSIP gateway only allow public gateways on RSIP hosts via administrative override.
In general, an RSIP gateway may not allow arbitrary hosts to start public gateways because of the traffic and security concerns. Thus, we recommend that if remote micro-flow based policy is used, that an RSIP gateway only allow public gateways on RSIP hosts via administrative override.
Currently, RSIP hosts can only be identified by their local IP address or MAC address.
Currently, RSIP hosts can only be identified by their local IP address or MAC address.
11. Security Considerations
11. Security Considerations
RSIP, in and of itself, does not provide security. It may provide the illusion of security or privacy by hiding a private address space, but security can only be ensured by the proper use of security protocols and cryptographic techniques.
RSIP, in and of itself, does not provide security. It may provide the illusion of security or privacy by hiding a private address space, but security can only be ensured by the proper use of security protocols and cryptographic techniques.
Borella, et al. Experimental [Page 40] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 40] RFC 3103 RSIP Protocol Specification October 2001
An RSIP gateway should take all measures deemed necessary to prevent its hosts from performing intentional or unintentional denial-of- service attacks by request large sets of resources.
An RSIP gateway should take all measures deemed necessary to prevent its hosts from performing intentional or unintentional denial-of- service attacks by request large sets of resources.
Currently, RSIP hosts can only be identified by their local IP address or, in some cases, MAC address. It is desirable to allow RSIP messages sent between a host and gateway to be authenticated. Further discussion of such authentication can be found in [RSIP- FRAME].
Currently, RSIP hosts can only be identified by their local IP address or, in some cases, MAC address. It is desirable to allow RSIP messages sent between a host and gateway to be authenticated. Further discussion of such authentication can be found in [RSIP- FRAME].
Discussion of RSIP support for end-to-end IPsec can be found in [RSIP-IPSEC].
Discussion of RSIP support for end-to-end IPsec can be found in [RSIP-IPSEC].
12. IANA Considerations
12. IANA Considerations
All of the designations below have been registered by the IANA.
All of the designations below have been registered by the IANA.
- RSIP port number: 4555
- RSIP error codes (see Appendix A).
- RSIP message type codes (see Appendix B).
- RSIP tunnel types, methods, and flow policies.
- RSIP port number: 4555 - RSIP error codes (see Appendix A). - RSIP message type codes (see Appendix B). - RSIP tunnel types, methods, and flow policies.
RSIP parameter values are designated as follows:
RSIP parameter values are designated as follows:
- 0 Reserved
- 1-240 Assigned by IANA
- 241-255 Reserved for private use
- 0 Reserved - 1-240 Assigned by IANA - 241-255 Reserved for private use
New registrations for the above namespaces are recommended to be allocated via the Specification Required method documented in [RFC2434].
New registrations for the above namespaces are recommended to be allocated via the Specification Required method documented in [RFC2434].
13. Acknowledgements
13. Acknowledgements
The authors would like to specifically thank Gabriel Montenegro, Pyda Srisuresh, Brian Carpenter, Eliot Lear, Dan Nessett, Gary Jaszewski, Naveen Rajanikantha, Sudhakar Ramakrishna, Jim March, and Rick Cobb for their input. The IETF NAT working group as a whole has been extremely helpful in the ongoing development of RSIP.
The authors would like to specifically thank Gabriel Montenegro, Pyda Srisuresh, Brian Carpenter, Eliot Lear, Dan Nessett, Gary Jaszewski, Naveen Rajanikantha, Sudhakar Ramakrishna, Jim March, and Rick Cobb for their input. The IETF NAT working group as a whole has been extremely helpful in the ongoing development of RSIP.
Borella, et al. Experimental [Page 41] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 41] RFC 3103 RSIP Protocol Specification October 2001
14. Appendix A: RSIP Error Numbers
14. Appendix A: RSIP Error Numbers
This section provides descriptions for the error values in the RSIP error parameter.
This section provides descriptions for the error values in the RSIP error parameter.
All errors are grouped into the following categories:
All errors are grouped into the following categories:
100's: General errors.
100's: General errors.
101: UNKNOWN_ERROR. An error that cannot be identified has
occurred. This error should be used when all other error
messages are inappropriate.
101: UNKNOWN_ERROR. An error that cannot be identified has occurred. This error should be used when all other error messages are inappropriate.
102: USE_TCP. A host has attempted to use UDP on a server that
only supports TCP.
102: USE_TCP. A host has attempted to use UDP on a server that only supports TCP.
103: FLOW_POLICY_VIOLATION: A host has not specified address or
port information in enough detail for its assigned flow policy.
103: FLOW_POLICY_VIOLATION: A host has not specified address or port information in enough detail for its assigned flow policy.
104: INTERNAL_SERVER_ERROR: An RSIP server application has
detected an unrecoverable error within itself or the RSIP
gateway.
104: INTERNAL_SERVER_ERROR: An RSIP server application has detected an unrecoverable error within itself or the RSIP gateway.
105: MESSAGE_COUNTER_REQUIRED: An RSIP host did not use a message
counter parameter in a situation in which it should have.
105: MESSAGE_COUNTER_REQUIRED: An RSIP host did not use a message counter parameter in a situation in which it should have.
106: UNSUPPORTED_RSIP_VERSION: An RSIP host sent a message with a
version number that is not supported by the RSIP gateway.
106: UNSUPPORTED_RSIP_VERSION: An RSIP host sent a message with a version number that is not supported by the RSIP gateway.
200's: Parameter and message errors. The gateway uses these errors
when it detects that a parameter or message is malformed, as well
as when it does not understand a parameter or message.
200's: Parameter and message errors. The gateway uses these errors when it detects that a parameter or message is malformed, as well as when it does not understand a parameter or message.
201: MISSING_PARAM. The request does not contain a required
parameter.
201: MISSING_PARAM. The request does not contain a required parameter.
202: DUPLICATE_PARAM. The request contains an illegal duplicate
parameter.
202: DUPLICATE_PARAM. The request contains an illegal duplicate parameter.
203: EXTRA_PARAM. The request contains a parameter that it should
not.
203: EXTRA_PARAM. The request contains a parameter that it should not.
204: ILLEGAL_PARAM. The gateway does not understand a parameter
type.
204: ILLEGAL_PARAM. The gateway does not understand a parameter type.
205: BAD_PARAM. A parameter is malformed.
205: BAD_PARAM. A parameter is malformed.
Borella, et al. Experimental [Page 42] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 42] RFC 3103 RSIP Protocol Specification October 2001
206: ILLEGAL_MESSAGE. The gateway does not understand the message
type. The message type is neither mandatory nor optional.
206: ILLEGAL_MESSAGE. The gateway does not understand the message type. The message type is neither mandatory nor optional.
207: BAD_MESSAGE. A message is malformed and gateway parsing
failed.
207: BAD_MESSAGE. A message is malformed and gateway parsing failed.
208: UNSUPPORTED_MESSAGE: The host has transmitted an optional
message that the gateway does not support.
208: UNSUPPORTED_MESSAGE: The host has transmitted an optional message that the gateway does not support.
300's: Permission, resource, and policy errors. The gateway uses
these errors when a host has attempted to do something that it is
not permitted to do, or something that violated gateway policy.
300's: Permission, resource, and policy errors. The gateway uses these errors when a host has attempted to do something that it is not permitted to do, or something that violated gateway policy.
301: REGISTER_FIRST. The RSIP host has attempted to request or
use resources without registering.
301: REGISTER_FIRST. The RSIP host has attempted to request or use resources without registering.
302: ALREADY_REGISTERED. The host has attempted to register again
without first de-registering.
302: ALREADY_REGISTERED. The host has attempted to register again without first de-registering.
303: ALREADY_UNREGISTERED. The host has attempted to de-register
but it is already in the unregistered state.
303: ALREADY_UNREGISTERED. The host has attempted to de-register but it is already in the unregistered state.
304: REGISTRATION_DENIED. The gateway will not allow the host to
register.
304: REGISTRATION_DENIED. The gateway will not allow the host to register.
305: BAD_CLIENT_ID. The host has referred to itself with the
wrong client ID.
305: BAD_CLIENT_ID. The host has referred to itself with the wrong client ID.
306: BAD_BIND_ID. The request refers to a bind ID that is not
valid for the host.
306: BAD_BIND_ID. The request refers to a bind ID that is not valid for the host.
307: BAD_TUNNEL_TYPE. The request refers to a tunnel type that is
not valid for the host.
307: BAD_TUNNEL_TYPE. The request refers to a tunnel type that is not valid for the host.
308: LOCAL_ADDR_UNAVAILABLE. The gateway is currently not able to
allocate ANY local address, but the host may try again later.
308: LOCAL_ADDR_UNAVAILABLE. The gateway is currently not able to allocate ANY local address, but the host may try again later.
309: LOCAL_ADDRPORT_UNAVAILABLE. The gateway is currently not
able to allocate ANY local IP address / port tuple of the
requested magnitude (i.e., number of ports), but the host may
try again later.
309: LOCAL_ADDRPORT_UNAVAILABLE. The gateway is currently not able to allocate ANY local IP address / port tuple of the requested magnitude (i.e., number of ports), but the host may try again later.
310: LOCAL_ADDR_INUSE. The gateway was not able to allocate the
requested local address because it is currently used by another
entity.
310: LOCAL_ADDR_INUSE. The gateway was not able to allocate the requested local address because it is currently used by another entity.
Borella, et al. Experimental [Page 43] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 43] RFC 3103 RSIP Protocol Specification October 2001
311: LOCAL_ADDRPORT_INUSE. The gateway was not able to allocate
the requested local address / port tuple because it is
currently used by another entity.
311: LOCAL_ADDRPORT_INUSE. The gateway was not able to allocate the requested local address / port tuple because it is currently used by another entity.
312: LOCAL_ADDR_UNALLOWED. The gateway will not let the host use
the specified local IP address due to policy.
312: LOCAL_ADDR_UNALLOWED. The gateway will not let the host use the specified local IP address due to policy.
313: LOCAL_ADDRPORT_UNALLOWED. The gateway will not let the host
use the specified local address / port pair due to policy.
313: LOCAL_ADDRPORT_UNALLOWED. The gateway will not let the host use the specified local address / port pair due to policy.
314: REMOTE_ADDR_UNALLOWED. The gateway will not allow the host
to establish a session to the specified remote address.
314: REMOTE_ADDR_UNALLOWED. The gateway will not allow the host to establish a session to the specified remote address.
315: REMOTE_ADDRPORT_UNALLOWED. The gateway will not allow the
host to establish a session to the specified remote address /
port tuple.
315: REMOTE_ADDRPORT_UNALLOWED. The gateway will not allow the host to establish a session to the specified remote address / port tuple.
400's: IPsec errors. All errors specific to RSIP / IPsec operation.
See [RSIP-IPSEC].
400's: IPsec errors. All errors specific to RSIP / IPsec operation. See [RSIP-IPSEC].
15. Appendix B: Message Types
15. Appendix B: Message Types
This section defines the values assigned to RSIP message types. We also indicate which RSIP entity, host or gateway, produces each messages, and whether it is mandatory or optional. All *_REQUEST messages are only to be implemented on hosts, while all *_RESPONSE messages are only to be implemented on gateways. RSIP implementations (both host and gateway) MUST support all mandatory messages in order to be considered "RSIP compliant".
This section defines the values assigned to RSIP message types. We also indicate which RSIP entity, host or gateway, produces each messages, and whether it is mandatory or optional. All *_REQUEST messages are only to be implemented on hosts, while all *_RESPONSE messages are only to be implemented on gateways. RSIP implementations (both host and gateway) MUST support all mandatory messages in order to be considered "RSIP compliant".
Borella, et al. Experimental [Page 44] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 44] RFC 3103 RSIP Protocol Specification October 2001
Value Message Implementation Status
------------------------------------------------------------
1 ERROR_RESPONSE gateway mandatory
2 REGISTER_REQUEST host mandatory
3 REGISTER_RESPONSE gateway mandatory
4 DE-REGISTER_REQUEST host mandatory
5 DE-REGISTER_RESPONSE gateway mandatory
6 ASSIGN_REQUEST_RSA-IP host optional
7 ASSIGN_RESPONSE_RSA-IP gateway optional
8 ASSIGN_REQUEST_RSAP-IP host mandatory
9 ASSIGN_RESPONSE_RSAP-IP gateway mandatory
10 EXTEND_REQUEST host mandatory
11 EXTEND_RESPONSE gateway mandatory
12 FREE_REQUEST host mandatory
13 FREE_RESPONSE gateway mandatory
14 QUERY_REQUEST host optional
15 QUERY_RESPONSE gateway mandatory
16 LISTEN_REQUEST host optional
17 LISTEN_RESPONSE gateway optional
Value Message Implementation Status ------------------------------------------------------------ 1 ERROR_RESPONSE gateway mandatory 2 REGISTER_REQUEST host mandatory 3 REGISTER_RESPONSE gateway mandatory 4 DE-REGISTER_REQUEST host mandatory 5 DE-REGISTER_RESPONSE gateway mandatory 6 ASSIGN_REQUEST_RSA-IP host optional 7 ASSIGN_RESPONSE_RSA-IP gateway optional 8 ASSIGN_REQUEST_RSAP-IP host mandatory 9 ASSIGN_RESPONSE_RSAP-IP gateway mandatory 10 EXTEND_REQUEST host mandatory 11 EXTEND_RESPONSE gateway mandatory 12 FREE_REQUEST host mandatory 13 FREE_RESPONSE gateway mandatory 14 QUERY_REQUEST host optional 15 QUERY_RESPONSE gateway mandatory 16 LISTEN_REQUEST host optional 17 LISTEN_RESPONSE gateway optional
16. Appendix C: Example RSIP host/gateway transactions
16. Appendix C: Example RSIP host/gateway transactions
In this appendix, we present an exemplary series of annotated transactions between an RSIP host and an RSIP gateway. All host to gateway traffic is denote by `C --> S' and all gateway to host traffic is denoted by `S --> C'. Parameter values are denoted inside of parentheses. Versions, message types, and overall lengths are not included in order to save space. "Don't care" values are indicated by 0's.
In this appendix, we present an exemplary series of annotated transactions between an RSIP host and an RSIP gateway. All host to gateway traffic is denote by `C --> S' and all gateway to host traffic is denoted by `S --> C'. Parameter values are denoted inside of parentheses. Versions, message types, and overall lengths are not included in order to save space. "Don't care" values are indicated by 0's.
A ports parameter is represented by the number of ports followed by the port numbers, separated by dashes. For example, 2-1012-1013 indicates two ports, namely 1012 and 1013, while 16-10000 indicates 16 ports, namely 10000-10015, and 4-0 indicates four ports, but the sender doesn't care where they are.
A ports parameter is represented by the number of ports followed by the port numbers, separated by dashes. For example, 2-1012-1013 indicates two ports, namely 1012 and 1013, while 16-10000 indicates 16 ports, namely 10000-10015, and 4-0 indicates four ports, but the sender doesn't care where they are.
IPv4 addresses are assumed.
IPv4 addresses are assumed.
16.1. RSAP-IP with Local Macro-flow Based Policy and No Remote Flow
Policy
16.1. RSAP-IP with Local Macro-flow Based Policy and No Remote Flow Policy
This example exhibits the loosest policy framework for RSAP-IP.
This example exhibits the loosest policy framework for RSAP-IP.
C --> S: REGISTER_REQUEST ()
C --> S: REGISTER_REQUEST ()
The host attempts to register with the gateway.
The host attempts to register with the gateway.
Borella, et al. Experimental [Page 45] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 45] RFC 3103 RSIP Protocol Specification October 2001
S --> C: REGISTER_RESPONSE (Client ID = 1, Local Flow Policy =
Macro, Remote Flow policy = None, Lease Time = 600)
S --> C: REGISTER_RESPONSE (Client ID = 1, Local Flow Policy = Macro, Remote Flow policy = None, Lease Time = 600)
The gateway responds, assigning a Client ID of 1, local macro-
flow based policy and no remote flow policy. No RSIP method is
indicated, so RSAP-IP is assumed. No tunnel type is indicated,
so IP-IP is assumed. A lease time of 600 seconds is assigned.
The gateway responds, assigning a Client ID of 1, local macro- flow based policy and no remote flow policy. No RSIP method is indicated, so RSAP-IP is assumed. No tunnel type is indicated, so IP-IP is assumed. A lease time of 600 seconds is assigned.
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) =
0, Ports (local) = 4-0, Address (remote) = 0, Ports (remote) =
0, Lease Time = 3600)
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) = 0, Ports (local) = 4-0, Address (remote) = 0, Ports (remote) = 0, Lease Time = 3600)
The host requests an address and four ports to use with it, but
doesn't care which address or ports are assigned. The host
does not specify the remote address or ports either. The host
suggests a lease time of 3600 seconds.
The host requests an address and four ports to use with it, but doesn't care which address or ports are assigned. The host does not specify the remote address or ports either. The host suggests a lease time of 3600 seconds.
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 1,
Address (local) = 149.112.240.156, Ports (local) = 4-1234,
Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800,
Tunnel Type = IP-IP)
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 1, Address (local) = 149.112.240.156, Ports (local) = 4-1234, Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800, Tunnel Type = IP-IP)
The gateway responds by indicating that a bind ID of 1 has been
assigned to IP address 149.112.240.156 with ports 1234-1237.
Any remote host may be communicated with, using any remote port
number. The lease time has been assigned to be 1800 seconds,
and the tunnel type is confirmed to be IP-IP.
The gateway responds by indicating that a bind ID of 1 has been assigned to IP address 149.112.240.156 with ports 1234-1237. Any remote host may be communicated with, using any remote port number. The lease time has been assigned to be 1800 seconds, and the tunnel type is confirmed to be IP-IP.
The host is now able to communicate with any host on the public
network using these resources.
The host is now able to communicate with any host on the public network using these resources.
C --> S: QUERY_REQUEST: (Client ID = 1, Indicator = network,
Address (network) = 10.20.60.0, Address (netmask)
255.255.255.0)
C --> S: QUERY_REQUEST: (Client ID = 1, Indicator = network, Address (network) = 10.20.60.0, Address (netmask) 255.255.255.0)
The host asks the gateway if the network 10.20.60.0/24 is
local.
The host asks the gateway if the network 10.20.60.0/24 is local.
S --> C: QUERY_RESPONSE: (Client ID = 1, Indicator = network,
Address (network) = 10.20.60.0, Address (netmask) =
255.255.255.0)
S --> C: QUERY_RESPONSE: (Client ID = 1, Indicator = network, Address (network) = 10.20.60.0, Address (netmask) = 255.255.255.0)
The gateway responds indicating that the network in question is
local.
The gateway responds indicating that the network in question is local.
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) =
149.112.240.156, Ports (local) = 8-1238, Address (remote) = 0,
Ports (remote) = 0, Lease Time = 1800)
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) = 149.112.240.156, Ports (local) = 8-1238, Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800)
Borella, et al. Experimental [Page 46] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 46] RFC 3103 RSIP Protocol Specification October 2001
The host requests eight more particular ports for use with
RSAP-IP with the same address. A lease of 1800 seconds is
requested. IP-IP tunneling is implied by default.
The host requests eight more particular ports for use with RSAP-IP with the same address. A lease of 1800 seconds is requested. IP-IP tunneling is implied by default.
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 2,
Address (local) = 149.112.240.156, Ports (local) = 8-1305,
Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800)
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 2, Address (local) = 149.112.240.156, Ports (local) = 8-1305, Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800)
The gateway grants the request with the same address, but with
a different set of ports. IP-IP tunneling is implied by
default.
The gateway grants the request with the same address, but with a different set of ports. IP-IP tunneling is implied by default.
C --> S: FREE_REQUEST (Client ID = 1, Bind ID = 1)
C --> S: FREE_REQUEST (Client ID = 1, Bind ID = 1)
The host frees bind ID 1; i.e., ports 1234-1237 from IP address
149.112.240.156. Note that the address itself is still
assigned to the host because the host is still assigned ports
1305-1314.
The host frees bind ID 1; i.e., ports 1234-1237 from IP address 149.112.240.156. Note that the address itself is still assigned to the host because the host is still assigned ports 1305-1314.
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 1)
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 1)
The gateway acknowledges that Bind ID 1 has been freed.
The gateway acknowledges that Bind ID 1 has been freed.
C --> S: EXTEND_REQUEST (Client ID = 1, Bind ID = 2, Lease Time =
1800)
C --> S: EXTEND_REQUEST (Client ID = 1, Bind ID = 2, Lease Time = 1800)
The host request that the lease on bind ID 1 be extended for
1800 seconds.
The host request that the lease on bind ID 1 be extended for 1800 seconds.
S --> C: EXTEND_RESPONSE (Client ID = 1, Bind ID = 2, Lease Time =
1800)
S --> C: EXTEND_RESPONSE (Client ID = 1, Bind ID = 2, Lease Time = 1800)
The gateway confirms the request.
The gateway confirms the request.
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 2)
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 2)
The gateway forces the host to free the resources of bind ID 2.
The gateway forces the host to free the resources of bind ID 2.
C --> S: DE-REGISTER_REQUEST (Client ID = 1)
C --> S: DE-REGISTER_REQUEST (Client ID = 1)
The host de-registers with the sever.
The host de-registers with the sever.
S --> C: DE-REGISTER_RESPONSE (Client ID = 1)
S --> C: DE-REGISTER_RESPONSE (Client ID = 1)
The gateway acknowledges that the host has de-registered.
The gateway acknowledges that the host has de-registered.
Borella, et al. Experimental [Page 47] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 47] RFC 3103 RSIP Protocol Specification October 2001
16.2. RSAP-IP with Local Micro-flow Based Policy and Remote Micro-
flow Based Policy
16.2. RSAP-IP with Local Micro-flow Based Policy and Remote Micro- flow Based Policy
This example exhibits the strictest policy framework for RSAP-IP.
This example exhibits the strictest policy framework for RSAP-IP.
C --> S: REGISTER_REQUEST ()
C --> S: REGISTER_REQUEST ()
The host attempts to register with the gateway.
The host attempts to register with the gateway.
S --> C: REGISTER_RESPONSE (Client ID = 5, Local Flow Policy =
Micro, Remote Flow policy = Micro, RSIP Method = RSAP-IP, RSIP
Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = GRE, Lease
Time = 600)
S --> C: REGISTER_RESPONSE (Client ID = 5, Local Flow Policy = Micro, Remote Flow policy = Micro, RSIP Method = RSAP-IP, RSIP Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = GRE, Lease Time = 600)
The gateway responds, assigning a Client ID of 5, local micro-
flow based policy and remote micro-flow based policy. Both
RSAP-IP and RSA-IP are supported. Both IP-IP and GRE tunnel
types are supported. A lease time of 600 seconds is assigned.
The gateway responds, assigning a Client ID of 5, local micro- flow based policy and remote micro-flow based policy. Both RSAP-IP and RSA-IP are supported. Both IP-IP and GRE tunnel types are supported. A lease time of 600 seconds is assigned.
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 5, Address (local) =
0, Ports (local) = 0, Address (remote) = 38.196.73.6, Ports
(remote) = 21, Lease Time = 600, Tunnel Type = IP-IP)
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 5, Address (local) = 0, Ports (local) = 0, Address (remote) = 38.196.73.6, Ports (remote) = 21, Lease Time = 600, Tunnel Type = IP-IP)
The host requests a local address and a port assignment to use
with it. The host indicates that it wants to contact host
38.196.73.6 at port 21 (FTP control). The host requests a
lease time of 600 seconds and a tunnel type of IP-IP.
The host requests a local address and a port assignment to use with it. The host indicates that it wants to contact host 38.196.73.6 at port 21 (FTP control). The host requests a lease time of 600 seconds and a tunnel type of IP-IP.
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 5, Bind ID = 1,
Address (local) = 149.112.240.156, Ports (local) = 2049,
Address (remote) = 38.196.73.6, Ports (remote) = 21, Lease Time
= 600, Tunnel Type = IP-IP)
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 5, Bind ID = 1, Address (local) = 149.112.240.156, Ports (local) = 2049, Address (remote) = 38.196.73.6, Ports (remote) = 21, Lease Time = 600, Tunnel Type = IP-IP)
The gateway responds by indicating that a bind ID of 1 has been
assigned to IP address 149.112.240.156 with port 2049. Only
host 38.196.73.6 at port 21 may be contacted. The lease time
has been assigned to be 600 seconds, and the tunnel type is
confirmed to be IP-IP.
The gateway responds by indicating that a bind ID of 1 has been assigned to IP address 149.112.240.156 with port 2049. Only host 38.196.73.6 at port 21 may be contacted. The lease time has been assigned to be 600 seconds, and the tunnel type is confirmed to be IP-IP.
C --> S: LISTEN_REQUEST: (Client ID = 5, Address (local) =
149.112.240.156, Ports (local) = 2050, Address (remote) =
38.196.73.6, Ports (remote) = 20)
C --> S: LISTEN_REQUEST: (Client ID = 5, Address (local) = 149.112.240.156, Ports (local) = 2050, Address (remote) = 38.196.73.6, Ports (remote) = 20)
The host requests a listen port 2050 at the same address that
it has been assigned. Only host 38.196.73.6 from ports 20 (FTP
data) will be able to contact it.
The host requests a listen port 2050 at the same address that it has been assigned. Only host 38.196.73.6 from ports 20 (FTP data) will be able to contact it.
Borella, et al. Experimental [Page 48] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 48] RFC 3103 RSIP Protocol Specification October 2001
S --> C: LISTEN_RESPONSE: (Client ID = 5, Address (local) =
149.112.240.156, Ports (local) = 2050, Address (remote) =
38.196.73.6, Ports (remote) = 20, Lease Time = 600, Tunnel Type
= IP-IP)
S --> C: LISTEN_RESPONSE: (Client ID = 5, Address (local) = 149.112.240.156, Ports (local) = 2050, Address (remote) = 38.196.73.6, Ports (remote) = 20, Lease Time = 600, Tunnel Type = IP-IP)
The gateway confirms the request and assigns a lease time of
600 seconds and a tunnel type of IP-IP.
The gateway confirms the request and assigns a lease time of 600 seconds and a tunnel type of IP-IP.
C --> S: DE-REGISTER_REQUEST (Client ID = 5)
C --> S: DE-REGISTER_REQUEST (Client ID = 5)
The host de-registers with the sever.
The host de-registers with the sever.
S --> C: DE-REGISTER_RESPONSE (Client ID = 5)
S --> C: DE-REGISTER_RESPONSE (Client ID = 5)
The gateway acknowledges that the host has de-registered. All
of the host's bindings have been implicitly revoked.
The gateway acknowledges that the host has de-registered. All of the host's bindings have been implicitly revoked.
16.3. RSA-IP with Local Macro-flow Based Policy and Remote Macro-
flow based Policy
16.3. RSA-IP with Local Macro-flow Based Policy and Remote Macro- flow based Policy
This example exhibits a medium level of control for RSA-IP.
This example exhibits a medium level of control for RSA-IP.
C --> S: REGISTER_REQUEST ()
C --> S: REGISTER_REQUEST ()
The host attempts to register with the gateway.
The host attempts to register with the gateway.
S --> C: REGISTER_RESPONSE (Client ID = 3, Local Flow Policy =
Macro, Remote Flow policy = Macro, RSIP Method = RSAP-IP, RSIP
Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = L2TP, Lease
Time = 600)
S --> C: REGISTER_RESPONSE (Client ID = 3, Local Flow Policy = Macro, Remote Flow policy = Macro, RSIP Method = RSAP-IP, RSIP Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = L2TP, Lease Time = 600)
The gateway responds, assigning a Client ID of 3, local macro-
flow based policy and remote macro-flow based policy. Both
RSAP-IP and RSA-IP are supported. Both IP-IP and L2TP tunnel
types are supported. A lease time of 600 seconds is assigned.
The gateway responds, assigning a Client ID of 3, local macro- flow based policy and remote macro-flow based policy. Both RSAP-IP and RSA-IP are supported. Both IP-IP and L2TP tunnel types are supported. A lease time of 600 seconds is assigned.
C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) =
0, Address (remote) = www.foo.com, Ports (remote) = 0, Lease
Time = 3600, Tunnel Type = IP-IP)
C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) = 0, Address (remote) = www.foo.com, Ports (remote) = 0, Lease Time = 3600, Tunnel Type = IP-IP)
The host requests a local address and indicates that it wants
to contact host www.foo.com.
The host requests a local address and indicates that it wants to contact host www.foo.com.
S --> C: ERROR_RESPONSE: (Error = REMOTE_ADDR_UNALLOWED, Client ID
= 3)
S --> C: ERROR_RESPONSE: (Error = REMOTE_ADDR_UNALLOWED, Client ID = 3)
The gateway indicates that the host is not permitted to
establish communication with www.foo.com.
The gateway indicates that the host is not permitted to establish communication with www.foo.com.
Borella, et al. Experimental [Page 49] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 49] RFC 3103 RSIP Protocol Specification October 2001
C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) =
0, Address (remote) = www.bar.com, Ports (remote) = 0, Lease
Time = 3600, Tunnel Type = IP-IP)
C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) = 0, Address (remote) = www.bar.com, Ports (remote) = 0, Lease Time = 3600, Tunnel Type = IP-IP)
The host requests a local address and indicates that it wants
to contact host www.bar.com.
The host requests a local address and indicates that it wants to contact host www.bar.com.
S --> C: ASSIGN_RESPONSE_RSA-IP: (Client ID = 3, Bind ID = 1,
Address (local) = 149.112.240.17, Address (remote) =
www.bar.com, Ports (remote) = 0, Lease Time = 3600, Tunnel Type
= IP-IP)
S --> C: ASSIGN_RESPONSE_RSA-IP: (Client ID = 3, Bind ID = 1, Address (local) = 149.112.240.17, Address (remote) = www.bar.com, Ports (remote) = 0, Lease Time = 3600, Tunnel Type = IP-IP)
The gateway responds by granting local IP address
149.112.240.17 to the host, and permitting it to communicate
with www.bar.com, at any port. Requested lease time and tunnel
type are also granted.
The gateway responds by granting local IP address 149.112.240.17 to the host, and permitting it to communicate with www.bar.com, at any port. Requested lease time and tunnel type are also granted.
C --> S: DE-REGISTER_REQUEST (Client ID = 3)
C --> S: DE-REGISTER_REQUEST (Client ID = 3)
The host de-registers with the sever.
The host de-registers with the sever.
S --> C: DE-REGISTER_RESPONSE (Client ID = 3)
S --> C: DE-REGISTER_RESPONSE (Client ID = 3)
The gateway acknowledges that the host has de-registered. All
of the host's bindings have been implicitly revoked.
The gateway acknowledges that the host has de-registered. All of the host's bindings have been implicitly revoked.
17. Appendix D: Example RSIP host state diagram
17. Appendix D: Example RSIP host state diagram
This appendix provides an exemplary diagram of RSIP host state. The host begins in the unregistered state. We assume that for UDP, if a message is lost, the host will timeout and retransmit another copy of it. We recommend a 7-fold binary exponential backoff timer for retransmissions, with the first timeout occurring after 12.5 ms. This diagram does not include transitions for the LISTEN_REQUEST message.
This appendix provides an exemplary diagram of RSIP host state. The host begins in the unregistered state. We assume that for UDP, if a message is lost, the host will timeout and retransmit another copy of it. We recommend a 7-fold binary exponential backoff timer for retransmissions, with the first timeout occurring after 12.5 ms. This diagram does not include transitions for the LISTEN_REQUEST message.
Borella, et al. Experimental [Page 50] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 50] RFC 3103 RSIP Protocol Specification October 2001
send
REGISTER_REQUEST
+------------+ +------------+
| |------------->|Registration|<-- timeout/send
+--->|Unregistered|<-------------| Pending |--- REGISTER_REQUEST
| | | +------------+
| +------------+ 7th timeout/recv |
| ^ ERROR_RESPONSE |
| | |
| | |
| |7th timeout/recv |recv timeout/send
| |DE-REGISTER_RESPONSE |REGISTER_RESPONSE QUERY_REQUEST
| | | ^ |
| | | | |
| | | send | |
| | send DE- v QUERY_REQUEST | |
| +----------------+ REGISTER_REQUEST+----------+ +----------+
| | Registered |<----------------| |--------->|Registered|
| | De-registration| |Registered| | Query |
| | Pending |---------------->| |<---------| Pending |
| +----------------+ recv +----------+ +----------+
| | ^ ERROR_RESPONSE ^ | 7th timeout/recv
| | | | | QUERY_RESPONSE or
| timeout/send | | ERROR_RESPONSE
| DE-REGISTER_REQUEST 7th timeout/recv| |
| ERROR_RESPONSE | |
| | |
| +----------------+ | |
| |Go to Registered| | |send
| +----------------+ | |ASSIGN_REQUEST
| ^ timeout/send | |
| |Yes FREE_REQUEST | |
| + | | | |
| + + v | | v
| + + 7th timeout/ +--------+ +----------+
| + Are all + recv | Free | |Assignment|<--timeout/send
| + resources +<-----------|Pending | | Pending |---ASSIGN_REQUEST
| + freed? + FREE_RESPONSE+--------+ +----------+
| + + ^ | |
| + + | | |
| + | | |recv
| |No send | |recv |ASSIGN_RESPONSE
| v ERROR_REQUEST| |ERROR_ |
| +---------------+ | |RESPONSE |
| | Go to Assigned| | | | 7th timeout/recv
| +---------------+ | | | QUERY_RESPONSE or
| recv | | | ERROR_RESPONSE
| +---------------+ERROR_RESPONSE | v v +-----------+
send REGISTER_REQUEST +------------+ +------------+ | |------------->|Registration|<-- timeout/send +--->|Unregistered|<-------------| Pending |--- REGISTER_REQUEST | | | +------------+ | +------------+ 7th timeout/recv | | ^ ERROR_RESPONSE | | | | | | | | |7th timeout/recv |recv timeout/send | |DE-REGISTER_RESPONSE |REGISTER_RESPONSE QUERY_REQUEST | | | ^ | | | | | | | | | send | | | | send DE- v QUERY_REQUEST | | | +----------------+ REGISTER_REQUEST+----------+ +----------+ | | Registered |<----------------| |--------->|Registered| | | De-registration| |Registered| | Query | | | Pending |---------------->| |<---------| Pending | | +----------------+ recv +----------+ +----------+ | | ^ ERROR_RESPONSE ^ | 7th timeout/recv | | | | | QUERY_RESPONSE or | timeout/send | | ERROR_RESPONSE | DE-REGISTER_REQUEST 7th timeout/recv| | | ERROR_RESPONSE | | | | | | +----------------+ | | | |Go to Registered| | |send | +----------------+ | |ASSIGN_REQUEST | ^ timeout/send | | | |Yes FREE_REQUEST | | | + | | | | | + + v | | v | + + 7th timeout/ +--------+ +----------+ | + Are all + recv | Free | |Assignment|<--timeout/send | + resources +<-----------|Pending | | Pending |---ASSIGN_REQUEST | + freed? + FREE_RESPONSE+--------+ +----------+ | + + ^ | | | + + | | | | + | | |recv | |No send | |recv |ASSIGN_RESPONSE | v ERROR_REQUEST| |ERROR_ | | +---------------+ | |RESPONSE | | | Go to Assigned| | | | 7th timeout/recv | +---------------+ | | | QUERY_RESPONSE or | recv | | | ERROR_RESPONSE | +---------------+ERROR_RESPONSE | v v +-----------+
Borella, et al. Experimental [Page 51] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 51] RFC 3103 RSIP Protocol Specification October 2001
| | Assigned |-------------->+-------------+-------->| Assigned |
+>|De-registration| | Assigned | | Query |
| Pending |<--------------+-------------+<--------| Pending |
+---------------+ send ^ | +-----------+
^ | DE-REGISTER_REQUEST | | send ^ |
| | | | QUERY_REQUEST | |
| | | | | |
timeout/send 7th/timeout/recv | |send | |
DE-REGISTER_ ASSIGN_RESPONSE | |ASSIGN_REQUEST timeout/send
REQUEST or ERROR_RESPONSE| | QUERY_REQUEST
| |
| v
+----------+
| Assigned |
|Assignment|
| Pending |
+----------+
^ |
| |
timeout/send
ASSIGN_REQUEST
| | Assigned |-------------->+-------------+-------->| Assigned | +>|De-registration| | Assigned | | Query | | Pending |<--------------+-------------+<--------| Pending | +---------------+ send ^ | +-----------+ ^ | DE-REGISTER_REQUEST | | send ^ | | | | | QUERY_REQUEST | | | | | | | | timeout/send 7th/timeout/recv | |send | | DE-REGISTER_ ASSIGN_RESPONSE | |ASSIGN_REQUEST timeout/send REQUEST or ERROR_RESPONSE| | QUERY_REQUEST | | | v +----------+ | Assigned | |Assignment| | Pending | +----------+ ^ | | | timeout/send ASSIGN_REQUEST
18. References
18. References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G.J. and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RSIP-FRAME] Borella, M. Lo, J., Grabelsky, D. and G. Montenegro,
"Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIP-FRAME] Borella, M. Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIP-IPSEC] Montenegro, G. and M. Borella, "RSIP Support for End-
to-end IPSEC", RFC 3104, October 2001.
[RSIP-IPSEC] Montenegro, G. and M. Borella, "RSIP Support for End- to-end IPSEC", RFC 3104, October 2001.
Borella, et al. Experimental [Page 52] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 52] RFC 3103 RSIP Protocol Specification October 2001
19. Authors' Addresses
19. Authors' Addresses
Michael Borella CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
Michael Borella CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
Phone: (847) 262-3083 EMail: mike_borella@commworks.com
Phone: (847) 262-3083 EMail: mike_borella@commworks.com
David Grabelsky CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
David Grabelsky CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
Phone: (847) 222-2483 EMail: david_grabelsky@commworks.com
Phone: (847) 222-2483 EMail: david_grabelsky@commworks.com
Jeffrey Lo Candlestick Networks, Inc 70 Las Colinas Lane, San Jose, CA 95119
Jeffrey Lo Candlestick Networks, Inc 70 Las Colinas Lane, San Jose, CA 95119
Phone: (408) 284 4132 EMail: yidarlo@yahoo.com
Phone: (408) 284 4132 EMail: yidarlo@yahoo.com
Kunihiro Taniguchi NEC USA C&C Research Labs. 110 Rio Robles San Jose, CA 95134
Kunihiro Taniguchi NEC USA C&C Research Labs. 110 Rio Robles San Jose, CA 95134
Phone: (408) 943-3031 EMail: taniguti@ccrl.sj.nec.com
Phone: (408) 943-3031 EMail: taniguti@ccrl.sj.nec.com
Borella, et al. Experimental [Page 53] RFC 3103 RSIP Protocol Specification October 2001
Borella, et al. Experimental [Page 53] RFC 3103 RSIP Protocol Specification October 2001
20. Full Copyright Statement
20. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Borella, et al. Experimental [Page 54]
Borella, et al. Experimental [Page 54]
一覧
スポンサーリンク
