RFC 2997

Specification of the Null Service Type

📅 published November 2000, from ietf

Specification of the Null Service Type ✨

okay bestie, this is RFC 2997 🎀 and it's giving "Standards Track" energy 💅. It was written in November 2000 by Y. Bernet (Microsoft), A. Smith (Allegro Networks), and B. Davie (Cisco Systems), and it's part of the Network Working Group 🌸. The title is Specification of the Null Service Type.

Status of This Memo

This is an Internet standards track protocol for the whole Internet community 🌈, and it's asking for discussion and suggestions for improvements 🫶. Go check 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 (C) The Internet Society (2000). All Rights Reserved. 🔥

Abstract

okay so in the typical Resource Reservation Protocol (RSVP)/Intserv model 🦋, applications ask for a specific Intserv service type and then put numbers on how many resources they need for it. For some apps, though, the network admin should really be the one picking the service parameters 👑. Like, ERP applications are often mission critical and need some kind of prioritized service, but they can't easily say exactly what resources they need 😭. So we introduce the notion of the Null Service 🧚. It lets apps identify themselves to network Quality of Service (QoS) policy agents using RSVP signaling, but they don't have to specify resource requirements, no cap 🙈. The policy agents in the network then apply QoS policies that fit the app (as decided by the network administrator) 💅. This way of using RSVP is especially good for networks that mix differentiated service (diffserv) QoS mechanisms with RSVP signaling [intdiff] ✨. In that setup, the policy agents can steer the signaled app's traffic into a particular diffserv class of service 💖.

1. Motivation

So with standard RSVP/Intserv signaling, apps running on hosts ask for network resources by sending these four things to network devices 🎀:

  1. A requested service level (Guaranteed or Controlled Load).
  2. The quantity of resources required at that service level.
  3. Classification information by which the network can recognize specific traffic (filterspec).
  4. Policy/identity information indicating the user and/or the application for which resources are required.

Then RSVP-aware network nodes decide whether to admit or deny the request 👀. That decision depends on whether resources are available along the relevant path, and on policies 🧐. Policies define which resources can be granted to specific users and/or applications 💅. When a request gets admitted, the nodes install classifiers to recognize the admitted traffic, and policers to make sure the traffic stays within the resources that were requested 🔒.

