💾 Archived View for gemini.bortzmeyer.org › rfc-mirror › rfc8101.txt captured on 2022-06-04 at 00:16:40.

View Raw

More Information

⬅️ Previous capture (2021-11-30)

-=-=-=-=-=-=-







Internet Engineering Task Force (IETF)                       C. Holmberg
Request for Comments: 8101                                      J. Axell
Category: Informational                                         Ericsson
ISSN: 2070-1721                                               March 2017


       IANA Registration of New Session Initiation Protocol (SIP)
 Resource-Priority Namespace for Mission Critical Push To Talk Service

Abstract

   This document creates additional Session Initiation Protocol (SIP)
   Resource-Priority namespaces to meet the requirements of the
   3GPP-defined Mission Critical Push To Talk (MCPTT) and places these
   namespaces in the corresponding IANA registry.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc8101.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Holmberg & Axell              Informational                     [Page 1]

RFC 8101                   MCPTT R-P Namespace                March 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  New SIP Resource-Priority Namespaces Created  . . . . . . . .   3
     3.1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  The MCPTT Namespaces  . . . . . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The Third Generation Partnership Project (3GPP) has defined a Mission
   Critical Push To Talk (MCPTT) over LTE service [TS.3GPP.22.179].  The
   MCPTT service supports an enhanced Push To Talk (PTT) service that is
   suitable for mission critical scenarios and is based upon 3GPP
   Evolved Packet System (EPS) services.  The requirements for the MCPTT
   service defined within 3GPP can also form the basis for other PTT
   services.

   The MCPTT service is intended to support communication between
   several users (a group call), where each user can gain permission to
   talk in an arbitrated manner.  However, the MCPTT service also
   supports private calls between pairs of users.

   MCPTT is primarily targeted to provide a professional PTT service to,
   e.g., public safety, transport companies, utilities, and industrial
   and nuclear plants.  In addition to this, a commercial PTT service
   for non-professional use (e.g., groups of people on holiday) may be
   delivered through an MCPTT system.  Based on their operational model,
   the performance and MCPTT features in use vary per user organization,
   where functionality that is more mission-critical-specific (e.g.,
   Imminent Peril Call) might not be available to commercial customers.

   The MCPTT service provides its users with different priorities for
   the access to network resources in order to provide means to
   prioritize between calls when resources are scarce.  Among other
   things, these priorities take into account the priority and role of
   the caller, the priority and type of the group, and the situation in
   which the call is made.

   The SIP-level call control procedures using these namespaces are
   specified in [TS.3GPP.24.379].  The namespaces defined here will
   support a wide range of queuing options.  The namespaces correspond
   to what can be supported over the 3GPP Rx interface, defined in



Holmberg & Axell              Informational                     [Page 2]

RFC 8101                   MCPTT R-P Namespace                March 2017


   [TS.3GPP.29.214].  The usage of the namespaces can be tailored to the
   needs of the operator.  The mechanism to do this is to configure
   which values a specific user is allowed to use.  This configuration
   is specified in [TS.3GPP.24.384].

   High-priority calls (when the life of either a public safety worker
   or anyone else is in danger) need to be set up immediately; thus,
   they require preemption.  Other calls may be less sensitive in call
   setup time but have a high priority once established.  For these
   calls, a queueing mechanism is more appropriate.  The MCPTT data
   transfer service currently under development can benefit from a
   queueing mechanism.  Another example is video-only calls that are not
   critical in call setup time but where keeping the call is important.

   This document creates additional SIP Resource-Priority namespaces to
   meet the requirements of the 3GPP-defined MCPTT and places these
   namespaces in the IANA registry.

2.  Applicability

   This document defines namespaces applicable for MCPTT services
   defined by 3GPP that use the network services of a 3GPP-defined LTE
   network.  The use of this namespace outside such networks is
   undefined.

3.  New SIP Resource-Priority Namespaces Created

3.1.  Introduction

   This document introduces the following MCPTT namespaces: mcpttp and
   mcpttq.  The names of which come from the 3GPP-defined MCPTT service.

