Internet Engineering Task Force Ken Carlberg
INTERNET DRAFT G11
April, 2007 Piers O'Hanlon
UCL
TRIP Attribute for Resource Priority
<draft-carlberg-trip-attribute-rp-01.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines a new attribute for the 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 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
tupple defined for the SIP resource Priority field.
Carlberg & O'Hanlon Expires Oct, 2007 [Page 1]
Internet Drafts Resource Priority Attribute April, 2007
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, negotiate capabilities, and specify attributes about
these gateways.
The TRIP protocol is modeled after BGP-4 [rfc1771] 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 an
Internet Telephony Administrative Domains (ITAD). A more extensive
framework discussion on TRIP can be found in [rfc2871].
This document defines a new attribute to be registered with IANA.
The purpose of this new attribute, and the rationale behind its
specification, is explained in the following sections.
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 System (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 code point in an ISDN User Part (ISUP)
Initial Address Message (IAM) for 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 code-points 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] provides additional information on
ETS and its requirements from the perspective of the Internet
Carlberg & O'Hanlon Expires Oct, 2007 [Page 2]
Internet Drafts Resource Priority Attribute April, 2007
Emergency Preparedness (IEPREP) working group of the IETF.
3. SIP Resource-Priority Effort
The initial discussions in the IEPREP 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 system, 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
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 &
Value tokens its 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., code points) 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 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
Carlberg & O'Hanlon Expires Oct, 2007 [Page 3]
Internet Drafts Resource Priority Attribute April, 2007
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.
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, whose field is shown in Figure 3 above, are set to
the following:
Conditional Mandatory: False
Required Flags: Not Well-Known, Independent Transitive
Potential Flags: None
TRIP Type Code: TBD (proposed to be 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 are 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], and is an alphanumeric value
as shown below:
namespace = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+"
/ "`" / "'" / "~" )
Since NameSpaces are arbitrary in length, each tuple consists of a
Carlberg & O'Hanlon Expires Oct, 2007 [Page 4]
Internet Drafts Resource Priority Attribute April, 2007
Length value with a NameSpace value as shown in Figure 4 below.
There is no padding between tuples.
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:
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
Carlberg & O'Hanlon Expires Oct, 2007 [Page 5]
Internet Drafts Resource Priority Attribute April, 2007
ResourcePriority attribute is a matter of local administrative
policy.
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
---- ----------------
TBD (suggest 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
[rfc2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, IETF, November 1997.
[rfc2871] Rosenberg, J. and H. Schulzrinne, "A Framework for
Telephony Routing over IP", RFC 2871, IETF, June 2000.
[rfc3219] Rosenberg, J. et. al., "Telephony Routing over IP (TRIP)",
RFC 3219, IETF, January 2002.
[rfc4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, IETF, Feb 2006.
Carlberg & O'Hanlon Expires Oct, 2007 [Page 6]
Internet Drafts Resource Priority Attribute April, 2007
8.2 Informative References
[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.
[rfc1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, IETF, March 1995.
[rfc3265] Roach, A., "Session Initiation Protocol (SIP) - Specific
Event Notification", RFC 3265, IETF, June 2002.
[rfc3487] Schulzrinne, H., "Requirements for Resource Priority
Mechanisms for the Session Initiation Protocol (SIP)",
RFC 3487, IETF, February 2003.
[rfc3667] Bradner, S., "IETF Rights in Contributions", RFC 3667,
IETF, February 2004.
[rfc3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", RFC 3668, IETF, February 2004.
[rfc3689] Carlberg, K. and R. Atkinson, "General Requirements for
Emergency Telecommunications Service (ETS)", RFC 3689,
IETF, February 2004.
[rfc3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
for Emergency Telecommunications Service (ETS)",
RFC 3690, IETF, February 2004.
Author's Addresses
Ken Carlberg Piers O'Hanlon
G11 University College London
123a Versailles Circle Gower Street
Baltimore, MD London
USA UK
carlberg@g11.org.uk p.ohanlon@cs.ucl.ac.uk
Carlberg & O'Hanlon Expires Oct, 2007 [Page 7]
Internet Drafts Resource Priority Attribute April, 2007
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The The IETF Trust (2007). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Carlberg & O'Hanlon Expires Oct, 2007 [Page 8]