The Guaranteed and Controlled Load Intserv services aren't a great fit for apps that can't (or don't want to) say what resources they need from the network 😩. Diffserv services are way better suited for this kind of app 🍓. Nodes in a diffserv network are usually provisioned to sort arriving packets into a small number of behavior aggregates (BAs) [diffarch] 🌈. Traffic gets handled on a per-BA basis ✨. This provisioning is kinda "top-down" when it comes to end-user traffic flows, because there's no signaling between hosts and the network 🙃. Instead, the network admin uses a mix of heuristics, measurement and experience to provision the network devices for aggregated traffic, with no deterministic knowledge of how much traffic will arrive at any specific node 😵‍💫.

When network admins apply diffserv mechanisms to manage app traffic, they run into two challenges 🚨:

  1. Provisioning - network admins need to anticipate the volume of traffic likely to arrive at each network node for each diffserv BA. If the volume arriving is likely to exceed the capacity available for the claimed BA, the admin can either increase the capacity for the BA, reduce the volume of traffic claiming the BA, or compromise service to all traffic arriving for the BA 😭.
  2. Classification - diffserv nodes classify traffic to user and/or application, based on the diff-serv codepoint (DSCP) in each packet's IP header, or based on other fields in the packet's IP header (source/destination address/port and protocol) 🧩. The latter method is called MF classification. This method can be unreliable and adds a management burden 💀.

Using RSVP signaling can make managing app traffic in diffserv networks way easier 🥹. (Fun fact: RSVP/diffserv interoperability was already discussed in the context of the Guaranteed and Controlled Load Intserv services.) This document focuses on RSVP/diffserv interoperability in the context of the Null Service 🦋.

2. Operational Overview

In the proposed mechanism, the RSVP sender offers a new service type, Null Service Type, in the ADSPEC that's included with the PATH message ✨. A new Tspec corresponding to the new service type gets added to the SENDER_TSPEC 🎀. On top of that, the RSVP sender will typically include policy objects with the PATH message that identify the user, the application and the sub application ID [identity, application] 💖.

(Heads up: right now the new Tspec is only defined to carry the maximum packet size parameter (M), so that fragmentation gets avoided. No other parameters are defined yet 🙈.)

Network nodes that receive these PATH messages read the service type as "this app isn't asking for any specific service type or quantifiable resources" 🫠. Instead, the nodes manage the traffic flow based on the requesting user, the requesting application, and the type of application sub-flow 👑.

This mechanism has some big advantages over a pure diffserv network 🔥. At the very least, it tells each network node that would be affected by the traffic flow (and that's interested in intercepting the signaling) about:

  1. The demand for resources, in terms of the number of flows of a particular type traversing the node.
  2. The binding between classification information and user, application and sub-application.

This info is super useful to policy enforcement points and policy decision points (PEPs and PDPs) 🧚. The network admin can configure these elements of the policy management system to apply the right policy based on the identity of the user, the application, and the specific sub application ID 💅.

PEPs and PDPs can be set up to return an RSVP RESV message to the sender 🦋. The returned RESV message may include a DCLASS object [dclass]. The DCLASS object tells the sender to mark packets on the matching flow with a specific DSCP (or a set of DSCPs) 🌈. This lets PEPs and PDPs affect how much traffic arrives at a node for any given BA ✨, and they can do it based on sophisticated policies 😤.

3.1 Operational Notes

3.1.1 Scalability Issues

If a network uses per-flow signaling, it's wise to think about scalability 🤓. The Null Service encourages signaling for a broader set of apps than would otherwise signal 👀. But RSVP signaling doesn't, in general, generate a significant amount of traffic compared to the actual data traffic for the session 💁‍♀️. Also, the Null Service doesn't push every app to signal 🙅‍♀️. It should be used by apps that are considered mission critical or that need QoS management by network admins 🫶.

The bigger worry is the impact on processing resources at the network nodes that process the signaling messages 😬. When thinking about this, it's important to point out that it's not necessary to process the signaling messages at every network node 🙌. Honestly, combining RSVP signaling with diff-serv networks can be a huge win even when RSVP messages are only processed at certain key nodes (like boundaries between network domains, first-hop routers, PEPs, or any subset of these) 🥰. Individual nodes should be enabled or disabled for RSVP processing at the discretion of the network administrator 👑. See [intdiff] for a discussion of the impact of RSVP signaling on diff-serv networks 📚.

Anyway, per-flow state isn't necessarily required, even in nodes that apply per-flow processing 💜.

2.1.2 Policy Enforcement in Legacy Networks

Network nodes that follow the RSVP spec should transparently pass signaling messages for the Null Service 🎀. Which means you can drop a small number of PEPs that are enabled for Null Service into a legacy network and still get the benefits described in this document 🌸.

2.1.3 Combining Existing Intserv Services with the Null Service

This document doesn't stop apps from offering both a quantitative Intserv service (Guaranteed or Controlled Load) and the Null Service at the same time 🦋. Like, a telephony app might benefit from the Guaranteed Service but can also adapt to a less strict service. By advertising support for both, the app lets network policy decide which service type to provide 🧠✨.

3. Signaling Details

3.1 ADSPEC Generation

The RSVP sender builds an initial RSVP ADSPEC object that specifies the Null Service Type 🎀. Since there are no service-specific parameters tied to this service type, the associated ADSPEC fragment is empty and only contains the header word 🫧. Network nodes may or may not supply valid values for the bandwidth and latency general parameters 🤷‍♀️. So they may use the unknown values defined in [RFC2216] 🌈.

The ADSPEC gets added to the RSVP PATH message created at the sender 💖.

3.2 RSVP SENDER_TSPEC Object

An additional Tspec is defined to correspond to the Null Service 🧚. If only the Null Service is offered in the ADSPEC, then that's the only Tspec included in the SENDER_TSPEC object 💅. If guaranteed or controlled load services are also offered in the ADSPEC, then the new Tspec is appended after the standard Intserv token-bucket Tspec [RFC2210] 🔥.

3.3 RSVP FLOWSPEC Object

Receivers can respond to PATH messages by generating an RSVP RESV message that includes a FLOWSPEC object 🦋. The FLOWSPEC object should specify that it's requesting the Null Service ✨. It's possible that, in the future, a specific Rspec might be defined to correspond to the new service type 🔮.

4. Detailed Message Formats

4.1 Standard ADSPEC Format

A standard RSVP ADSPEC object is described in [RFC2210] 📖. It includes a message header and a default general parameters fragment 🎀. After the default general parameters fragment come fragments for each supported service type 🌸.

4.2 ADSPEC for Null Service Type 🎀

okay so the Null Service ADSPEC is basically the message header and the default general parameters fragment, plus one single fragment that says "hey, Null Service!" 💅 The new fragment for the Null Service looks like this:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    6 (a)      |x| Reserved    |           0 (b)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • (a) indicates Null Service (6).
  • (x) is the break-bit.
  • (b) indicates zero words in addition to the header.

Here's a complete ADSPEC that only supports the Null Service 🦋

      31            24 23           16 15            8 7
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    1 | 0 (a) |    Reserved           |  Msg length -1 (b)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    2 | 1 (c)         |x| Reserved    |           8 (d)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    3 |    4 (e)        |    (f)      |           1 (g)               |
    + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    4 |                    IS hop cnt (32-bit unsigned)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    5 |    6 (h)        |    (i)      |           1 (j)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    6 |   Path b/w estimate  (32-bit IEEE floating point number)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    7 |    8 (k)        |    (l)      |           1 (m)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    8 |        Minimum path latency (32-bit integer)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    9 |   10 (n)        |    (o)      |           1 (p)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   10 |        Composed MTU (32-bit unsigned)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   11 |    6 (q)      |x| Reserved    |           0 (r)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's the breakdown, word by word:

Word 1: Message Header:

  • (a) - Message header and version number
  • (b) - Message length (10 words not including header)

Words 2-10: Default general characterization parameters

  • (c) - Per-Service header, service number 1 (Default General Parameters)
  • (x) - Global Break bit (NON_IS_HOP general parameter 2)
  • (d) - Length of General Parameters data block (8 words)
  • (e) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS general parameter)
  • (f) - Parameter 4 flag byte
  • (g) - Parameter 4 length, 1 word not including header
  • (h) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH general parameter)
  • (i) - Parameter 6 flag byte
  • (j) - Parameter 6 length, 1 word not including header
  • (k) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY general parameter)
  • (l) - Parameter 8 flag byte
  • (m) - Parameter 8 length, 1 word not including header
  • (n) - Parameter ID, parameter 10 (PATH_MTU general parameter)
  • (o) - Parameter 10 flag byte
  • (p) - Parameter 10 length, 1 word not including header

