doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc3690.txt b/doc/rfc/rfc3690.txt
new file mode 100644
index 0000000..694fc90
--- /dev/null
+++ b/doc/rfc/rfc3690.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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.
+
+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.
+
+1.  Introduction
+
+   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.
+
+   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].
+
+
+
+
+
+
+Carlberg & Atkinson          Informational                      [Page 1]
+
+RFC 3690               ETS Telephony Requirements          February 2004
+
+
+1.1.  Problem
+
+   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.
+
+2.  Scope
+
+   [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.
+
+   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.
+
+2.1.  Out of Scope
+
+   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.
+
+   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.
+
+
+
+
+
+
+Carlberg & Atkinson          Informational                      [Page 2]
+
+RFC 3690               ETS Telephony Requirements          February 2004
+
+
+3.  IP Telephony Requirements
+
+   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.
+
+   1) Telephony signaling applications used with Internet-based
+      telephony MUST be able to carry labels.
+
+   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.
+
+   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).
+
+   4) Application layer IP telephony capabilities MUST NOT preclude the
+      ability to do application layer accounting.
+
+      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).
+
+   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.
+
+      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).
+
+
+
+
+Carlberg & Atkinson          Informational                      [Page 3]
+
+RFC 3690               ETS Telephony Requirements          February 2004
+
+
+      Additional comments on this topic are presented below in item 2 of
+      section 4.
+
+      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.
+
+4.  Issues
+
+   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.
+
+   1) Alternate paths
+
+      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.
+
+   2) Application of Best Available Service
+
+      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).
+
+
+
+
+
+
+
+
+Carlberg & Atkinson          Informational                      [Page 4]
+
+RFC 3690               ETS Telephony Requirements          February 2004
+
+
+      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
+
+   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).
+
+   Security is also discussed in the general requirements of [3], which
+   applies to section 3 above.
+
+6.  References
+
+6.1.  Normative Reference
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+6.2.  Informative References
+
+   [2]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [3]  Carlberg, K. and R. Atkinson, "General System Requirements for
+        Emergency Telecommunications Service", RFC 3689, February 2004.
+
+   [4]  Schulzrinne, H., "Requirements for Resource Priority Mechanisms
+        for the Session Initiation Protocol (SIP)", RFC 3487, February
+        2003.
+
+   [5]  ANSI, "Signaling System No. 7(SS7): High Probability of
+        Completion (HPC) Network Capability", ANSI T1.631, 1993.
+
+
+
+
+
+
+
+
+Carlberg & Atkinson          Informational                      [Page 5]
+
+RFC 3690               ETS Telephony Requirements          February 2004
+
+
+7.  Authors' Addresses
+
+   Ken Carlberg
+   University College London
+   Department of Computer Science
+   Gower Street
+   London, WC1E 6BT
+   United Kingdom
+
+   EMail: k.carlberg@cs.ucl.ac.uk
+
+
+   Ran Atkinson
+   Extreme Networks
+   3585 Monroe Street
+   Santa Clara, CA
+   95051  USA
+
+   EMail: rja@extremenetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carlberg & Atkinson          Informational                      [Page 6]
+
+RFC 3690               ETS Telephony Requirements          February 2004
+
+
+8.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carlberg & Atkinson          Informational                      [Page 7]
+