Network Working Group                                        K. Carlberg
Request for Comments: 3690                                           UCL
Category: Informational                                      R. Atkinson
                                                        Extreme Networks
                                                           February 2004
        
                     IP Telephony Requirements for
               Emergency Telecommunication Service (ETS)
        

Status of this Memo

このメモの位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2004). All Rights Reserved.

著作権(C)インターネット協会(2004)。全著作権所有。

Abstract

抽象

This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document.

この文書では、IPテレフォニーのコンテキスト内での緊急通信サービス(ETS)をサポートする要件のリストを提示します。これは、これらの要件に3689.ソリューションは、この文書で提示されていないRFCに提示一般的な要件を拡張したものです。

1. Introduction
1. はじめに

Effective telecommunications capabilities can be imperative to facilitate immediate recovery operations for serious disaster events, such as, hurricanes, floods, earthquakes, and terrorist attacks. Disasters can happen unexpectedly, at any time or place. Quick response for recovery operations requires immediate access to any public telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless Personal Digital Assistants (PDAs). The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support emergency management and recovery operations.

効果的な通信機能は、重大な災害などのイベント、ハリケーン、洪水、地震、テロ攻撃の即時回復操作を容易にするために不可欠することができます。災害は、任意の時間や場所で、不意に起こることができます。リカバリ操作のクイックレスポンスが手元にある任意の公衆電気通信機能への即時アクセスを必要とします。これらの機能は、次のとおりです。従来の電話、携帯電話、およびインターネットへのアクセスをオンライン端末、IP電話、および無線携帯情報端末(PDA)を介して。商用通信インフラは急速にインターネットベースの技術に進化しています。そのため、インターネットコミュニティは、どのようにそれができる最善のサポート緊急事態管理およびリカバリ操作を考慮する必要があります。

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 [1].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されます。

1.1. Problem
1.1. 問題

Standards have been developed by other standards bodies concerning emergency communications. As discussed in [3], some of these standards, such as T1.631 [5], define specific indicators or labels for emergency communications in Signaling System 7 (SS7) networks. Certain requirements must be defined in order to achieve peering across hybrid networks (networks that communicate between IP and other types of networks, such as that realized by the Public Switched Telephone Network) in order to achieve an interworking of services.

規格は、緊急通信に関する他の標準化団体によって開発されています。で論じたように[3]、例えばT1.631などのこれらの規格の一部は、[5]、シグナリングシステム7(SS7)ネットワークにおける緊急通信のために特定の指標またはラベルを定義します。一定の要件は、サービスのインターワーキングを実現するために(例えば、そのようなIPおよび他のタイプのネットワーク間の通信ネットワークは、公衆によって実現交換電話網)ハイブリッドネットワーク間のピアリング達成するために定義されなければなりません。

2. Scope
2.適用範囲

[3] has defined a set of general system requirements to support Emergency Telecommunications Service (ETS). This document defines an additional set of system requirements to achieve support for ETS within the specific context of IP telephony (note that this document views IP telephony within the context of an end-to-end application layer service). Solutions to requirements are not defined. The document does not specify protocol enhancements or specifications.

[3]緊急通信サービス(ETS)をサポートする一般的なシステム要件のセットを定義しています。この文書では、IPテレフォニーの特定のコンテキスト内でETSのサポートを実現するためのシステム要件の追加セットを定義します(この文書は、エンドツーエンドのアプリケーション層サービスのコンテキスト内でIPテレフォニーを見ていることに注意してください)。要件への解決策が定義されていません。文書は、プロトコルの拡張機能や仕様を指定していません。

Note that [4], Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP), is an RFC that shares some overlap with this document. However, [4] only applies to SIP and is not meant to be applied to a more general perspective of IP telephony as it relates to ETS.

[4]は、セッション開始プロトコル(SIP)のための資源優先度のメカニズムのための要件は、この文書といくつかの重複を共有RFCであることに留意されたいです。しかし、[4]のみSIPに適用され、それがETSに関連するIPテレフォニーのより一般的な観点に適用されるものではありません。

2.1. Out of Scope
2.1. 範囲外

