Specification of the Null Service Type
Extracted elements (15)
The Null Service does not require per-flow RSVP processing at every network node. Significant benefits can be realized even when RSVP messages are processed only at key nodes such as domain boundaries, first-hop routers, or PEPs. Individual nodes should be enabled or disabled for RSVP processing at the network administrator's discretion.
The Null Service is particularly applicable to networks combining diffserv QoS mechanisms with RSVP signaling. In this environment, QoS policy agents (PEPs/PDPs) can direct signaled application traffic to a particular diffserv class of service, solving the classification and provisioning challenges of pure diffserv networks.
The Null Service Tspec carries only the maximum packet size parameter (M) to avoid fragmentation. No other quantitative parameters (token bucket rate, peak rate, burst size) are defined, reflecting the service's intent to avoid requiring applications to specify resource requirements.
The Null Service was introduced because applications like ERP systems are mission critical and require prioritized service, but cannot readily specify their resource requirements. Rather than forcing them to quantify resources (as Guaranteed or Controlled Load Intserv services require), the Null Service lets applications identify themselves to policy agents and defer resource allocation decisions to the network administrator.
Applications may simultaneously offer both a quantitative Intserv service (Guaranteed or Controlled Load) and the Null Service in the same ADSPEC, enabling network policy to decide which service type to provide. For example, a telephony application might benefit from Guaranteed Service but also advertise Null Service as a fallback.
Network nodes adhering to the RSVP spec should transparently pass Null Service signaling messages, allowing a small number of Null Service-enabled PEPs to be introduced into a legacy network. Standard ADSPEC parsing rules ensure that legacy elements encountering an unknown per-service data header set the break-bit and skip over the fragment using the length field.
If only the Null Service is offered in the ADSPEC, the Null Service Tspec is the only Tspec included in the SENDER_TSPEC object. If Guaranteed or Controlled Load services are also offered, the Null Service Tspec is appended following the standard Intserv token-bucket Tspec.
Receivers responding to Null Service PATH messages with a RESV message should specify in the FLOWSPEC object that the Null Service is being requested (service number 6).
PEPs and PDPs may respond to Null Service PATH messages by returning an RSVP RESV message containing a DCLASS object, which instructs the sender to mark packets on the corresponding flow with a specific DSCP or set of DSCPs. This allows policy agents to steer traffic to the appropriate diffserv behavior aggregate.
The Null Service ADSPEC fragment contains only a header word with service number 6, a break-bit field, and a length field of 0 (no additional words beyond the header). Network nodes may supply general parameters (bandwidth, latency) using unknown values from RFC 2216 if meaningful values cannot be generated.
The Null Service Type allows RSVP senders to signal application identity and classification information without specifying quantitative resource requirements. The sender includes a Null Service ADSPEC fragment in the PATH message along with policy objects identifying the user, application, and sub-application ID.
The message formatting and usage rules described for the Null Service raise no new security issues beyond standard RSVP. The security considerations of RFC 2205 apply.
The Null Service ADSPEC fragment is a single 32-bit word: bits 31-24 carry service number 6, bit 23 is the break-bit, bits 22-16 are reserved, and bits 15-0 carry the length field (value 0, indicating zero additional words beyond the header).
The Null Service FLOWSPEC object is a 4-word structure: Word 1 has version 0 and overall length 3; Word 2 has service number 6 and per-service data length 2; Words 3-4 carry Parameter ID 128 (Null Service TSpec) with flags 0, length 1, and the Maximum Packet Size M as a 32-bit integer.
The Null Service SENDER_TSPEC is a 3-word structure: Word 1 has service number 6 and length 2; Word 2 has Parameter ID 128 (Null Service TSpec), flags 0, and length 1; Word 3 carries the Maximum Packet Size (M) as a 32-bit integer. Only the M parameter is defined; no token-bucket parameters are included.