IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces
Forty new SIP Resource-Priority namespaces, registered with IANA for the US Defense Information Systems Agency.
Polk, J., "IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces", RFC 5478, DOI 10.17487/RFC5478, March 2009, <https://www.rfc-editor.org/info/rfc5478>.
@misc{rfc5478,
series = {Request for Comments},
number = 5478,
howpublished = {RFC 5478},
publisher = {RFC Editor},
doi = {10.17487/RFC5478},
url = {https://www.rfc-editor.org/info/rfc5478},
author = {J. Polk},
title = {{IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces}},
pagetotal = 6,
year = 2009,
month = mar,
} RFC text
Contents
Network Working Group J. Polk
Request for Comments: 5478 Cisco Systems
Category: Standards Track March 2009
IANA Registration of New Session Initiation Protocol (SIP)
Resource-Priority Namespaces
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.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract
This document creates additional Session Initiation Protocol (SIP)
Resource-Priority namespaces to meet the requirements of the US
Defense Information Systems Agency, and places these namespaces in
the IANA registry.
Table of Contents
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. New SIP Resource-Priority Namespaces Created ....................3
3. IANA Considerations .............................................4
3.1. IANA Resource-Priority Namespace Registration ..............4
3.2. IANA Priority-Value Registrations ..........................6
4. Security Considerations .........................................6
5. Acknowledgments .................................................6
6. Normative References ............................................6
1. Introduction
The US Defense Information Systems Agency (DISA) is rolling out their
Session Initiation Protocol (SIP) based architecture at this time.
This network will require more Resource-Priority namespaces than were
defined, and IANA registered, in RFC 4412 [RFC4412]. The purpose of
this document is to define these additional namespaces. Each will be
preemptive in nature, as defined in RFC 4412, and will have the same
10 priority-values.
DISA has a requirement to be able to assign different Resource-
Priority namespaces to differing groups of differing sizes throughout
their networks. Examples of this may be
- namespaces as large as each branch of service (Army, Navy, Air
Force, Marines, Coast Guard)
- namespaces for some departments within the government (for example,
Homeland Security)
- namespaces that are temporary assignments to individual units of
varying sizes (from battle groups to patrol groups or platoons)
These temporary assignments might be combinations of smaller units
involving several branches of service operating as one unit (say, one
task force, which is separate than the branch of service), or a
single commando unit requiring special treatment for a short period
of time, making it appear separate from the branch of service they
are from.
Providing DISA with a pool of namespaces for fine-grained
assignment(s) allows them the flexibility they need for their mission
requirements. One can imagine due to their sheer size and separation
of purpose, they can easily utilize a significant number of
namespaces within their networks. This is the reason for the
assignment of so many new namespaces, which seems to deviate from
guidance in RFC 4412 to have as few namespaces as possible.
This document makes no changes to SIP, it just adds IANA-registered
namespaces for SIP's use within the Resource-Priority header
framework.
1.1. Conventions Used in This Document
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. New SIP Resource-Priority Namespaces Created
The following 40 SIP namespaces are created by this document:
dsn-000000 drsn-000000 rts-000000 crts-000000
dsn-000001 drsn-000001 rts-000001 crts-000001
dsn-000002 drsn-000002 rts-000002 crts-000002
dsn-000003 drsn-000003 rts-000003 crts-000003
dsn-000004 drsn-000004 rts-000004 crts-000004
dsn-000005 drsn-000005 rts-000005 crts-000005
dsn-000006 drsn-000006 rts-000006 crts-000006
dsn-000007 drsn-000007 rts-000007 crts-000007
dsn-000008 drsn-000008 rts-000008 crts-000008
dsn-000009 drsn-000009 rts-000009 crts-000009
Each namespace listed above is wholly different. However, according
to the rules within Section 8 of RFC 4412, one or more sets can be
treated as if they are the same when they are configured as an
aggregated grouping of namespaces.
These aggregates of two or more namespaces, that are to be considered
equivalent during treatment, can be a set of any IANA registered
namespaces, not just adjacent (i.e., consecutive) namespaces.
Each namespace listed above will have the same 10 priority levels:
.0 (lowest priority)
.1
.2
.3
.4
.5
.6
.7
.8
.9 (highest priority)
According to the rules established in RFC 4412 [RFC4412], priority-
values have a relative order for preferential treatment, unless one
or more consecutive groups of priority-values are to be considered
equivalent (i.e., first-received, first treated).
The dash character ('-') is just like any other ASCII character
within a namespace, and is not to be considered a delimiter in any
official way within any namespace here. Other namespace definitions
in the future could change this.
As stated in Section 9 of RFC 4412 [RFC4412] an IANA-registered
namespace SHOULD NOT change the number, and MUST NOT change the
relative priority order, of its assigned priority-values.
3. IANA Considerations
Abiding by the rules established within RFC 4412 [RFC4412], this is a
Standards-Track document registering new namespaces, their associated
priority-values, and intended algorithms.
3.1. IANA Resource-Priority Namespace Registration
Within the "Resource-Priority Namespaces" registry in the sip-
parameters section of IANA, the following table lists the new
namespaces registered by this document.
Intended New warn- New resp.
Namespace Levels Algorithm code code Reference
---------- ------ ------------ --------- --------- ---------
dsn-000000 10 preemption no no [RFC5478]
dsn-000001 10 preemption no no [RFC5478]
dsn-000002 10 preemption no no [RFC5478]
dsn-000003 10 preemption no no [RFC5478]
dsn-000004 10 preemption no no [RFC5478]
dsn-000005 10 preemption no no [RFC5478]
dsn-000006 10 preemption no no [RFC5478]
dsn-000007 10 preemption no no [RFC5478]
dsn-000008 10 preemption no no [RFC5478]
dsn-000009 10 preemption no no [RFC5478]
drsn-000000 10 preemption no no [RFC5478]
drsn-000001 10 preemption no no [RFC5478]
drsn-000002 10 preemption no no [RFC5478]
drsn-000003 10 preemption no no [RFC5478]
drsn-000004 10 preemption no no [RFC5478]
drsn-000005 10 preemption no no [RFC5478]
drsn-000006 10 preemption no no [RFC5478]
drsn-000007 10 preemption no no [RFC5478]
drsn-000008 10 preemption no no [RFC5478]
drsn-000009 10 preemption no no [RFC5478]
rts-000000 10 preemption no no [RFC5478]
rts-000001 10 preemption no no [RFC5478]
rts-000002 10 preemption no no [RFC5478]
rts-000003 10 preemption no no [RFC5478]
rts-000004 10 preemption no no [RFC5478]
rts-000005 10 preemption no no [RFC5478]
rts-000006 10 preemption no no [RFC5478]
rts-000007 10 preemption no no [RFC5478]
rts-000008 10 preemption no no [RFC5478]
rts-000009 10 preemption no no [RFC5478]
crts-000000 10 preemption no no [RFC5478]
crts-000001 10 preemption no no [RFC5478]
crts-000002 10 preemption no no [RFC5478]
crts-000003 10 preemption no no [RFC5478]
crts-000004 10 preemption no no [RFC5478]
crts-000005 10 preemption no no [RFC5478]
crts-000006 10 preemption no no [RFC5478]
crts-000007 10 preemption no no [RFC5478]
crts-000008 10 preemption no no [RFC5478]
crts-000009 10 preemption no no [RFC5478]
3.2. IANA Priority-Value Registrations
Within the "Resource-Priority Priority-values" registry in the
sip-parameters section of IANA, the list of priority-values for each
of the 40 newly created namespaces from Section 3.1 of this
document, prioritized least to greatest, is registered by the
following (replicated similar to the following format):
Namespace: dsn-000000
Reference: RFC5478 (this document)
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
4. Security Considerations
This document has the same Security Considerations as RFC 4412.
5. Acknowledgments
To Jeff Hewett for his helpful guidance in this effort. Thanks to
Janet Gunn, John Rosenberg, Joel Halpern, Michael Giniger, Henning
Schulzrinne, Keith Drage, and Suresh Krishnan for their comments.
6. Normative References
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)", RFC
4412, February 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
James Polk
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
AI ELI5
On this page
§1Why More Namespaces Were Needed
The US Defense Information Systems Agency (DISA) is rolling out a SIP-based architecture. That network needs more Resource-Priority namespaces than RFC 4412 defined and IANA registered. Each new namespace is preemptive in nature, as defined in RFC 4412, and has the same 10 priority-values.
DISA wants to assign different namespaces to groups of different sizes. The RFC gives examples: namespaces as large as each branch of service, namespaces for departments such as Homeland Security, and temporary namespaces for individual units, from battle groups to platoons.
The RFC admits that so many new namespaces seems to deviate from the guidance in RFC 4412 to have as few namespaces as possible. It justifies this by DISA's size and the separation of its purposes. The document makes no changes to SIP; it only adds IANA-registered namespaces for use within the Resource-Priority header framework.
A big organization needs many separate sets of priority labels, so a small team can have its own set for a short job. This note creates a big batch of them.
§2The 40 New Namespaces
The document creates 40 namespaces in four families of ten: dsn-000000 to dsn-000009, drsn-000000 to drsn-000009, rts-000000 to rts-000009, and crts-000000 to crts-000009.
Each namespace is wholly different from the others. However, under the rules in Section 8 of RFC 4412, one or more sets can be treated as the same when configured as an aggregated grouping. An aggregate of two or more namespaces can be any set of IANA-registered namespaces, not just consecutive ones.
The dash is treated like any other ASCII character in a namespace and is not a delimiter. The RFC notes that other namespace definitions in the future could change this.
There are four families of ten, like four colors of ten numbered lockers. Locker groups can be treated as one big locker if needed, even if their numbers are not next to each other.
- dsndsn-000000 to dsn-000009
- drsndrsn-000000 to drsn-000009
- rtsrts-000000 to rts-000009
- crtscrts-000000 to crts-000009
§3Priority Levels
Every new namespace has the same 10 priority levels, .0 (lowest priority) through .9 (highest priority). Under the rules of RFC 4412, priority-values have a relative order for preferential treatment, unless consecutive groups of values are to be considered equivalent, in which case calls are handled first-received, first-treated.
As stated in Section 9 of RFC 4412, an IANA-registered namespace SHOULD NOT change the number, and MUST NOT change the relative priority order, of its assigned priority-values.
Each set has ten levels from 0 to 9, like a ladder. A call on a higher rung goes ahead of one on a lower rung.
§4IANA Registrations
Following the rules of RFC 4412, this Standards Track document registers the new namespaces, their priority-values and their intended algorithms. In the "Resource-Priority Namespaces" registry, each of the 40 namespaces is listed with 10 levels, the preemption algorithm, no new warning code, no new response code, and the reference RFC 5478.
In the "Resource-Priority Priority-values" registry, each namespace gets an entry listing its priority-values from least to greatest: "0", "1", "2", "3", "4", "5", "6", "7", "8", "9".
The new labels were written into the official list, each with its ten levels, so everyone agrees what they mean.
§5Security Considerations
The document states that it has the same Security Considerations as RFC 4412. It adds no further text on the subject.
Adding more labels does not change the safety rules, so the old rules still apply.