An item that is not in scope of this document is mandating acceptance and support of the requirements presented in this document. The IETF does not mandate requirements or capabilities to independent networks that comprise the Internet. As an example, Internet Service Providers (ISP) may choose not to operate any telephony-related gateways or services. The IETF cannot and does not mandate that an ISP deploy either telephony-related gateways or telephony-related services. There is an expectation that business contracts, for example Service Level Agreements (SLA), will be used to satisfy those following requirements that apply to service providers. Absence of an SLA implies best effort service is provided.

この文書の範囲内にない項目は、この文書の要件の受け入れと支援を義務付けています。 IETFは、インターネットを含む、独立したネットワークへの要件や機能を強制しません。例として、インターネットサービスプロバイダ(ISP)は、任意のテレフォニー関連のゲートウェイやサービスを動作しないこともできます。 IETFは、およびISPがいずれかのテレフォニー関連のゲートウェイまたはテレフォニー関連サービスを展開することを強制しないことはできません。事業契約は、例えば、サービスレベル契約(SLA)のために、サービスプロバイダーには適用されたものは、次の要件を満たすために使用されるという期待があります。 SLAの不在は、ベストエフォート型のサービスが提供される暗示します。

It is assumed that some ISPs will choose to offer ETS services and that other carriers will choose not to offer ETS services. These requirements do not apply to ISPs that have chosen not to offer ETS services.

いくつかのISPは、ETSのサービスを提供するように選択することが想定され、他のキャリアは、ETSのサービスを提供しないことを選択すること。これらの要件は、ETSのサービスを提供しないことを選択しているISPには適用されません。

3. IP Telephony Requirements
3. IPテレフォニーの要件

The requirements in this section relate only to Telephony Signaling as used in Internet-based telephony services. They are an extension to the general requirements specified in [3]. The following requirements explicitly do not relate to IP-layer mechanisms, such as Differentiated Services or Integrated Services.

インターネットベースの電話サービスで使用されるように、このセクションの要件は、テレフォニーシグナリングにのみ関連します。彼らは、[3]で指定された一般的な要件に拡張したものです。次の要件が明示的な差別化サービスや統合サービスとしてIP層メカニズム、とは関係ありません。

1) Telephony signaling applications used with Internet-based telephony MUST be able to carry labels.

1)インターネットベースの電話と共に使用されるテレフォニーシグナリングアプリケーションは、ラベルを運ぶことができなければなりません。

2) The ability to carry labels MUST be extensible to support various types and numbers of labels. A single binary value will not be sufficient given the various labeling standards in existence today.

2)ラベルを運ぶ能力は、様々なタイプとラベルの数をサポートするように拡張可能でなければなりません。単一のバイナリ値は、現存する様々な表示基準、今日与えられた十分ではありません。

3) Telephony signaling labels SHOULD have a mapping with the various emergency related labels/markings used in other telephony based networks, such as the Public Switched Telephone Network (PSTN). This ensures that a telephone call placed over a hybrid infrastructure (traditional PSTN over some portion(s) of the path, Internet telephony over some other portion(s) of the path) can carry the labels end-to-end with appropriate translation at PSTN/Internet boundaries. Absence of a mapping means that the signaling reverts to a default service (presumably one attributed to the general public).

3)テレフォニーシグナルラベルは、公衆交換電話網(PSTN)のような、他の電話ベースのネットワークで使用される様々な緊急関連ラベル/マーキングのマッピングを持っているべきです。これは、ハイブリッドインフラ(パスの一部(単数または複数)上の伝統的なPSTN、経路のいくつかの他の部分(単数または複数)上のインターネット電話)上に配置された電話コールがで適切な翻訳をラベルは、エンドツーエンド運ぶことができることを確実にしますPSTN /インターネット境界。マッピングの不在は、シグナリングは、デフォルトのサービス(一般公衆に起因すると思われる1)に戻りますことを意味します。

4) Application layer IP telephony capabilities MUST NOT preclude the ability to do application layer accounting.

4)アプリケーション層のIPテレフォニー機能は、アプリケーション層の会計処理を行う能力を排除してはなりません。

Accounting is a useful feature in support of billing and tracking down abuse of service. If specific solutions or protocols in support of ETS require accounting, then this will be articulated in future document(s).

