tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5975

 
 
 

QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)

Part 4 of 4, p. 51 to 64
Prev RFC Part

 


prevText      Top      Up      ToC       Page 51 
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

Top      Up      ToC       Page 52 
   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:

Top      Up      ToC       Page 53 
   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

Top      Up      ToC       Page 54 
      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

Top      Up      ToC       Page 55 
   "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:

Top      Up      ToC       Page 56 
   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

Top      Up      ToC       Page 57 
   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.com

10.  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).

Top      Up      ToC       Page 58 
   [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.

Top      Up      ToC       Page 59 
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.

Top      Up      ToC       Page 60 
   [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

Top      Up      ToC       Page 61 
                   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.

Top      Up      ToC       Page 62 
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

Top      Up      ToC       Page 63 
   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
   --------------------------+------------

Top      Up      ToC       Page 64 
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