doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc5115.txt b/doc/rfc/rfc5115.txt
new file mode 100644
index 0000000..cf10522
--- /dev/null
+++ b/doc/rfc/rfc5115.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                        K. Carlberg
+Request for Comments: 5115                                           G11
+Category: Standards Track                                    P. O'Hanlon
+                                                                     UCL
+                                                            January 2008
+
+
+    Telephony Routing over IP (TRIP) Attribute for Resource Priority
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document defines a new attribute for the Telephony Routing over
+   IP (TRIP) protocol.  The attribute associates protocols/services in
+   the PSTN offering authorized prioritization during call setup that
+   are reachable through a TRIP gateway.  Current examples of
+   preferential service in the Public Switched Telephone Network (PSTN)
+   are Government Emergency Telecommunications Service (GETS) in the
+   U.S. and Government Telephone Preference Scheme (GTPS) in the U.K.
+   The proposed attribute for TRIP is based on the NameSpace.Value tuple
+   defined for the SIP Resource-Priority field.
+
+1.  Introduction
+
+   An IP telephony gateway allows nodes on an IP-based network to
+   communicate with other entities on the circuit switched telephone
+   network.  The Telephony Routing over IP (TRIP) protocol [rfc3219]
+   provides a way for nodes on the IP network to locate a suitable
+   gateway through the use of Location Servers.  TRIP is a policy-
+   driven, inter-administrative domain protocol for advertising the
+   reachability, negotiating the capabilities, and specifying the
+   attributes of these gateways.
+
+   The TRIP protocol is modeled after BGP-4 [rfc4271] and uses path-
+   vector advertisements distributed in a hop-by-hop manner (resembling
+   a Bellman-Ford routing algorithm) via Location Servers.  These
+   Location Servers are grouped in administrative clusters known as
+   Internet Telephony Administrative Domains (ITADs).  A more extensive
+   framework discussion on TRIP can be found in [rfc2871].
+
+
+
+
+
+Carlberg & O'Hanlon         Standards Track                     [Page 1]
+
+RFC 5115              Resource Priority Attribute           January 2008
+
+
+   This document defines a new attribute that has been registered with
+   IANA.  The purpose of this new attribute, and the rationale behind
+   its specification, is explained in the following sections.
+
+   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 [rfc2119].
+
+2.  Emergency Telecommunications Service
+
+   Emergency Telecommunications Service is a broad term that refers to
+   the services provided by systems used to support emergency
+   communications.  One example of these systems is the U.S. Government
+   Emergency Telecommunications Service (GETS).  This system currently
+   operates over the U.S. Public Switched Telephone Network (PSTN) as a
+   pay-per-use system by authorized personnel.  It uses the T1.631-1993
+   ANSI standard [ANSI] to signal the presence of the National Security
+   / Emergency Preparedness (NS/EP) codepoint in an ISDN User Part
+   (ISUP) Initial Address Message (IAM) for Signaling System No. 7
+   (SS7).  A key aspect of GETS is that a signaling standard in the U.S.
+   PSTN is used to convey the activation/request of the GETS service.
+
+   From a protocol perspective, other examples of priority (and which
+   can be argued as emergency/disaster related) standards are the
+   H.460.4 ITU [itu460] standard on Call Priority designation for H.323
+   calls, and the I.255.3 [itu255] ITU standard on Multi-Level
+   Precedence and Preemption Service.  The latter has been integrated
+   into private telephony systems like AUTOVON.  In both cases,
+   signaling codepoints exist to distinguish telephony calls by
+   authenticated and prioritized end-user from the normal end-user.  The
+   form of this distinction varies and is outside the scope of this
+   document.  [rfc3689] and [rfc3690] provide additional information on
+   ETS and its requirements.
+
+3.  SIP Resource-Priority Effort
+
+   The initial discussions in the IEPREP working group list, along with
+   the presentation at the Adelaide IETF [ADEL00], led to strawman
+   requirements to augment SIP to have the ability to prioritize call
+   signaling.  This effort was then advanced formally in the SIPPING
+   working group so that SIP would be able to prioritize access to
+   circuit-switched networks, end systems, and proxy resources for
+   emergency preparedness communication [rfc3487].
+
+   The requirements in [rfc3487] produced the corresponding document
+   [rfc4412] in the SIP working group, which defines a new header for
+   SIP called Resource-Priority.  This new header, which is optional, is
+
+
+
+
+Carlberg & O'Hanlon         Standards Track                     [Page 2]
+
+RFC 5115              Resource Priority Attribute           January 2008
+
+
+   divided into two parts: a NameSpace and a Value.  The NameSpace part
+   uniquely identifies a group of one or more priorities.  The Value
+   part identifies one of a set of priorities used for a SIP message.
+
+3.1.  Benefits
+
+   There are three basic benefits derived from the addition of the
+   Resource Priority header in SIP.  The first is an ability to signal
+   the priority within a SIP message to other entities in an IP network.
+   The caveat is that some entities may not recognize/support the
+   priority or namespace, but at least the ability to signal the
+   priority with respect to resources has been specified in the SIP
+   protocol.
+
+   The second benefit is that telephony-related protocol/codepoints from
+   other standards can have a corresponding mapping to SIP NameSpace and
+   Value tokens in the Resource-Priority header.  Hence, the current
+   NS/EP codepoint in ANSI standard T1.631-1993 could have a
+   corresponding NameSpace.Value token set for the IETF standards body.
+   And as a result, this mapping would facilitate the transparent
+   bridging of signals (i.e., codepoints) between standards defined by
+   various organizations -- be they private or public.
+
+   The third benefit of the Resource-Priority header, and its definition
+   of alphanumeric tokens, is that it is highly versatile.  The
+   NameSpace allows for a wide set of priorities to be defined and
+   updated, if the need arises, by simply defining a new NameSpace
+   token.  Hence, there is no reliance on a single set of priorities
+   applied for all cases.
+
+3.2  Issue
+
+   Having defined a means of signaling priority through gateways, the
+   follow-on question arises of how does one determine which gateways
+   support a given NameSpace.  The dissemination of this type of
+   information is within the scope of TRIP.  However, the current
+   specification of TRIP does not include a component that advertises
+   associations of gateways with specific NameSpaces.  To address this
+   omission, the following section defines a new TRIP attribute that
+   associates one or more NameSpaces with a gateway.
+
+
+
+
+
+
+
+
+
+
+
+Carlberg & O'Hanlon         Standards Track                     [Page 3]
+
+RFC 5115              Resource Priority Attribute           January 2008
+
+
+4.  New Attribute: ResourcePriority
+
+   This section provides details on the syntax and semantics of the
+   ResourcePriority TRIP attribute.  Its presentation reflects the form
+   of existing attributes presented in Section 5 of [rfc3219].
+
+   Attribute Flags are set to the following:
+
+      Conditional Mandatory: False
+      Required Flags: Not Well-Known, Independent Transitive
+      Potential Flags: None
+      TRIP Type Code: 12
+
+   There are no dependencies on other attributes, thus Conditional
+   Mandatory is set to "False".
+
+   Since the Resource-Priority field in SIP, with its corresponding
+   NameSpace token, is optional, the ResourcePriority attribute in TRIP
+   is also optional.  Hence, it is set to "Not Well-Known".
+
+   The Independent Transitive condition indicates that the attribute is
+   to be forwarded amongst all ITADs.  The Location Server that does not
+   recognize the attribute sets the Partial flag as well.
+
+4.1.  Syntax of ResourcePriority
+
+   The ResourcePriority attribute contains one or more NameSpace token
+   identifiers.  An initial set of identifiers is defined in [rfc4412],
+   with subsequent identifiers to be found in the IANA registry.  The
+   syntax of the ResourcePriority attribute is copied from the
+   "namespace" token syntax from [rfc4412], which in turn imported
+   "alphanum" from [rfc3261], and is an alphanumeric value as shown
+   below:
+
+   namespace = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+"
+                   / "`" / "'" / "~" )
+
+   Note that an augmented version of Backus-Naur Form is found in
+   [rfc4234].
+
+   Since NameSpaces are arbitrary in length, each tuple consists of a
+   Length value with a NameSpace value as shown in the figure below.
+   There is no padding between tuples.
+
+
+
+
+
+
+
+
+Carlberg & O'Hanlon         Standards Track                     [Page 4]
+
+RFC 5115              Resource Priority Attribute           January 2008
+
+
+    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
+   +---------------+---------------+--------------+----------------+
+   |        NameSpace Length       |   NameSpace Value (variable)  |
+   +---------------+---------------+--------------+----------------+
+
+   It is important to note that the priority (i.e., "r-priority" token
+   syntax) from [rfc4412] is NOT used in the ResourcePriority attribute.
+   This is because the objective of the attribute is to advertise the
+   NameSpace associated with a gateway and not the individual priorities
+   within that NameSpace.
+
+4.2  Additional TRIP Considerations
+
+   Section 5.12 of TRIP lists a number of considerations that should be
+   addressed when defining new attributes.  The first three
+   considerations (use of the attribute, its flags, and syntax) have
+   been discussed above in this section.  The final three considerations
+   are the following.
+
+4.2.1.  Route Origination
+
+   The ResourcePriority attribute is not well-known.  If a route has a
+   ResourcePriority attribute associated with it, the Location Server
+   (LS) MUST include that attribute in the advertisement it originates.
+
+4.2.2.  Route Aggregation
+
+   Routes with differing ResourcePriority token values MUST NOT be
+   aggregated.  Routes with the same token values in the
+   ResourcePriority attribute MAY be aggregated and the same
+   ResourcePriority attribute attached to the aggregated object.
+
+4.2.3.  Route Dissemination and Attribute Scope
+
+   An LS MUST include the ResourcePriority attribute when communicating
+   with peer LSs within its own domain.
+
+   If received from a peer LS in another domain, an LS MUST propagate
+   the ResourcePriority attribute to other LSs within its domain.
+
+   An LS MAY add the ResourcePriority attribute when propagating routing
+   objects to an LS in another domain.  The inclusion of the
+   ResourcePriority attribute is a matter of local administrative
+   policy.
+
+
+
+
+
+
+Carlberg & O'Hanlon         Standards Track                     [Page 5]
+
+RFC 5115              Resource Priority Attribute           January 2008
+
+
+5.  Security Considerations
+
+   The document defines a new attribute for the TRIP protocol and has no
+   direct security considerations applied to it.  However, the security
+   considerations for TRIP and its messages remain the same and are
+   articulated in Section 14 of [rfc3219].
+
+6.  IANA Considerations
+
+   As described in Section 4 above, one new "TRIP attribute" has been
+   defined.  Its name and code value are the following:
+
+      Code                    Attribute Name
+      ----                   ----------------
+       12                    ResourcePriority
+
+   These assignments are recorded in the following registry:
+      http://www.iana.org/assignments/trip-parameters
+
+7.  Acknowledgements
+
+   The authors appreciate review and subsequent comments from James Polk
+   and Henning Schulzrinne.
+
+8.  References
+
+8.1.  Normative References
+
+   [rfc3219] Rosenberg, J., Salama, H., and M. Squire, "Telephony
+             Routing over IP (TRIP)", RFC 3219, January 2002.
+
+   [rfc4412] Schulzrinne, H. and J. Polk, "Communications Resource
+             Priority for the Session Initiation Protocol (SIP)", RFC
+             4412, February 2006.
+
+8.2.  Informative References
+
+   [ADEL00]  IETF Proceedings (47th), SIP Working Group, Adelaide,
+             Australia, June 2000.
+
+   [ANSI]    ANSI, "Signaling System No. 7 (SS7): High Probability of
+             Completion (HPC) Network Capability", ANSI T1.631, 1993.
+
+   [itu460]  ITU, "Call Priority Designation for H.323 Calls", ITU
+             Recommendation H.460.4, November 2002.
+
+   [itu255]  ITU, "Multi-Level Precedence and Preemption Service", ITU
+             Recommendation I.255.3, July 1990.
+
+
+
+Carlberg & O'Hanlon         Standards Track                     [Page 6]
+
+RFC 5115              Resource Priority Attribute           January 2008
+
+
+   [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [rfc2871] Rosenberg, J. and H. Schulzrinne, "A Framework for
+             Telephony Routing over IP", RFC 2871, June 2000.
+
+   [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.
+
+   [rfc3487] Schulzrinne, H., "Requirements for Resource Priority
+             Mechanisms for the Session Initiation Protocol (SIP)", RFC
+             3487, February 2003.
+
+   [rfc3689] Carlberg, K. and R. Atkinson, "General Requirements for
+             Emergency Telecommunication Service (ETS)", RFC 3689,
+             February 2004.
+
+   [rfc3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
+             for Emergency Telecommunications Service (ETS)", RFC 3690,
+             February 2004.
+
+   [rfc4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
+             Specifications: ABNF", RFC 4234, October 2005.
+
+   [rfc4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border
+             Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+Authors' Addresses
+
+   Ken Carlberg
+   G11
+   123a Versailles Circle
+   Baltimore, MD
+   USA
+
+   EMail: carlberg@g11.org.uk
+
+
+   Piers O'Hanlon
+   University College London
+   Gower Street
+   London
+   UK
+
+   EMail: p.ohanlon@cs.ucl.ac.uk
+
+
+
+
+
+Carlberg & O'Hanlon         Standards Track                     [Page 7]
+
+RFC 5115              Resource Priority Attribute           January 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Carlberg & O'Hanlon         Standards Track                     [Page 8]
+