Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5975

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

Pages: 64
Experimental
Part 4 of 4 – Pages 51 to 64
First   Prev   None

Top   ToC   RFC5975 - Page 51   prevText

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   ToC   RFC5975 - 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   ToC   RFC5975 - 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   ToC   RFC5975 - 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   ToC   RFC5975 - 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   ToC   RFC5975 - 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   ToC   RFC5975 - 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   ToC   RFC5975 - 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   ToC   RFC5975 - 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   ToC   RFC5975 - 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   ToC   RFC5975 - 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   ToC   RFC5975 - 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   ToC   RFC5975 - 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   ToC   RFC5975 - 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