会計は、課金のサポートとサービスの乱用を追跡するのに便利な機能です。 ETSをサポートする特定のソリューションやプロトコルが会計を必要とする場合、これは将来のドキュメント(複数可)に連接されます。

5) Application layer mechanisms in gateways and stateful proxies that are specifically in place to recognize ETS type labels MUST be able to support "best available" service (this will probably be realized as better than best effort). These labels MAY exist in the application layer headers of data (i.e., bearer) traffic or signaling traffic used for call completion.

5)アプリケーション層ゲートウェイでのメカニズムとETSタイプラベルを認識するための場所で特異的にあるステートフルプロキシは、「利用可能な最善」のサービス(これはおそらく最善の努力よりも良いとして実現される)をサポートすることができなければなりません。これらのラベルは、データ(すなわち、ベアラ)トラフィックまたは呼完了のために使用されるシグナリングトラフィックのアプリケーション層ヘッダで存在することができます。

The support for best available service SHOULD focus on probability of forwarding packets. Probability MAY reach 100% depending on the local policy associated with the label. Local policy MUST also be used to determine if better than best effort is to be applied to a specific label (or related set of labels).

利用可能な最善のサービスのサポートは、パケット転送の確率に焦点を当てるべきです。確率は、ラベルに関連付けられたローカルポリシーに応じて、100%に達する可能性があります。ローカルポリシーは、ベストエフォートよりも良いが、特定のラベル(またはラベルの関連セット)に適用されるかどうかを判断するために使用しなければなりません。

Additional comments on this topic are presented below in item 2 of section 4.

このトピックに関する追加のコメントはセクション4の項目2に、以下に提示されています。

The above paragraphs MUST be taken in their entirety. The ability to support best available service does not mean that the application layer mechanism is expected to be activated. Further, we do not define the means by which best available service is realized. Application layer mechanisms that do not recognize ETS type labels are not subject to this requirement.

上記の段落では、その全体を払わなければなりません。利用可能な最善のサービスをサポートする機能は、アプリケーション層機構を活性化することが期待されていることを意味するものではありません。さらに、我々は最高の利用可能なサービスが実現される手段を定義していません。 ETSタイプラベルを認識しないアプリケーション層メカニズムはこの要件の対象ではありません。

4. Issues
4.問題

This section presents issues that arise in considering solutions for the telephony requirements that have been defined for ETS. This section does not specify solutions, nor is it to be confused with requirements. Subsequent documents that articulate a more specific set of requirements for a particular service may make a statement about the following issues.

このセクションでは、ETSのために定義されているテレフォニー要件のためのソリューションを検討する中で発生する問題を提示しています。このセクションでは、ソリューションを指定しません。また、要件と混同されることです。特定のサービスのための要件のより具体的なセットを明確以降の文書は、次の問題について声明を発表することがあります。

1) Alternate paths

1)代替パス

Experience with The Government Emergency Telecommunications Service (GETS) over the PSTN has shown the utility of alternate paths to a destination to help facilitate emergency-related communications. From the perspective of the Internet, this utility may be difficult to achieve and have a more limited benefit. Unlike the PSTN, which creates a fixed path during call setup phase, the Internet uses dynamic routing for IP packets. This dynamic routing capability automatically causes IP packets to travel the best current path. The Internet network infrastructure does not have the concept of a "call" or the concept of "call setup", though IP telephony applications might have application layer awareness of calls or the call setup concept.

PSTN上政府緊急通信サービス(GETS)の経験は、緊急関連の通信を容易にするために役立つ目的地への代替パスの有用性を示しました。インターネットの観点から、このユーティリティは達成し、より限定された利点を持ってすることは困難です。呼設定フェーズ中に固定されたパスを作成し、PSTNとは異なり、インターネットは、IPパケットの動的ルーティングを使用します。この動的なルーティング機能は、自動的に現在の最良のパスを移動するIPパケットが発生します。 IPテレフォニーアプリケーションが発信や通話セットアップコンセプトのアプリケーション層の意識を持っているかもしれませんが、インターネットのネットワークインフラストラクチャは、「コール」または「コール・セットアップ」の概念の概念がありません。

2) Application of Best Available Service

ベストサービスの2)アプリケーション