Word 11: Null Service parameters

  • (q) - Per-Service header, service number 6 (Null)
  • (x) - Break bit for Null Service
  • (r) - Length (0) of per-service data not including header word.

Now, here's the reassuring bit ✨ The standard rules for parsing ADSPEC service fragments mean the ADSPEC won't get rejected by legacy network elements 🫶 Specifically, a network element that runs into a per-service data header it doesn't understand should set bit 23 (the break-bit) to say the service isn't supported, and then use the length field in that header to skip over the rest of the fragment.

Also, heads up: it's likely that hosts or network nodes won't be able to generate meaningful values for words 5 and/or 7 (the bandwidth estimates and path latency) 🙈 That's just the nature of this service. In that case, the unknown values from [RFC2216] should be used.

4.3 SENDER_TSPEC Object Format 🧚

This Tspec is defined to match up with the Null Service:

     31            24 23           16 15            8 7
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1 |   6 (a)       |0|  Reserved   |             2 (b)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2 | 128 (c)       |    0 (d)      |             1 (e)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3 | Maximum Packet Size [M] (32-bit integer)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Word 1: Service header

  • (a) - Service number 6 (Null Service)
  • (b) - Length of per-service data, 2 words not including per-service header

Word 2-3: Parameter

  • (c) - Parameter ID, parameter 128 (Null Service TSpec)
  • (d) - Parameter 128 flags (none set)
  • (e) - Parameter 128 length, 1 words not including parameter header

