******* *************** **************
SW - Telco Switch
SG - Signaling Gateway
Figure 2
Given multiple IP domains, and the presumption that SLAs relating to
ETS traffic may exist between them, the need for something like
diff-serv grows with respect to being able to distinguish the
emergency related traffic from other types of traffic. In addition,
IP security becomes more important between domains in order to ensure
that the act of distinguishing ETS-type traffic is indeed valid for
the given source.
We conclude this section by mentioning a complementary work in
progress in providing ISUP transparency across SS7-SIP interworking
[33]. The objective of this effort is to access services in the SIP
network and yet maintain transparency of end-to-end PSTN services.
Not all services are mapped (as per the design goals of [33]), so we
anticipate the need for an additional document to specify the mapping
between new SIP labels and existing PSTN code points like NS/EP and
MLPP.
6. Security Considerations
Information on this topic is presented in sections 2 and 4.
7. Informative References
[1] Braden, R., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[2] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[3] Shenker, S., Partridge, C., and R. Guerin, "Specification of
Guaranteed Quality of Service", RFC 2212, September 1997.
[4] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[5] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001.
[6] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S.
Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
2961, April 2001.
[7] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
Weiss, "An Architecture for Differentiated Service", RFC 2475,
December 1998.
[8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P.,
Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label
Switching (MPLS) Support of Differentiated Services", RFC 3270,
May 2002.
[9] Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol
Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[10] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[11] 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.
[12] ANSI, "Signaling System No. 7(SS7), High Probability of
Completion (HPC) Network Capability", ANSI T1.631-1993, (R1999).
[13] Robust Audio Tool (RAT): http://www-
mice.cs.ucl.ac.uk/multimedia/software/rat
[14] Schulzrinne, H., "Requirements for Resource Priority Mechanisms
for the Session Initiation Protocol (SIP)", RFC 3487, February
2003.
[15] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[16] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A.
Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
2748, January 2000.
[17] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony
Routing over IP", RFC 2871, June 2000.
[18] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999.
[19] ITU, "Multi-Level Precedence and Preemption Service, ITU,
Recommendation, I.255.3, July, 1990.
[20] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
over IP (TRIP)", RFC 3219, January 2002.
[21] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
Control Protocol Version 1", RFC 3525, June 2003.
[22] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data", RFC 2198, September 1997.
[23] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[24] ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-
2000, 2000.
[25] "Description of an International Emergency Preference Scheme
(IEPS)", ITU-T Recommendation E.106 March, 2002
[26] Carlberg, K., "The Classifier Extension Header for RTP", Work In
Progress, October 2001.
[27] National Communications System: http://www.ncs.gov
[28] Bansal, R., Ravikanth, R., "Performance Measures for Voice on
IP", http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-
voiceip/, IETF Presentation: IPPM-Voiceip, Aug, 1997
[29] Hardman, V., et al, "Reliable Audio for Use over the Internet",
Proceedings, INET’95, Aug, 1995.
[30] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", RFC
2702, September 1999.
[31] "Service Class Designations for H.323 Calls", ITU Recommendation
H.460.4, November, 2002.
[32] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao,
"Overview and Principles of Internet Traffic Engineering", RFC
3272, May 2002.
[33] Vemuri, A. and J. Peterson, "Session Initiation Protocol for
Telephones (SIP-T): Context and Architectures", BCP 63, RFC
3372, September 2002.
[34] Polk, J., "Internet Emergency Preparedness (IEPREP) Telephony
Topology Terminology", RFC 3523, April 2003.
[35] Carlberg, K. and R. Atkinson, "General Requirements for
Emergency Telecommunication Service (ETS)", RFC 3689, February
2004.
[36] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for
Emergency Telecommunication Service (ETS)", RFC 3690, February
2004.
[37] Meyers, D., "Some Thoughts on CoS and Backbone Networks"
http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf IETF
Presentation: IEPREP, Dec, 2002.
[38] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001.
[39] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[40] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J.,
Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March
2002.
[41] ITU, "Gateway Control Protocol", Version 3, ITU, September,
2005.
[42] Cuervo, F., Greene, N., Huitema, C., Rayhan, A., Rosen, B., and
J. Segers, "Megaco Protocol version 0.8", RFC 2885, August 2000.
[43] Taylor, T., "Megaco Errata", RFC 2886, August 2000.
Appendix A: Government Telephone Preference Scheme (GTPS)
This framework document uses the T1.631 and ITU IEPS standard as a
target model for defining a framework for supporting authorized
emergency-related communication within the context of IP telephony.
We also use GETS as a helpful model from which to draw experience.
We take this position because of the various areas that must be
considered; from the application layer to the (inter)network layer,
in addition to policy, security (authorized access), and traffic
engineering.
The U.K. has a different type of authorized use of telephony
services, referred to as the Government Telephone Preference Scheme
(GTPS). At present, GTPS only applies to a subset of the local loop
lines within the UK. The lines are divided into Categories 1, 2, and
3. The first two categories involve authorized personnel involved in
emergencies such as natural disasters. Category 3 identifies the
general public. Priority marks, via C7/NUP, are used to bypass
call-gapping for a given Category. The authority to activate GTPS
has been extended to either a central or delegated authority.
A.1. GTPS and the Framework Document
The design of the current GTPS, with its designation of preference
based on physical static devices, precludes the need for several
aspects presented in this document. However, one component that can
have a direct correlation is the labeling capability of the proposed
Resource Priority extension to SIP. A new label mechanism for SIP
could allow a transparent interoperation between IP telephony and the
U.K. PSTN that supports GTPS.
Appendix B: Related Standards Work
The process of defining various labels to distinguish calls has been,
and continues to be, pursued in other standards groups. As mentioned
in Section 1.1.1, the ANSI T1S1 group has previously defined a label
in the SS7 ISUP Initial Address Message. This single label or value
is referred to as the National Security and Emergency Preparedness
(NS/EP) indicator and is part of the T1.631 standard. The following
subsections presents a snapshot of parallel, on-going efforts in
various standards groups.
It is important to note that the recent activity in other groups have
gravitated to defining 5 labels or levels of priority. The impact of
this approach is minimal in relation to this ETS framework document
because it simply generates a need to define a set of corresponding
labels for the resource priority header of SIP.
B.1. Study Group 16 (ITU)
Study Group 16 (SG16) of the ITU is responsible for studies relating
to multimedia service definition and multimedia systems, including
protocols and signal processing.
A contribution [31] has been accepted by this group that adds a
Priority Class parameter to the call establishment messages of H.323.
This class is further divided into two parts; one for Priority Value
and the other is a Priority Extension for indicating subclasses. It
is this former part that roughly corresponds to the labels
transported via the Resource Priority field for SIP [14].
The draft recommendation advocates defining PriorityClass information
that would be carried in the GenericData parameter in the H323-UU-PDU
or RAS messages. The GenericData parameter contains
PriorityClassGenericData. The PriorityClassInfo of the
PriorityClassGenericData contains the Priority and Priority Extension
fields.
At present, 4 levels have been defined for the Priority Value part of
the Priority Class parameter: Normal, High, Emergency-Public,
Emergency-Authorized. An additional 8-bit priority extension has
been defined to provide for subclasses of service at each priority.
The suggested ASN.1 definition of the service class is the following:
CALL-PRIORITY {itu-t(0) recommendation(0) h(8) 460 4 version1(0)}
DEFINITIONS AUTOMATIC TAGS::=
BEGIN
IMPORTS
ClearToken,
CryptoToken
FROM H235-SECURITY-MESSAGES;
CallPriorityInfo::= SEQUENCE
{
priorityValue CHOICE
{
emergencyAuthorized NULL,
emergencyPublic NULL,
high NULL,
normal NULL,
...
},
priorityExtension INTEGER (0..255) OPTIONAL,
tokens SEQUENCE OF ClearToken OPTIONAL,
cryptoTokens SEQUENCE OF CryptoToken OPTIONAL,
rejectReason CHOICE
{
priorityUnavailable NULL,
priorityUnauthorized NULL,
priorityValueUnknown NULL,
...
} OPTIONAL, -- Only used in CallPriorityConfirm
...
}
The advantage of using the GenericData parameter is that an existing
parameter is used, as opposed to defining a new parameter and causing
subsequent changes in existing H.323/H.225 documents.
Acknowledgements
The authors would like to acknowledge the helpful comments, opinions,
and clarifications of Stu Goldman, James Polk, Dennis Berg, Ran
Atkinson as well as those comments received from the IEPS and IEPREP
mailing lists. Additional thanks to Peter Walker of Oftel for
private discussions on the operation of GTPS, and Gary Thom on
clarifications of the SG16 draft contribution.
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
Ian Brown
University College London
Department of Computer Science
Gower Street
London, WC1E 6BT
United Kingdom
EMail: I.Brown@cs.ucl.ac.uk
Cory Beard
University of Missouri-Kansas City
Division of Computer Science
Electrical Engineering
5100 Rockhill Road
Kansas City, MO 64110-2499
USA
EMail: BeardC@umkc.edu
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.