3.2.  The MCPTT Namespaces

   The mcpttp namespace uses the priority levels listed below from
   lowest to highest priority.

      mcpttp.0 (lowest priority)

      mcpttp.1

      mcpttp.2

      mcpttp.3

      mcpttp.4

      mcpttp.5



Holmberg & Axell              Informational                     [Page 3]

RFC 8101                   MCPTT R-P Namespace                March 2017


      mcpttp.6

      mcpttp.7

      mcpttp.8

      mcpttp.9

      mcpttp.10

      mcpttp.11

      mcpttp.12

      mcpttp.13

      mcpttp.14

      mcpttp.15 (highest priority)

   The Namespace Numerical Value is 46.

   Intended algorithm for mcpttp is preemption.

   New Warning code: No.

   New SIP response code: No.

   The mcpttq namespace uses the priority levels listed below from
   lowest to highest priority.

      mcpttq.0 (lowest priority)

      mcpttq.1

      mcpttq.2

      mcpttq.3

      mcpttq.4

      mcpttq.5

      mcpttq.6

      mcpttq.7

      mcpttq.8



Holmberg & Axell              Informational                     [Page 4]

RFC 8101                   MCPTT R-P Namespace                March 2017


      mcpttq.9

      mcpttq.10

      mcpttq.11

      mcpttq.12

      mcpttq.13

      mcpttq.14

      mcpttq.15 (highest priority)

   The Namespace Numerical Value is 47.

   Intended algorithm for mcpttq is queuing.

   New Warning code: No.

   New SIP response code: No.

4.  Security Considerations

   This document does not have any impact on the security of the SIP
   MCPTT protocol.  Its purpose is purely administrative in nature.

5.  IANA Considerations

   Abiding by the rules established within [RFC4412] and [RFC7134], this
   is an Informational RFC creating two new namespaces, their associated
   priority-values, and intended algorithms.

6.  Normative References

   [RFC4412]  Schulzrinne, H. and J. Polk, "Communications Resource
              Priority for the Session Initiation Protocol (SIP)",
              RFC 4412, DOI 10.17487/RFC4412, February 2006,
              <http://www.rfc-editor.org/info/rfc4412>.

   [RFC7134]  Rosen, B., "The Management Policy of the Resource Priority
              Header (RPH) Registry Changed to "IETF Review"", RFC 7134,
              DOI 10.17487/RFC7134, March 2014,
              <http://www.rfc-editor.org/info/rfc7134>.







Holmberg & Axell              Informational                     [Page 5]

RFC 8101                   MCPTT R-P Namespace                March 2017


   [TS.3GPP.22.179]
              3GPP, "3rd Generation Partnership Project; Technical
              Specification Group Services and System Aspects; Mission
              Critical Push To Talk (MCPTT) over LTE; Stage 1", 3GPP
              TS 22.179 13.3.0, December 2015.

   [TS.3GPP.29.214]
              3GPP, "3rd Generation Partnership Project; Technical
              Specification Group Core Network and Terminals; Policy and
              Charging Control over Rx reference point;", 3GPP TS 29.214
              13.7.0, September 2016.

   [TS.3GPP.24.379]
              3GPP, "3rd Generation Partnership Project; Technical
              Specification Group Core Network and Terminals; Mission
              Critical Push To Talk (MCPTT) call control; Protocol
              specification;", 3GPP TS 24.379 13.2.0, September 2016.

   [TS.3GPP.24.384]
              3GPP, "3rd Generation Partnership Project; Technical
              Specification Group Core Network and Terminals; Mission
              Critical Push To Talk (MCPTT) configuration management;
              Protocol specification", 3GPP TS 24.384 13.2.0, September
              2016.

Acknowledgments

   The authors would like to thank Bob Fredericks, Baruh Hason, Mary
   Barnes, and Keith Drage for comments and discussions.

Authors' Addresses

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com


   Joergen Axell
   Ericsson
   Groenlandsgatan 31
   Stockholm  16480
   Sweden

   Email: jorgen.axell@ericsson.com



Holmberg & Axell              Informational                     [Page 6]