Quick note 📝 The diagram above doesn't include the standard RSVP SENDER_TSPEC object header, and it also doesn't include the sub-object header (the one that tells you the message format version number and length). Those are defined in RFC 2205 and RFC 2210, respectively.

So here's how it fits together 💜 If only the Null Service is advertised in the ADSPEC, the Tspec above gets appended right after the SENDER_TSPEC object header and sub-object header. If extra service types are advertised and they need the token bucket specific Tspec defined in RFC2210, then the Tspec above goes after the token bucket Tspec. That token bucket Tspec then follows the object header and sub-object header.

4.4 FLOWSPEC Object Format 🌸

Here's the format of an RSVP FLOWSPEC object that comes from a receiver asking for the Null Service. A value of 6 in the per-service header (field (c) below) means the Null Service is being requested.

     31            24 23           16 15            8 7
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1 | 0 (a)         |    reserved   |         3 (b)                 |
   + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2 |   6 (c)       |0|  Reserved   |             2 (d)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3 | 128 (e)       |    0 (f)      |             1 (g)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4 | Maximum Packet Size [M] (32-bit integer)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • (a) - Message format version number (0)
  • (b) - Overall length (3 words not including header)
  • (c) - Service header, service number 6 (Null)
  • (d) - Length of data, 2 words not including per-service header
  • (e) - Parameter ID, parameter 128 (Null Service TSpec)
  • (f) - Parameter 128 flags (none set)
  • (g) - Parameter 128 length, 1 words not including parameter header

4.5 DCLASS Object Format 💖

DCLASS objects may be included in RESV messages. If you want the details on the DCLASS object format, check out [dclass] 🔥

5. Security Considerations 🙈

Okay, serious moment, bestie 😭 The message formatting and usage rules described in this note raise no new security issues beyond standard RSVP. So nothing extra to worry about on top of what RSVP already brings to the table ✨

6. References 📚

[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.

[RFC2216] Shenker, S. and J. Wroclawski, "Network Element QoS Control Service Specification Template", RFC 2216, September 1997.

[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.

[intdiff] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Nichols, K., Speer, M., Braden, B. and B. Davie, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.

[diffarch] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.

[identity] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., "Identity Representation for RSVP", RFC 2752, January 2000.

[application] Bernet, Y., "Application and Sub Application Identity Policy Objects for Use with RSVP", RFC 2872, June 2000.

[dclass] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.

7. Acknowledgments 🫶

Huge thanks to Fred Baker, Dinesh Dutt, Nitsan Elfassy, John Schnizlein, Ramesh Pabbati and Sanjay Kaniyar for their comments on this memo. You all are literally the best 💅

8. Authors' Addresses 💜

Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052

Phone: +1 (425) 936-9568 EMail: Yoramb@microsoft.com

Andrew Smith Allegro Networks 6399 San Ignacio Ave. San Jose, CA 95119, USA

FAX: +1 415 345 1827 Email: andrew@allegronetworks.com

Bruce Davie Cisco Systems 250 Apollo Drive Chelmsford, MA 01824

Phone: +1 (978)-244-8000 EMail: bsd@cisco.com

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement ✨

Funding for the RFC Editor function is currently provided by the Internet Society. 🎀

📦 where this page comes from