In item 5 of section 3 above, we discuss the requirement of supporting best available service. We note that in this document, the scope of that support is constrained to the application layer and flows that traverse that layer. This may involve direct support for the flow containing the ETS type label, or may involve indirect support (e.g., ETS labels in signaling messages that cause an effect on corresponding data or bearer flows).

上記のセクション3の項目5で、我々は最高の利用可能なサービスを支援する必要性を議論します。私たちは、この文書では、そのサポートの範囲は、その層を通過するアプリケーション層と流れに拘束されることに注意してください。これはETSタイプラベルを含む流れのための直接サポートを含んでいてもよい、または間接的なサポートを含んでいてもよい(例えば、データまたはベアラ・フローに対応する上で効果を引き起こすシグナリングメッセージにおけるETSラベル)。

It is critical to understand that how the support for best available service can be realized is outside the scope of this document. In addition, the perceived effectiveness of a given approach or implementation is also outside the scope of this document.

どのように利用可能な最善のサービスのサポートを実現することができることは、この文書の範囲外であることを理解することが重要です。加えて、所与のアプローチまたは実装の知覚される効果は、この文書の範囲外でもあります。

5. Security
5.セキュリティ

Only authorized users or operators SHOULD be able to create non-ordinary Labels (i.e., labels that may alter the default best effort service). Labels SHOULD be associated with mechanisms to provide strong end-to-end integrity during their transmission through the telephony systems. Finally, in cases where labels are expected to be acted upon by operators, these operators SHOULD have the capability of authenticating the label on a received message or transmission in order to prevent theft of service and reduce risk of denial of service (e.g., by unauthorized users consuming any limited resources).

許可されたユーザまたはオペレータのみが非通常のラベル(デフォルトのベストエフォート型サービスを変更することができる、すなわち、ラベル)を作成することができる必要があり。ラベルは、電話システムを介して自分の送信時に強力なエンドツーエンドの整合性を提供するためのメカニズムに関連付けられている必要があり。最後に、ラベルは、オペレータによって作用することが期待されている場合には、これらの事業者は、サービスの盗難を防止し、サービス拒否(例えば、不正によってのリスクを軽減するために、受信したメッセージや送信のラベルを認証する機能を持つべきである(SHOULD)すべての限られた資源を消費するユーザー)。

Security is also discussed in the general requirements of [3], which applies to section 3 above.

セキュリティは、上記のセクション3に適用される[3]の一般的な要件に記載されています。

6. References
6.参照
6.1. Normative Reference
6.1. 引用規格

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

6.2. Informative References
6.2. 参考文献

[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[2]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。

[3] Carlberg, K. and R. Atkinson, "General System Requirements for Emergency Telecommunications Service", RFC 3689, February 2004.

[3]カールバーグ氏、K.とR.アトキンソン、 "緊急通信サービスのための一般的なシステム要件"、RFC 3689、2004年2月。

[4] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.

[4] Schulzrinneと、H.、RFC 3487 "セッション開始プロトコル(SIP)のためのリソースプライオリティメカニズムのための要件"、2003年2月を。

[5] ANSI, "Signaling System No. 7(SS7): High Probability of Completion (HPC) Network Capability", ANSI T1.631, 1993.

[5] ANSI、 "信号システム第7号(SS7):完了(HPC)ネットワーク能力の高い確率"、ANSI T1.631、1993。

7. Authors' Addresses
7.著者のアドレス

Ken Carlberg University College London Department of Computer Science Gower Street London, WC1E 6BT United Kingdom

コンピュータサイエンスガウアーストリートロンドン、WC1E 6BTイギリスのケン・カールバーグロンドン大学学部

EMail: k.carlberg@cs.ucl.ac.uk

メールアドレス:k.carlberg@cs.ucl.ac.uk

Ran Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA

アトキンソンエクストリームネットワークを走った3585モンローストリートサンタクララ、CA 95051 USA

EMail: rja@extremenetworks.com

メールアドレス:rja@extremenetworks.com

8. Full Copyright Statement
8.完全な著作権声明

Copyright (C) The Internet Society (2004). All Rights Reserved.

著作権(C)インターネット協会(2004)。全著作権所有。

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 assignees.

上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。