RFC5390 日本語訳
5390 Requirements for Management of Overload in the Session InitiationProtocol. J. Rosenberg. December 2008. (Format: TXT=32851 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg Request for Comments: 5390 Cisco Category: Informational December 2008
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 5390年のコクチマスカテゴリ: 情報の2008年12月
Requirements for Management of Overload in the
Session Initiation Protocol
セッション開始プロトコルにおけるオーバーロードの管理のための要件
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/ ライセンスインフォメーション)へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
Abstract
要約
Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This document summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution.
プロキシとユーザエージェントに要求の処理を終了する不十分なリソースがあるとき、オーバーロードはSession Initiationプロトコル(SIP)ネットワークで起こります。 SIPは503応答コードを通してオーバーロード取り扱いのための限定的なサポートを提供します。コードは、それが積みすぎられると上流の要素に言います。 しかしながら、多数の問題はこのメカニズムと同一視されました。 このドキュメントは、既存の503メカニズムで問題をまとめて、いくつかの要件をソリューションに提供します。
Rosenberg Informational [Page 1] RFC 5390 Overload Requirements December 2008
[1ページ]RFC5390オーバーロード要件2008年12月の情報のローゼンバーグ
Table of Contents
目次
1. Introduction ....................................................2
2. Causes of Overload ..............................................2
3. Terminology .....................................................4
4. Current SIP Mechanisms ..........................................4
5. Problems with the Mechanism .....................................5
5.1. Load Amplification .........................................5
5.2. Underutilization ...........................................9
5.3. The Off/On Retry-After Problem .............................9
5.4. Ambiguous Usages ..........................................10
6. Solution Requirements ..........................................10
7. Security Considerations ........................................13
8. Acknowledgements ...............................................13
9. References .....................................................14
9.1. Normative Reference .......................................14
9.2. Informative References ....................................14
1. 序論…2 2. オーバーロードの原因…2 3. 用語…4 4. 現在の一口メカニズム…4 5. メカニズムに関する問題…5 5.1. 増幅をロードしてください…5 5.2. 過少利用…9 5.3. 後の再試行問題のオフ/…9 5.4. あいまいな用法…10 6. ソリューション要件…10 7. セキュリティ問題…13 8. 承認…13 9. 参照…14 9.1. 標準の参照…14 9.2. 有益な参照…14
1. Introduction
1. 序論
Overload occurs in Session Initiation Protocol (SIP) [RFC3261] networks when proxies and user agents have insufficient resources to complete the processing of a request or a response. SIP provides limited support for overload handling through its 503 response code. This code allows a server to tell an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism.
プロキシとユーザエージェントに要求か応答の処理を終了する不十分なリソースがあるとき、オーバーロードはSession Initiationプロトコル(SIP)[RFC3261]ネットワークで起こります。 SIPは503応答コードを通してオーバーロード取り扱いのための限定的なサポートを提供します。 このコードで、サーバは、それが積みすぎられると上流の要素に言うことができます。 しかしながら、多数の問題はこのメカニズムと同一視されました。
This document describes the general problem of SIP overload and reviews the current SIP mechanisms for dealing with overload. It then explains some of the problems with these mechanisms. Finally, the document provides a set of requirements for fixing these problems.
このドキュメントは、SIPオーバーロードの一般的問題について説明して、オーバーロードに対処するために現在のSIPメカニズムを見直します。 それで、次に、これらのメカニズムに関する問題のいくつかがわかります。最終的に、ドキュメントはこれらの問題を修正するための1セットの要件を提供します。
2. Causes of Overload
2. オーバーロードの原因
Overload occurs when an element, such as a SIP user agent or proxy, has insufficient resources to successfully process all of the traffic it is receiving. Resources include all of the capabilities of the element used to process a request, including CPU processing, memory, I/O, or disk resources. It can also include external resources such as a database or DNS server, in which case the CPU, processing, memory, I/O, and disk resources of those servers are effectively part of the logical element processing the request. Overload can occur for many reasons, including:
SIPユーザエージェントかプロキシなどの要素に首尾よくそれが受けているトラフィックのすべてを処理する不十分なリソースがあるとき、オーバーロードは起こります。 リソースはCPU処理を含む要求を処理するのにおいて中古の要素、メモリ、入出力、またはディスクリソースの能力のすべてを含んでいます。 また、それはデータベースかDNSサーバなどの外部のリソースを含むことができます、その場合、事実上、それらのサーバに関するCPU、処理、メモリ、入出力、およびディスクリソースは要求を処理する論理要素の一部です。 以下を含んでいて、オーバーロードは種々の理由で起こることができます。
Rosenberg Informational [Page 2] RFC 5390 Overload Requirements December 2008
[2ページ]RFC5390オーバーロード要件2008年12月の情報のローゼンバーグ
Poor Capacity Planning: SIP networks need to be designed with
sufficient numbers of servers, hardware, disks, and so on, in
order to meet the needs of the subscribers they are expected to
serve. Capacity planning is the process of determining these
needs. It is based on the number of expected subscribers and the
types of flows they are expected to use. If this work is not done
properly, the network may have insufficient capacity to handle
predictable usages, including regular usages and predictably high
ones (such as high voice calling volumes on Mother's Day).
貧しいキャパシティプランニング: SIPネットワークは、十分な数のサーバ、ハードウェア、ディスクなどで設計されている必要があります、取り扱う彼らが予想される加入者の需要を満たすために。 キャパシティプランニングはこれらの必要性を決定するプロセスです。 それは予想された加入者の数と使用すると予想される流れのタイプに基づいています。 この仕事が適切に完了していないなら、ネットワークには、予測できる用法を扱う不十分な容量があるかもしれません、通常の用法と予想どおりに高いもの(母の日の量を訪問する高い声などの)を含んでいて。
Dependency Failures: A SIP element can become overloaded because a
resource on which it is dependent has failed or become overloaded,
greatly reducing the logical capacity of the element. In these
cases, even minimal traffic might cause the server to go into
overload. Examples of such dependency overloads include DNS
servers, databases, disks, and network interfaces.
依存失敗: SIP要素は、それが依存しているリソースが失敗したので積みすぎられるようになるか、または積みすぎられるようになることができます、要素の論理的な容量を大いに減少させて。 これらの場合では、最小量のトラフィックでさえ、サーバはオーバーロードに入るかもしれません。 そのような依存オーバーロードに関する例はDNSサーバ、データベース、ディスク、およびネットワーク・インターフェースを含んでいます。
Component Failures: A SIP element can become overloaded when it is a
member of a cluster of servers that each share the load of
traffic, and one or more of the other members in the cluster fail.
In this case, the remaining elements take over the work of the
failed elements. Normally, capacity planning takes such failures
into account, and servers are typically run with enough spare
capacity to handle failure of another element. However, unusual
failure conditions can cause many elements to fail at once. This
is often the case with software failures, where a bad packet or
bad database entry hits the same bug in a set of elements in a
cluster.
コンポーネント故障: それがそれぞれトラフィック、および1の負荷を共有するサーバのクラスタのメンバーであるときに、SIP要素が積みすぎられるようになることができますか、またはクラスタの一層の他のメンバーが失敗します。 この場合、残っている要素は失敗した要素の仕事を引き継ぎます。 通常、キャパシティプランニングはそのような失敗を考慮に入れます、そして、通常、サーバは別の要素の失敗を扱うことができるくらいの設備余力がある走行です。 しかしながら、珍しい失敗状態はすぐに、多くの要素に失敗できます。 しばしばこれはソフトウェア障害があるそうです。(そこでは、悪いパケットか悪いデータベースエントリーが1セットの要素でひとかたまりになって同じバグを打ちます)。
Avalanche Restart: One of the most troubling sources of overload is
avalanche restart. This happens when a large number of clients
all simultaneously attempt to connect to the network with a SIP
registration. Avalanche restart can be caused by several events.
One is the "Manhattan Reboots" scenario, where there is a power
failure in a large metropolitan area, such as Manhattan. When
power is restored, all of the SIP phones, whether in PCs or
standalone devices, simultaneously power on and begin booting.
They will all then connect to the network and register, causing a
flood of SIP REGISTER messages. Another cause of avalanche
restart is failure of a large network connection, for example, the
access router for an enterprise. When it fails, SIP clients will
detect the failure rapidly using the mechanisms in [OUTBOUND].
When connectivity is restored, this is detected, and clients re-
REGISTER, all within a short time period. Another source of
avalanche restart is failure of a proxy server. If clients had
殺到再開: オーバーロードの最も厄介な源の1つは殺到再開です。 多くのクライアントが皆、同時にSIP登録でネットワークに接続するのを試みるとき、これは起こります。 殺到再開はいくつかのイベントによって引き起こされる場合があります。 1つはマンハッタンなどの「マンハッタンリブート」シナリオです。(そこに、停電が大きい都市エリアにあります)。 パワーが同時に回復するとき、SIP電話のすべてが、PCかスタンドアロンデバイスにかかわらず電源を入れて、ブートし始めます。 SIP REGISTERメッセージの洪水を引き起こして、彼らは皆、次に、ネットワークに接続して、登録するでしょう。 殺到再開の別の原因は大きいネットワーク接続、例えば、企業のためのアクセスルータの失敗です。 失敗すると、SIPクライアントは、急速に[OUTBOUND]のメカニズムを使用することで失敗を検出するでしょう。 いつ接続性は回復していて、これが検出されるということですか、そして、短い期間以内のクライアント再REGISTER。 殺到再開の別の源がプロキシサーバの失敗である、クライアントはそうしました。
Rosenberg Informational [Page 3] RFC 5390 Overload Requirements December 2008
[3ページ]RFC5390オーバーロード要件2008年12月の情報のローゼンバーグ
all connected to the server with TCP, its failure will be
detected, followed by re-connection and re-registration to another
server. Note that [OUTBOUND] does provide some remedies to this
case.
すべてがTCPと共にサーバに接続して、失敗は検出されるでしょう、再接続と再登録が別のサーバにあとに続いていて。[OUTBOUND]がいくつかの療法を本件に供給することに注意してください。
Flash Crowds: A flash crowd occurs when an extremely large number of
users all attempt to simultaneously make a call. One example of
how this can happen is a television commercial that advertises a
number to call to receive a free gift. If the gift is compelling
and many people see the ad, many calls can be simultaneously made
to the same number. This can send the system into overload.
群衆をひらめかせてください: 非常に多くのユーザが皆、同時に電話をかけるのを試みるとき、フラッシュ群衆は起こります。 これがどう起こることができるかに関する1つの例が無料の贈り物を受け取るために呼ぶために数の広告を出すテレビコマーシャルです。 贈り物が無視できなく、多くの人々が広告を見るなら、同時に、多くの電話を同じ数までかけることができます。 これはシステムをオーバーロードに送ることができます。
Denial of Service (DoS) Attacks: An attacker, wishing to disrupt
service in the network, can cause a large amount of traffic to be
launched at a target server. This can be done from a central
source of traffic or through a distributed DoS attack. In all
cases, the volume of traffic well exceeds the capacity of the
server, sending the system into overload.
サービス妨害(DoS)は攻撃されます: ネットワークでサービスを中断することを願って、攻撃者は目標サーバで多量のトラフィックを始めさせることができます。これはトラフィックの主要な源、または、分配されたDoS攻撃を通して終わることができます。 すべての場合では、システムをオーバーロードに送って、交通量はサーバの容量をよく超えています。
Unfortunately, the overload problem tends to compound itself. When a network goes into overload, this can frequently cause failures of the elements that are trying to process the traffic. This causes even more load on the remaining elements. Furthermore, during overload, the overall capacity of functional elements goes down, since much of their resources are spent just rejecting or treating load that they cannot actually process. In addition, overload tends to cause SIP messages to be delayed or lost, which causes retransmissions to be sent, further increasing the amount of work in the network. This compounding factor can produce substantial multipliers on the load in the system. Indeed, in the case of UDP, with as many as seven retransmits of an INVITE request prior to timeout, overload can multiply the already-heavy message volume by as much as seven!
残念ながら、オーバーロード問題は、それ自体を合成する傾向があります。 ネットワークがオーバーロードに入るとき、これは頻繁にトラフィックを処理しようとしている要素の失敗を引き起こす場合があります。 これは残っている要素の上のさらに多くの負荷を引き起こします。 その上、オーバーロードの間、機能要素の全能力は落ちて、それらのリソースは、多くので、ただ、それらが実際に処理できない負荷を拒絶するか、または扱うのに費やされます。 さらに、オーバーロードは、遅らせるべきであるか、または失われるべきメッセージをSIPに引き起こす傾向があります(「再-トランスミッション」を送らせます)、ネットワークで仕事量をさらに増強して。 この悪化因子はシステムでかなりの乗数を負荷に生産できます。 本当に、7がタイムアウトの前にINVITE要求について再送するのと同じくらい多くがあるUDPの場合では、オーバーロードは既に重いメッセージ量を最大7に掛けることができます!
3. Terminology
3. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
4. Current SIP Mechanisms
4. 現在の一口メカニズム
SIP provides very basic support for overload. It defines the 503 response code, which is sent by an element that is overloaded. RFC 3261 defines it thus:
SIPはオーバーロードの非常に基本的なサポートを提供します。 それは503応答コードを定義します。(それは、積みすぎられる要素によって送られます)。 その結果、RFC3261はそれを定義します:
The server is temporarily unable to process the request due to
a temporary overloading or maintenance of the server. The
server MAY indicate when the client should retry the request in
サーバはサーバの一時的な積みすぎかメインテナンスのため一時要求を処理できません。サーバは、クライアントがいつ要求を再試行するべきであるかを示すかもしれません。
Rosenberg Informational [Page 4] RFC 5390 Overload Requirements December 2008
[4ページ]RFC5390オーバーロード要件2008年12月の情報のローゼンバーグ
a Retry-After header field. If no Retry-After is given, the
client MUST act as if it had received a 500 (Server Internal
Error) response.
後のRetryヘッダーフィールド。 後のRetryを全く与えないなら、まるで500(サーバInternal Error)応答を受けたかのようにクライアントは行動しなければなりません。
A client (proxy or UAC) receiving a 503 (Service Unavailable)
SHOULD attempt to forward the request to an alternate server.
It SHOULD NOT forward any other requests to that server for the
duration specified in the Retry-After header field, if present.
503(サービスUnavailable)SHOULDを受け取るクライアント(プロキシかUAC)は、代替のサーバに要求を転送するのを試みます。中で持続時間のためのそのサーバに後のRetryヘッダーフィールドを指定しましたSHOULD NOTの前進のいかなる他のも、要求する、存在しているなら。
Servers MAY refuse the connection or drop the request instead of
responding with 503 (Service Unavailable).
503(サービスUnavailable)で応じることの代わりに、サーバは、接続を拒否するか、または要求を下げるかもしれません。
The objective is to provide a mechanism to move the work of the overloaded server to another server so that the request can be processed. The Retry-After header field, when present, is meant to allow a server to tell an upstream element to back off for a period of time, so that the overloaded server can work through its backlog of work.
目的は要求を処理できるように積みすぎられたサーバの仕事を別のサーバに動かすためにメカニズムを提供することです。 存在しているとき、サーバは、後のRetryヘッダーフィールドでしばらく引き返すように上流の要素に言うことになっていることができます、積みすぎられたサーバがやり残した仕事を終えることができるように。
RFC 3261 also instructs proxies to not forward 503 responses upstream, at SHOULD NOT strength. This is to avoid the upstream server of mistakingly concluding that the proxy is overloaded when, in fact, the problem was an element further downstream.
また、RFC3261は、SHOULD NOTの強さで上流へ503の応答を進めないようプロキシに命令します。 これは、川下でさらに事実上、問題が要素であったときにプロキシが積みすぎられると間違って結論を下す上流のサーバを避けるためのものです。
5. Problems with the Mechanism
5. メカニズムに関する問題
At the surface, the 503 mechanism seems workable. Unfortunately, this mechanism has had numerous problems in actual deployment. These problems are described here.
表面では、503メカニズムが実行可能に思えます。 残念ながら、このメカニズムには、実際の展開における多数の問題がありました。 これらの問題はここで説明されます。
5.1. Load Amplification
5.1. 負荷増幅
The principal problem with the 503 mechanism is that it tends to substantially amplify the load in the network when the network is overloaded, causing further escalation of the problem and introducing the very real possibility of congestive collapse. Consider the topology in Figure 1.
503メカニズムに関する主要な問題はネットワークが積みすぎられるとき、ネットワークで負荷をかなり増幅する傾向があるということです、問題のさらなる増大を引き起こして、充血性の崩壊の非常に本当の可能性を導入して。 図1のトポロジーを考えてください。
Rosenberg Informational [Page 5] RFC 5390 Overload Requirements December 2008
[5ページ]RFC5390オーバーロード要件2008年12月の情報のローゼンバーグ
+------+
> | |
/ | S1 |
/ | |
/ +------+
/
/
/
/
+------+ / +------+
--------> | |/ | |
| P1 |---------> | S2 |
--------> | |\ | |
+------+ \ +------+
\
\
\
\
\
\ +------+
\ | |
> | S3 |
| |
+------+
+------+ >。| | / | S1| / | | / +------+ / / / / +------+ / +------+ -------->| |/ | | | P1|、-、-、-、-、-、-、-、--、>| S2| -------->| |\ | | +------+ \ +------+ \ \ \ \ \ \ +------+ \ | | >| S3| | | +------+
Figure 1
図1
Proxy P1 receives SIP requests from many sources and acts solely as a load balancer, proxying the requests to servers S1, S2, and S3 for processing. The input load increases to the point where all three servers become overloaded. Server S1, when it receives its next request, generates a 503. However, because the server is loaded, it might take some time to generate the 503. If SIP is being run over UDP, this may result in request retransmissions, which further increase the work on S1. Even in the case of TCP, if the server is loaded and the kernel cannot send TCP acknowledgements fast enough, TCP retransmits may occur. When the 503 is received by P1, it retries the request on S2. S2 is also overloaded and eventually generates a 503, but in the interim may also be hit with retransmits. P1 once again tries another server, this time S3, which also eventually rejects it with a 503.
プロキシP1は唯一負荷分散装置として多くのソースと行為からSIP要求を受け取ります、処理のためにサーバのS1、S2、およびS3に要求をproxyingして。 入力負荷はすべての3つのサーバが積みすぎられるようになるポイントに増加します。 次の要求を受け取るとき、サーバS1は503を生成します。 しかしながら、サーバがロードされているので、503を生成するにはいくらかの時間がかかるかもしれません。 SIPがUDPの上に実行されているなら、これは要求「再-トランスミッション」をもたらすかもしれません。(さらに、「再-トランスミッション」はS1への作業を増強します)。 TCPの場合ではさえ、サーバがロードされていて、カーネルが十分速く発信できないのでTCPが再送するなら、起こるかもしれません。 503がそうときに、P1によって受け取られて、それはS2で要求を再試行します。 S2はまた、その間打たれるかもしれない状態でまた、である積みすぎであり、結局、503を生成します。再送します。 P1はもう一度別のサーバ、また、結局503でそれを拒絶するこの時間S3を試みます。
Thus, the processing of this request, which ultimately failed, involved four SIP transactions (client to P1, P1 to S1, P1 to S2, P1 to S3), each of which may have involved many retransmissions -- up to seven in the case of UDP. Thus, under unloaded conditions, a single request from a client would generate one request (to S1, S2, or S3) and two responses (from S1 to P1, then P1 to the client). When the
その結果、結局失敗したこの要求の処理が4つのSIPトランザクションにかかわった、(P1へのクライアント、S1へのP1、S2へのP1、S3へのP1)、それのそれぞれが多くの「再-トランスミッション」にUDPに関するケースに7までかかわったかもしれない。 したがって、降ろされた条件のもとで、クライアントからのただ一つの要求は1つの要求(S1、S2、またはS3への)と2つの応答(クライアントへの当時のS1からP1までのP1)を生成するでしょう。 いつ
Rosenberg Informational [Page 6] RFC 5390 Overload Requirements December 2008
[6ページ]RFC5390オーバーロード要件2008年12月の情報のローゼンバーグ
network is overloaded, a single request from the client, before timing out, could generate as many as 18 requests and as many responses when UDP is used! The situation is better with TCP (or any reliable transport in general), but even if there was never a TCP segment retransmitted, a single request from the client can generate three requests and four responses. Each server had to expend resources to process these messages. Thus, more messages and more work were sent into the network at the point at which the elements became overloaded. The 503 mechanism works well when a single element is overloaded. But when the problem is overall network load, the 503 mechanism actually generates more messages and more work for all servers, ultimately resulting in the rejection of the request anyway.
ネットワークは積みすぎられて、UDPが使用されているとき、クライアントからのただ一つの要求は外で調節する前に、最大18の要求と同じくらい多くの応答を生成するかもしれません! 状況はTCP(または、一般に、どんな信頼できる輸送も)によって、より良いのですが、再送されたTCPセグメントが決してなかったとしても、クライアントからのただ一つの要求は3つの要求と4つの応答を生成することができます。 各サーバは、これらのメッセージを処理するためにリソースを費やさなければなりませんでした。 したがって、要素が積みすぎられるようになったポイントのネットワークにより多くのメッセージと、より多くの仕事を送りました。 ただ一つの要素が積みすぎられるとき、503メカニズムはうまくいきます。 しかし、問題が総合的なネットワーク負荷であるときに、503メカニズムは実際にすべてのサーバのための、より多くのメッセージと、より多くの仕事を生成します、結局とにかく要求の拒絶をもたらして。
The problem becomes amplified further if one considers proxies upstream from P1, as shown in Figure 2.
人が、プロキシがP1から上流であると考えるなら、問題は図2に示されるようにさらに増幅されるようになります。
Rosenberg Informational [Page 7] RFC 5390 Overload Requirements December 2008
[7ページ]RFC5390オーバーロード要件2008年12月の情報のローゼンバーグ
+------+
> | | <
/ | S1 | \\
/ | | \\
/ +------+ \\
/ \
/ \\
/ \\
/ \
+------+ / +------+ +------+
| | / | | | |
| P1 | ---------> | S2 |<----------| P2 |
| | \ | | | |
+------+ \ +------+ +------+
^ \ / ^
\ \ // /
\ \ // /
\ \ // /
\ \ / /
\ \ +------+ // /
\ \ | | // /
\ > | S3 | < /
\ | | /
\ +------+ /
\ /
\ /
\ /
\ /
\ /
\ /
\ /
\ /
+------+
| |
| PA |
| |
+------+
^ ^
| |
| |
+------+ >。| | </| S1| \\ / | | \\ / +------+ \\ / \ / \\ / \\ / \ +------+ / +------+ +------+ | | / | | | | | P1| --------->| S2| <、-、-、-、-、-、-、-、-、--、| P2| | | \ | | | | +------+ \ +------+ +------+ ^ \ / ^ \ \ // / \ \ // / \ \ // / \ \ / / \ \ +------+ // / \ \ | | ///\>。| S3| </\| | / \ +------+ / \ / \ / \ / \ / \ / \ / \ / \ / +------+ | | | PA| | | +------+ ^ ^ | | | |
Figure 2
図2
Here, proxy PA receives requests and sends these to proxies P1 or P2. P1 and P2 both load balance across S1 through S3. Assuming again S1 through S3 are all overloaded, a request arrives at PA, which tries P1 first. P1 tries S1, S2, and then S3, and each transaction results in many request retransmits if UDP is used. Since P1 is unable to
ここで、プロキシPAはプロキシP1かP2に要求を受け取って、これらを送ります。 P1とP2はS3を通してS1の向こう側にともにバランスをロードします。 再びS1からS3がすべて積みすぎられると仮定して、要求はPAに到着します。(それは、最初に、P1を試みます)。 P1はS1、S2を試みて、次に、S3を試みます、そして、UDPが使用されているなら、多くにおける結果が要求する各トランザクションは再送されます。 以来、P1であることができません。
Rosenberg Informational [Page 8] RFC 5390 Overload Requirements December 2008
[8ページ]RFC5390オーバーロード要件2008年12月の情報のローゼンバーグ
eventually process the request, it rejects it. However, since all of its downstream dependencies are busy, it decides to send a 503. This propagates to PA, which tries P2, which tries S1 through S3 again, resulting in a 503 once more. Thus, in this case, we have doubled the number of SIP transactions and overall work in the network compared to the previous case. The problem here is that the fact that S1 through S3 were overloaded was known to P1, but this information was not passed back to PA and through to P2, so that P2 retries S1 through S3 again.
結局、要求を処理してください、そして、それはそれを拒絶します。 しかしながら、川下の依存のすべてが忙しいので、それは、503を送ると決めます。 これはPAに伝播されます。(それは、P2を試みます)。(もう一度503をもたらして、P2は再びS3を通してS1を試みます)。 したがって、この場合、先の事件と比べて、私たちはネットワークでSIPトランザクションと総合的な仕事の数を倍にしました。 この情報がPAに向かうのとS1からS3が積みすぎられたという事実がP1において知られていたのではなく、P2に終わったという問題は、ここにあります、P2が再びS3を通してS1を再試行するように。
5.2. Underutilization
5.2. 過少利用
Interestingly, there are also examples of deployments where the network capacity was greatly reduced as a consequence of the overload mechanism. Consider again Figure 1. Unfortunately, RFC 3261 is unclear on the scope of a 503. When it is received by P1, does the proxy cease sending requests to that IP address? To the hostname? To the URI? Some implementations have chosen the hostname as the scope. When the hostname for a URI points to an SRV record in the DNS, which, in turn, maps to a cluster of downstream servers (S1, S2, and S3 in the example), a 503 response from a single one of them will make the proxy believe that the entire cluster is overloaded. Consequently, proxy P1 will cease sending any traffic to any element in the cluster, even though there are elements in the cluster that are underutilized.
おもしろく、展開に関する例もネットワーク容量がオーバーロードメカニズムの結果として大いに減少したところにあります。 もう一度図1を考えてください。 残念ながら、RFC3261は503の範囲で不明瞭です。 それがP1によって受け取られるとき、プロキシは、そのIPアドレスに要求を送るのをやめますか? ホスト名に? URIに? いくつかの実装が範囲としてホスト名を選びました。 URIのためのホスト名がSRV記録を示すとき、シングルからのDNS、503応答では、彼らのひとりはプロキシに全体のクラスタが積みすぎられると信じさせるでしょう。順番に、DNSは(例のS1、S2、およびS3)を川下のサーバのクラスタに写像します。 その結果、プロキシP1は、クラスタのどんな要素にもどんなトラフィックも送るのをやめるでしょう、クラスタのunderutilizedされる要素がありますが。
5.3. The Off/On Retry-After Problem
5.3. 後の再試行問題のオフ/
The Retry-After mechanism allows a server to tell an upstream element to stop sending traffic for a period of time. The work that would have otherwise been sent to that server is instead sent to another server. The mechanism is an all-or-nothing technique. A server can turn off all traffic towards it, or none. There is nothing in between. This tends to cause highly oscillatory behavior under even mild overload. Consider a proxy P1 that is balancing requests between two servers S1 and S2. The input load just reaches the point where both S1 and S2 are at 100% capacity. A request arrives at P1 and is sent to S1. S1 rejects this request with a 503, and decides to use Retry-After to clear its backlog. P1 stops sending all traffic to S1. Now, S2 gets traffic, but it is seriously overloaded -- at 200% capacity! It decides to reject a request with a 503 and a Retry-After, which now forces P1 to reject all traffic until S1's Retry-After timer expires. At that point, all load is shunted back to S1, which reaches overload, and the cycle repeats.
後のRetryメカニズムで、サーバは、しばらくトラフィックを送りながら、止まるように上流の要素に言うことができます。 代わりにそうでなければそのサーバに送られた仕事を別のサーバに送ります。メカニズムがそう、オール、無、テクニック。 サーバはすべてのトラフィックをそれ、またはなにもに向かってオフにすることができます。 何も中間でありません。 これは、温和なオーバーロードの下でさえ非常に振動性の振舞いを引き起こす傾向があります。 バランスをとっているプロキシP1が2つのサーバの間でS1とS2を要求すると考えてください。 入力負荷はただ、S1とS2の両方が100%の容量であるポイントに達します。 要求はP1に到着して、S1に送ります。 S1は、a503でこの要求を拒絶して、予備をきれいにするのに後のRetryを使用すると決めます。 P1は、すべてのトラフィックをS1に送るのを止めます。 それは真剣に積みすぎられます--今、S2はトラフィックを得ますが、200%の容量で得る! それは、a503との要求と後のRetryを拒絶すると決めます。(S1の後のRetryタイマが期限が切れるまで、P1は現在、Retryでやむを得ずすべてのトラフィックを拒絶します)。 その時、すべての負荷がS1に転じて戻ります、そして、サイクルは繰り返されます。(範囲はS1を積みすぎます)。
It's important to observe that this problem is only observed for servers where there are a small number of upstream elements sending it traffic, as is the case in these examples. If a proxy is accessed
この問題がトラフィックをそれに送る少ない数の上流の要素があるサーバに関して観測されるだけであるのを観測するのは重要です、これらの例におけるケースのように。 プロキシがアクセスされているなら
Rosenberg Informational [Page 9] RFC 5390 Overload Requirements December 2008
[9ページ]RFC5390オーバーロード要件2008年12月の情報のローゼンバーグ
by a large number of clients, each of which sends a small amount of traffic, the 503 mechanism with Retry-After is quite effective when utilized with a subset of the clients. This is because spreading the 503 out amongst the clients has the effect of providing the proxy more fine-grained controls on the amount of work it receives.
クライアントの多くで、クライアントの部分集合と共に利用されると、後のRetryがある503メカニズムはかなり効果的です。それはそれぞれ少量のトラフィックを送ります。 これはクライアントの中に503を広げるのにおいてそれが受ける仕事量できめ細かにより粒状のコントロールをプロキシに提供するという効果があるからです。
5.4. Ambiguous Usages
5.4. あいまいな用法
Unfortunately, the specific instances under which a server is to send a 503 are ambiguous. The result is that implementations generate 503 for many reasons, only some of which are related to actual overload. For example, RFC 3398 [RFC3398], which specifies interworking from SIP to ISDN User Part (ISUP), defines the usage of 503 when the gateway receives certain ISUP cause codes from downstream switches. In these cases, the gateway has ample capacity; it's just that this specific request could not be processed because of a downstream problem. All subsequent requests might succeed if they take a different route in the Public Switched Telephone Network (PSTN).
残念ながら、503を送るサーバがことである特定のインスタンスはあいまいです。 結果は実装がそれの或るものだけが実際のオーバーロードに関連する503を生成するということです。 ISUPが川下のスイッチからコードを引き起こすのを確信していた状態でゲートウェイが受信されるとき、例えば、RFC3398[RFC3398](SIPからISDN User Partまで(ISUP)を織り込みながら、指定する)は503の用法を定義します。 これらの場合では、ゲートウェイは十分な容量を持っています。 まさしく、川下の問題のためにこの特定の要求を処理できなかったということです。 Public Switched Telephone Network(PSTN)の異なったルートを取るなら、すべてのその後の要求が成功するかもしれません。
This causes two problems. First, during periods of overload, it exacerbates the problems above because it causes additional 503 to be fed into the system, causing further work to be generated in conditions of overload. Second, it becomes hard for an upstream element to know whether to retry when a 503 is received. There are classes of failures where trying on another server won't help, since the reason for the failure was that a common downstream resource is unavailable. For example, if servers S1 and S2 share a database and the database fails, a request sent to S1 will result in a 503, but retrying on S2 won't help since the same database is unavailable.
これは2つの問題を引き起こします。最初にオーバーロードの期間、追加503をシステムに入れさせるので、上の問題を悪化させます、仕事がオーバーロードの状態で生成されることをさらに引き起こして。 2番目に、503が受け取られているとき、再試行するかどうかを知るのが上流の要素に困難になります。 失敗のクラスが別のサーバを試着するのが助けないところにあります、失敗の理由が一般的な川下のリソースが入手できないということであったので。 例えば、サーバのS1とS2がデータベースを共有して、データベースが失敗すると、S1に送られた要求は503をもたらすでしょうが、同じデータベースが入手できないので、S2で再試行するのは助けないでしょう。
6. Solution Requirements
6. ソリューション要件
In this section, we propose requirements for an overload control mechanism for SIP that addresses these problems.
このセクションで、私たちはこれらのその問題を訴えるSIPのためにオーバーロード制御機構のための要件を提案します。
REQ 1: The overload mechanism shall strive to maintain the overall
useful throughput (taking into consideration the quality-of-
service needs of the using applications) of a SIP server at
reasonable levels, even when the incoming load on the network is
far in excess of its capacity. The overall throughput under load
is the ultimate measure of the value of an overload control
mechanism.
REQ1: オーバーロードメカニズムが、総合的な役に立つスループットを維持するように努力するものとする、(品質を考慮に入れる、-、-、使用アプリケーションのサービスの必要性) 妥当な水準におけるSIPサーバには、入来でさえあるときに、はるかに容量を超えてネットワークの負荷があります。 負荷の下における総合的なスループットはオーバーロード制御機構の価値の究極の基準です。
REQ 2: When a single network element fails, goes into overload, or
suffers from reduced processing capacity, the mechanism should
strive to limit the impact of this on other elements in the
network. This helps to prevent a small-scale failure from
becoming a widespread outage.
REQ2: ただ一つのネットワーク要素が失敗するか、オーバーロードに入るか、または減少している処理容量が欠点であると、メカニズムは、他の要素の上でネットワークがこの影響を制限するように努力するはずです。 これは、小規模の失敗が広範囲の供給停止になるのを防ぐのを助けます。
Rosenberg Informational [Page 10] RFC 5390 Overload Requirements December 2008
[10ページ]RFC5390オーバーロード要件2008年12月の情報のローゼンバーグ
REQ 3: The mechanism should seek to minimize the amount of
configuration required in order to work. For example, it is
better to avoid needing to configure a server with its SIP message
throughput, as these kinds of quantities are hard to determine.
REQ3: メカニズムは働くのに必要である構成の量を最小にしようとするはずです。 例えば、SIPメッセージスループットでサーバを構成するのが必要であることを避けるほうがよいです、これらの種類の量は決定しにくいとき。
REQ 4: The mechanism must be capable of dealing with elements that
do not support it, so that a network can consist of a mix of
elements that do and don't support it. In other words, the
mechanism should not work only in environments where all elements
support it. It is reasonable to assume that it works better in
such environments, of course. Ideally, there should be
incremental improvements in overall network throughput as
increasing numbers of elements in the network support the
mechanism.
REQ4: メカニズムはそれをサポートしない要素に対処できなければなりません、ネットワークがそれをして、サポートしない要素のミックスから成ることができるように。 言い換えれば、メカニズムはすべての要素がそれをサポートする環境だけで動作するはずがありません。 それがそのような環境でうまくいくと仮定するのはもちろん妥当です。 ネットワークにおける増加する数の要素がメカニズムをサポートするので、理想的に、総合的なネットワークスループットには増加の改良があるべきです。
REQ 5: The mechanism should not assume that it will only be deployed
in environments with completely trusted elements. It should seek
to operate as effectively as possible in environments where other
elements are malicious; this includes preventing malicious
elements from obtaining more than a fair share of service.
REQ5: メカニズムは、それが完全に信じられた要素で環境で配備されるだけであると仮定するはずがありません。 それは他の要素が悪意がある環境でできるだけ有効に作動しようとするべきです。 これは、悪意がある要素がサービスの正当な分け前以上を得るのを防ぐのを含んでいます。
REQ 6: When overload is signaled by means of a specific message, the
message must clearly indicate that it is being sent because of
overload, as opposed to other, non overload-based failure
conditions. This requirement is meant to avoid some of the
problems that have arisen from the reuse of the 503 response code
for multiple purposes. Of course, overload is also signaled by
lack of response to requests. This requirement applies only to
explicit overload signals.
REQ6: オーバーロードが特定のメッセージによって合図されるとき、メッセージは、それがオーバーロードのために送られるのを明確に示さなければなりません、他の、そして、非オーバーロードベースの失敗状態と対照的に。 この要件は複数の目的のために503応答コードの再利用から起こった問題のいくつかを避けることになっています。 もちろん、また、オーバーロードは無反応によって要求に合図されます。 この要件は明白なオーバーロード信号だけに適用されます。
REQ 7: The mechanism shall provide a way for an element to throttle
the amount of traffic it receives from an upstream element. This
throttling shall be graded so that it is not all-or-nothing as
with the current 503 mechanism. This recognizes the fact that
"overload" is not a binary state and that there are degrees of
overload.
REQ7: メカニズムは要素がそれが上流の要素から受ける交通の量を阻止する方法を提供するものとします。 この阻止が等級付けされるものとするのでそれがそれでない、オール、無、現在の503メカニズムのように。 これは「オーバーロード」が2進の状態でなく、オーバーロードの度合いがあるという事実を認識します。
REQ 8: The mechanism shall ensure that, when a request was not
processed successfully due to overload (or failure) of a
downstream element, the request will not be retried on another
element that is also overloaded or whose status is unknown. This
requirement derives from REQ 1.
REQ8: メカニズムは、要求が下流要素のオーバーロード(または、失敗)のため首尾よく処理されなかったとき、要求がまた、積みすぎられるか、または状態も未知である別の要素の上で再試行されないのを確実にするものとします。 この要件がREQ1に由来しています。
REQ 9: That a request has been rejected from an overloaded element
shall not unduly restrict the ability of that request to be
submitted to and processed by an element that is not overloaded.
This requirement derives from REQ 1.
REQ9: 積みすぎられない要素に従って、要求が積みすぎられた要素から拒絶されたのが、提出されるというその要求の能力を過度に制限して、処理しないものとしました。 この要件がREQ1に由来しています。
Rosenberg Informational [Page 11] RFC 5390 Overload Requirements December 2008
[11ページ]RFC5390オーバーロード要件2008年12月の情報のローゼンバーグ
REQ 10: The mechanism should support servers that receive requests
from a large number of different upstream elements, where the set
of upstream elements is not enumerable.
REQ10: メカニズムは多くの異なった上流の要素から要求を受け取るサーバをサポートするはずです。そこでは、上流の要素のセットがenumerableではありません。
REQ 11: The mechanism should support servers that receive requests
from a finite set of upstream elements, where the set of upstream
elements is enumerable.
REQ11: メカニズムは1つの有限集合の上流の要素から要求を受け取るサーバをサポートするはずです。そこでは、上流の要素のセットがenumerableです。
REQ 12: The mechanism should work between servers in different
domains.
REQ12: メカニズムは異なったドメインでサーバの間で動作するはずです。
REQ 13: The mechanism must not dictate a specific algorithm for
prioritizing the processing of work within a proxy during times of
overload. It must permit a proxy to prioritize requests based on
any local policy, so that certain ones (such as a call for
emergency services or a call with a specific value of the
Resource-Priority header field [RFC4412]) are given preferential
treatment, such as not being dropped, being given additional
retransmission, or being processed ahead of others.
REQ13: メカニズムはオーバーロードの倍の間、プロキシの中で仕事の処理を最優先させるための特定のアルゴリズムを決めてはいけません。 それは、プロキシがどんなローカルの方針にも基づく要求を最優先させることを許可しなければなりません、あるもの(Resource-優先権ヘッダーフィールド[RFC4412]の特定の値がある緊急サービスのための呼び出しか呼び出しなどの)に優遇を与えるように、落とされないのなどように、追加「再-トランスミッション」を与えるか、または他のものの前で処理して。
REQ 14: The mechanism should provide unambiguous directions to
clients on when they should retry a request and when they should
not. This especially applies to TCP connection establishment and
SIP registrations, in order to mitigate against avalanche restart.
REQ14: メカニズムは要求を再試行するべきである時、彼らが提供するべきでないときに時クライアントへの明白な指示を提供するはずです。 これは、雪崩再開を困難にするためにTCPコネクション確立とSIP登録証明書に特に申し込まれます。
REQ 15: In cases where a network element fails, is so overloaded
that it cannot process messages, or cannot communicate due to a
network failure or network partition, it will not be able to
provide explicit indications of the nature of the failure or its
levels of congestion. The mechanism must properly function in
these cases.
REQ15: ネットワーク要素が失敗できませんし、メッセージを処理できないように積みすぎることができませんし、またネットワーク失敗かネットワークパーティションのため交信できない場合では、それは失敗の本質かその混雑のレベルの明白なしるしを供給できないでしょう。 メカニズムはこれらの場合で適切に機能しなければなりません。
REQ 16: The mechanism should attempt to minimize the overhead of the
overload control messaging.
REQ16: メカニズムは、オーバーロードコントロールメッセージングのオーバーヘッドを最小にするのを試みるはずです。
REQ 17: The overload mechanism must not provide an avenue for
malicious attack, including DoS and DDoS attacks.
REQ17: オーバーロードメカニズムはDoSとDDoS攻撃を含む悪意ある攻撃に大通りを提供してはいけません。
REQ 18: The overload mechanism should be unambiguous about whether a
load indication applies to a specific IP address, host, or URI, so
that an upstream element can determine the load of the entity to
which a request is to be sent.
REQ18: オーバーロードメカニズムは負荷指示が特定のIPアドレス、ホスト、またはURIに適用されるかどうか明白であるべきです、上流の要素が送られる要求がことである実体の負荷を決定できるように。
REQ 19: The specification for the overload mechanism should give
guidance on which message types might be desirable to process over
others during times of overload, based on SIP-specific
considerations. For example, it may be more beneficial to process
a SUBSCRIBE refresh with Expires of zero than a SUBSCRIBE refresh
REQ19: オーバーロードメカニズムのための仕様はメッセージタイプがオーバーロードの倍の間、他のものの上で処理するために望ましいかもしれない指導を与えるべきです、SIP特有の問題に基づいて。 例えば、登録より登録がExpiresと共にリフレッシュする過程に有益なゼロがリフレッシュするということであるかもしれません。
Rosenberg Informational [Page 12] RFC 5390 Overload Requirements December 2008
[12ページ]RFC5390オーバーロード要件2008年12月の情報のローゼンバーグ
with a non-zero expiration (since the former reduces the overall
amount of load on the element), or to process re-INVITEs over new
INVITEs.
非ゼロ満了(前者が要素で総合的な量の負荷を減少させるので)か、新しいINVITEsの上の過程再INVITEsに。
REQ 20: In a mixed environment of elements that do and do not
implement the overload mechanism, no disproportionate benefit
shall accrue to the users or operators of the elements that do not
implement the mechanism.
REQ20: オーバーロードメカニズムをして、実行しない要素の複雑な環境で、どんな不均衡な利益もメカニズムを実行しない要素のユーザかオペレータに生じないものとします。
REQ 21: The overload mechanism should ensure that the system remains
stable. When the offered load drops from above the overall
capacity of the network to below the overall capacity, the
throughput should stabilize and become equal to the offered load.
REQ21: オーバーロードメカニズムは、システムが安定した状態を保つのを確実にするはずです。 提供された負荷がネットワークの全能力から全能力の下に低下すると、スループットは、安定して、提供された負荷と等しくなるべきです。
REQ 22: It must be possible to disable the reporting of load
information towards upstream targets based on the identity of
those targets. This allows a domain administrator who considers
the load of their elements to be sensitive information, to
restrict access to that information. Of course, in such cases,
there is no expectation that the overload mechanism itself will
help prevent overload from that upstream target.
REQ22: それらの目標のアイデンティティに基づく上流の目標に向かって負荷情報の報告を無能にするのは可能であるに違いありません。 これは、アクセスをその情報に制限するためにそれらの要素の負荷が機密情報であると考えるドメイン管理者を許容します。 もちろん、オーバーロードメカニズム自体がその上流の目標からオーバーロードを防ぐのを助ける期待が全くそのような場合ありません。
REQ 23: It must be possible for the overload mechanism to work in
cases where there is a load balancer in front of a farm of
proxies.
REQ23: オーバーロードメカニズムが負荷分散装置がプロキシの農場の正面にある場合で動作するのは、可能であるに違いありません。
7. Security Considerations
7. セキュリティ問題
Like all protocol mechanisms, a solution for overload handling must prevent against malicious inside and outside attacks. This document includes requirements for such security functions.
すべてがメカニズムについて議定書の中で述べるように、取り扱いが悪意がある内外に対して防がなければならないオーバーロードの解決策は攻撃されます。 このドキュメントはそのようなセキュリティ機能のための要件を含んでいます。
Any mechanism that improves the behavior of SIP elements under load will result in more predictable performance in the face of application-layer denial-of-service attacks.
負荷の下でSIP要素の動きを改良するどんなメカニズムも応用層サービス不能攻撃の表面における、より予測できる性能をもたらすでしょう。
8. Acknowledgements
8. 承認
The author would like to thank Steve Mayer, Mouli Chandramouli, Robert Whent, Mark Perkins, Joe Stone, Vijay Gurbani, Steve Norreys, Volker Hilt, Spencer Dawkins, Matt Mathis, Juergen Schoenwaelder, and Dale Worley for their contributions to this document.
作者はこのドキュメントへの彼らの貢献についてスティーブ・マイヤー、Mouli Chandramouli、ロバートWhent、マーク・パーキンス、ジョー・ストーン、ビジェイGurbani、スティーブNorreys、ボルカーHilt、スペンサー・ダウキンズ、マット・マシス、ユルゲンSchoenwaelder、およびデール・ウォーリーに感謝したがっています。
Rosenberg Informational [Page 13] RFC 5390 Overload Requirements December 2008
[13ページ]RFC5390オーバーロード要件2008年12月の情報のローゼンバーグ
9. References
9. 参照
9.1. Normative Reference
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
9.2. Informative References
9.2. 有益な参照
[OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
Work in Progress, October 2008.
[外国行き]のジョニングス、C.、およびR.マーイ、「クライアントを管理すると、セッション開始プロトコル(一口)のコネクションズは開始しました」、処理中の作業、2008年10月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong,
"Integrated Services Digital Network (ISDN) User Part
(ISUP) to Session Initiation Protocol (SIP) Mapping",
RFC 3398, December 2002.
[RFC3398]キャマリロ(G.、ローチ、A.、ピーターソン、J.、およびL.オング)は、「サービスディジタル通信網(ISDN)ユーザ部分(ISUP)をセッション開始プロトコル(一口)マッピングと統合しました」、RFC3398、2002年12月。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006.
[RFC4412]SchulzrinneとH.とJ.ポーク、「セッション開始プロトコル(一口)のためのコミュニケーションリソース優先権」、RFC4412、2006年2月。
Author's Address
作者のアドレス
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサンローゼンバーグシスコのニュージャージーエディソン(米国)
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
メール: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Rosenberg Informational [Page 14]
ローゼンバーグInformationalです。[14ページ]
一覧
スポンサーリンク
