RFC 5975
QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)
Pages: 64
Experimental
Experimental
Part 4 of 4 – Pages 51 to 64
6. Security Considerations
QSPEC security is directly tied to QoS NSLP security, and the QoS NSLP document [RFC5974] has a very detailed security discussion in Section 7. All the considerations detailed in Section 7 of [RFC5974] apply to QSPEC. The priority parameter raises possibilities for theft-of-service attacks because users could claim an emergency priority for their flows without real need, thereby effectively preventing serious emergency calls to get through. Several options exist for countering such attacks, for example: - only some user groups (e.g., the police) are authorized to set the emergency priority bit - any user is authorized to employ the emergency priority bit for particular destination addresses (e.g., police)7. IANA Considerations
This section defines the registries and initial codepoint assignments for the QSPEC template, in accordance with BCP 26, RFC 5226 [RFC5226]. It also defines the procedural requirements to be followed by IANA in allocating new codepoints. This specification creates the following registries with the structures as defined below: Object Types (12 bits): The following values are allocated as specified in Section 5: 0: QoS Desired 1: QoS Available 2: QoS Reserved 3: Minimum QoS
Further values are as follows:
4-63: Unassigned
64-67: Private/Experimental Use
68-4095: Reserved
(Note: 'Reserved' just means 'do not give these out'.)
The registration procedure is Specification Required.
QSPEC Version (4 bits):
The following value is allocated by this specification:
0: Version 0 QSPEC
Further values are as follows:
1-15: Unassigned
The registration procedure is Specification Required. (A
specification is required to depreciate, delete, or modify QSPEC
versions.)
QSPEC Type (5 bits):
The following values are allocated by this specification:
0: Default
1: Y.1541-QOSM [RFC5976]
2: RMD-QOSM [RFC5977]
Further values are as follows:
3-12: Unassigned
13-16: Local/Experimental Use
17-31: Reserved
The registration procedure is Specification Required.
QSPEC Procedure (8 bits):
The QSPEC Procedure object consists of the Message Sequence parameter
(4 bits) and the Object Combination parameter (4 bits), as discussed
in Section 4.3. Message Sequences 0 (Two-Way Transactions), 1
(Three-Way Transactions), and 2 (Resource Queries) are explained in
Sections 4.3.1, 4.3.2, and 4.3.3, respectively. Tables 1, 2, and 3
in Section 4.3 assign the Object Combination Number to Message
Sequences 0, 1, and 2, respectively. The values assigned by this
specification for the Message Sequence parameter and the Object
Combination parameter are summarized here:
MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED
SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
-------------------------------------------------------------------
0 |0 |N/A |QoS Desired |QoS Reserved
| | | |
0 |1 |N/A |QoS Desired |QoS Reserved
| |N/A |QoS Available |QoS Available
| | | |
0 |2 |N/A |QoS Desired |QoS Reserved
| |N/A |QoS Available |QoS Available
| |N/A |Minimum QoS |
| | | |
1 |0 |QoS Desired |QoS Desired |QoS Reserved
| | | |
1 |1 |QoS Desired |QoS Desired |QoS Reserved
| |(Minimum QoS) |QoS Available |QoS Available
| | |(Minimum QoS) |
| | | |
1 |2 |QoS Desired |QoS Desired |QoS Reserved
| |QoS Available |QoS Available |
| | | |
2 |0 |QoS Available |N/A |QoS Available
Further values of the Message Sequence parameter (4 bits) are as
follows:
3-15: Unassigned
Further values of the Object Combination parameter (4 bits) are as
follows:
Message | Object
Sequence | Combination
---------------------------
0 | 3-15: Unassigned
1 | 3-15: Unassigned
2 | 1-15: Unassigned
3-15 | 0-15: Unassigned
The registration procedure is Specification Required. (A
specification is required to depreciate, delete, or modify QSPEC
Procedures.)
QoS Model Error Code (8 bits):
QoS Model Error Codes may be defined for NSLP error class 6 (QoS
Model Error), as described in Section 6.4 of [RFC5974]. Values are
as follows:
0-63: Unassigned
64-67: Private/Experimental Use
68-255: Reserved
The registration procedure is Specification Required. (A
specification is required to depreciate, delete, or modify QoS Model
Error Codes.)
Parameter ID (12 bits):
The following values are allocated by this specification:
1-14: assigned as specified in Section 5.2:
1: <TMOD-1>
2: <TMOD-2>
3: <Path Latency>
4: <Path Jitter>
5: <Path PLR>
6: <Path PER>
7: <Slack Term>
8: <Preemption Priority> and <Defending Priority>
9: <Admission Priority>
10: <RPH Priority>
11: <Excess Treatment>
12: <PHB Class>
13: <DSTE Class Type>
14: <Y.1541 QoS Class>
Further values are as follows:
15-255: Unassigned
256-259: Private/Experimental Use
260-4095: Reserved
The registration procedure is Specification Required. (A
specification is required to depreciate, delete, or modify Parameter
IDs.)
Y.2171 Admission Priority Parameter (8 bits):
The following values are allocated by this specification:
0-2: assigned as specified in Section 5.2.9:
0: best-effort priority flow
1: normal priority flow
2: high priority flow
Further values are as follows:
3-63: Unassigned
64-255: Reserved
The registration procedure is Specification Required.
RPH Namespace Parameter (16 bits):
Note that [RFC4412] creates a registry for RPH Namespace and Priority
values already (see Section 12.6 of [RFC4412]), and an extension to
this registry is created in [EMERG-RSVP], which will also be used for
the QSPEC RPH parameter. In the extended registry, "Namespace
Numerical Values" are assigned by IANA to RPH Namespaces, and
"Priority Numerical Values" are assigned to the RPH Priority. There are no additional IANA requirements made by this specification for the RPH Namespace Parameter. Excess Treatment Parameter (8 bits): The following values are allocated by this specification: 0-3: assigned as specified in Section 5.2.11: 0: drop 1: shape 2: re-mark 3: no metering or policing is permitted Further values are as follows: 4-63: Unassigned 64-255: Reserved The registration procedure is Specification Required. Y.1541 QoS Class Parameter (8 bits): The following values are allocated by this specification: 0-7: assigned as specified in Section 5.2.14: 0: Y.1541 QoS Class 0 1: Y.1541 QoS Class 1 2: Y.1541 QoS Class 2 3: Y.1541 QoS Class 3 4: Y.1541 QoS Class 4 5: Y.1541 QoS Class 5 6: Y.1541 QoS Class 6 7: Y.1541 QoS Class 7 Further values are as follows: 8-63: Unassigned 64-255: Reserved The registration procedure is Specification Required.8. Acknowledgements
The authors would like to thank (in alphabetical order) David Black, Ken Carlberg, Anna Charny, Christian Dickman, Adrian Farrel, Ruediger Geib, Matthias Friedrich, Xiaoming Fu, Janet Gunn, Robert Hancock, Chris Lang, Jukka Manner, Martin Stiemerling, An Nguyen, Tom Phelan, James Polk, Alexander Sayenko, John Rosenberg, Hannes Tschofenig, and Sven van den Bosch for their very helpful suggestions.9. Contributors
This document is the result of the NSIS Working Group effort. In addition to the authors/editors listed in Section 12, the following people contributed to the document:
Roland Bless Institute of Telematics, Karlsruhe Institute of Technology (KIT) Zirkel 2, Building 20.20 P.O. Box 6980 Karlsruhe 76049 Germany Phone: +49 721 608 6413 EMail: bless@kit.edu URI: http://tm.kit.edu/~bless Chuck Dvorak AT&T Room 2A37 180 Park Avenue, Building 2 Florham Park, NJ 07932 Phone: +1 973-236-6700 Fax: +1 973-236-7453 EMail: cdvorak@research.att.com Yacine El Mghazli Alcatel Route de Nozay 91460 Marcoussis cedex FRANCE Phone: +33 1 69 63 41 87 EMail: yacine.el_mghazli@alcatel.fr Georgios Karagiannis University of Twente P.O. BOX 217 7500 AE Enschede The Netherlands EMail: g.karagiannis@ewi.utwente.nl Andrew McDonald Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK EMail: andrew.mcdonald@roke.co.uk
Al Morton AT&T Room D3-3C06 200 S. Laurel Avenue Middletown, NJ 07748 Phone: +1 732 420-1571 Fax: +1 732 368-1192 EMail: acmorton@att.com Bernd Schloer University of Goettingen EMail: bschloer@cs.uni-goettingen.de Percy Tarapore AT&T Room D1-33 200 S. Laurel Avenue Middletown, NJ 07748 Phone: +1 732 420-4172 EMail: tarapore@.att.com Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm, Sweden EMail: Lars.Westberg@ericsson.com10. Normative References
[3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; enhanced Multi Level Precedence and Preemption service (eMLPP) - Stage 1 (Release 7). [3GPP-2] 3GPP TS 23.067 V7.1.0 (2006-03) Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Core Network; enhanced Multi-Level Precedence and Preemption service (eMLPP) - Stage 2 (Release 7). [3GPP-3] 3GPP TS 24.067 V6.0.0 (2004-12) Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Core Network; enhanced Multi-Level Precedence and Preemption service (eMLPP) - Stage 3 (Release 6).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997. [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001. [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001. [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005. [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006. [RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006. [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010. [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of- Service Signaling", RFC 5974, October 2010. [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services", February 2006. [Y.2171] ITU-T Recommendation Y.2171, "Admission Control Priority Levels in Next Generation Networks", September 2006.
11. Informative References
[COMPOSITION] Morton, A. and E. Stephan, "Spacial Composition of Metrics", Work in Progress, July 2010. [DQOS] CableLabs, "PacketCable Dynamic Quality of Service Specification", CableLabs Specification PKT-SP-DQOS-I12-050812, August 2005. [EMERG-RSVP] Le Faucheur, F., Polk, J., and K. Carlberg, "Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority", Work in Progress, March 2010. [G.711] ITU-T Recommendation G.711, "Pulse code modulation (PCM) of voice frequencies", November 1988. [IEEE754] Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, August 1985. [CL-QOSM] Kappler, C., "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Work in Progress, April 2010. [DSCP-REGISTRY] IANA, "Differentiated Services Field Codepoints", http://www.iana.org. [NETWORK-OCTET-ORDER] Wikipedia, "Endianness", http://en.wikipedia.org/wiki/Endianness. [PHBID-CODES-REGISTRY] IANA, "Per Hop Behavior Identification Codes", http://www.iana.org. [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2474] 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. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999. [RFC2997] Bernet, Y., Smith, A., and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000. [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
5226, May 2008.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, March 2009.
[RFC5976] Ash, G., Morton, A., Dolly, M., Tarapore, P., Dvorak,
C., and Y. El Mghazli, "Y.1541-QOSM: Model for
Networks Using Y.1541 Quality-of-Service Classes",
RFC 5976, October 2010.
[RFC5977] Bader, A., Westberg, L., Karagiannis, G., Kappler, C,
and T. Phelan, "RMD-QOSM: The NSIS Quality-of-Service
Model for Resource Management in Diffserv", RFC 5977,
October 2010.
[VERTICAL-INTERFACE]
Dolly, M., Tarapore, P., and S. Sayers, "Discussion
on Associating of Control Signaling Messages with
Media Priority Levels", T1S1.7 and PRQC, October
2004.
[Y.1540] ITU-T Recommendation Y.1540, "Internet Protocol Data
Communication Service - IP Packet Transfer and
Availability Performance Parameters", December 2002.
Appendix A. Mapping of QoS Desired, QoS Available, and QoS Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ
The union of QoS Desired, QoS Available, and QoS Reserved can provide all functionality of the objects specified in RSVP IntServ; however, it is difficult to provide an exact mapping. In RSVP, the Sender TSpec specifies the traffic an application is going to send (e.g., TMOD). The AdSpec can collect path characteristics (e.g., delay). Both are issued by the sender. The receiver sends the FlowSpec that includes a Receiver TSpec describing the resources reserved using the same parameters as the Sender TSpec, as well as an RSpec that provides additional IntServ QoS Model specific parameters, e.g., Rate and Slack. The RSVP TSpec, AdSpec, and RSpec are tailored to the receiver- initiated signaling employed by RSVP and the IntServ QoS Model. For example, to the knowledge of the authors, it is not possible for the sender to specify a desired maximum delay except implicitly and mutably by seeding the AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in the receiver-issued RSVP RESERVE message. For this reason, our discussion at this point leads us to a slightly different mapping of necessary functionality to objects, which should result in more flexible signaling models.Appendix B. Example of TMOD Parameter Encoding
In an example VoIP application that uses RTP [RFC3550] and the G.711 Codec [G.711], the TMOD-1 parameter could be set as follows: In the simplest case, the Minimum Policed Unit m is the sum of the IP, UDP, and RTP headers + payload. The IP header in the IPv4 case has a size of 20 octets (40 octets if IPv6 is used). The UDP header has a size of 8 octets, and RTP uses a 12-octet header. The G.711 Codec specifies a bandwidth of 64 kbit/s (8000 octets/s). Assuming RTP transmits voice datagrams every 20 ms, the payload for one datagram is 8000 octets/s * 0.02 s = 160 octets. IPv4 + UDP + RTP + payload: m = 20 + 8 + 12 + 160 octets = 200 octets IPv6 + UDP + RTP + payload: m = 40 + 8 + 12 + 160 octets = 220 octets The Rate r specifies the amount of octets per second. 50 datagrams are sent per second. IPv4: r = 50 1/s * m = 10,000 octets/s IPv6: r = 50 1/s * m = 11,000 octets/s
The bucket size b specifies the maximum burst. In this example, a burst of 10 packets is used. IPv4: b = 10 * m = 2000 octets IPv6: b = 10 * m = 2200 octets A number of extra headers (e.g., for encapsulation) may be included in the datagram. A non-exhaustive list is given below. For additional headers, m, r, and b have to be set accordingly. Protocol Header Size --------------------------+------------ GRE [RFC1701] | 8 octets GREIP4 [RFC1702] | 4-8 octets IP4INIP4 [RFC2003] | 20 octets MINENC [RFC2004] | 8-12 octets IP6GEN [RFC2473] | 40 octets IP6INIP4 [RFC4213] | 20 octets IPsec [RFC4301, RFC4303] | variable --------------------------+------------
Authors' Addresses
Gerald Ash (Editor) AT&T EMail: gash5107@yahoo.com Attila Bader (Editor) Traffic Lab Ericsson Research Ericsson Hungary Ltd. Laborc u. 1 H-1037 Budapest Hungary EMail: Attila.Bader@ericsson.com Cornelia Kappler (Editor) ck technology concepts Berlin, Germany EMail: cornelia.kappler@cktecc.de David R. Oran (Editor) Cisco Systems, Inc. 7 Ladyslipper Lane Acton, MA 01720, USA EMail: oran@cisco.com