Summary

  • RFC 3496 added an optional ATM_SERVICECLASS object to an RSVP-TE PATH message so an MPLS LSP could request UBR, VBR-NRT, VBR-RT or CBR treatment.
  • The document explicitly did not specify how an LSR would implement that treatment. Recognition, path state, reservation, labels, queue configuration, measured behavior and application outcome remained separate receipts.

RFC 3496 gave a traffic-engineering request the vocabulary of an older transport system. An MPLS network intended to carry ATM cells could receive a PATH message saying that the tunnel belonged to one of four ATM service classes. The aim was functional replacement: keep the service-class distinction while moving the traffic across links that could be Ethernet, Packet over SONET, ATM or something else.

The object was small. Class number 227 and C-Type 1 identified it. Twenty-nine bits were reserved, transmitted as zero and ignored on receipt. The final three bits selected UBR, non-real-time VBR, real-time VBR or CBR; values four through seven remained reserved. That economy was deliberate. It also exposed what the object could not say.

No field described a scheduler algorithm, queue depth, buffer allocation, policing rate, weight, latency target or loss threshold. The RFC stated the boundary directly: it specified how to signal that a traffic-engineered path must support the ATM classes, not how MPLS LSRs would emulate them through queuing and scheduling. CBR in the control plane was a requirement, not an installed mechanism.

The object appeared in PATH, after the optional Diffserv object in the extended grammar. The session still had to be an IPv4 LSP tunnel with a label request. Existing RSVP-TE limits remained, including unicast-only setup; multicast was left for further study. The addition narrowed one part of the request without replacing the rest of RSVP-TE.

When an LSP was associated with an ATM service class, the sender had to include the object. Every aware LSR recorded it in the path state block. Recording was useful evidence: it showed what class the control plane believed belonged to that path. It did not prove that the data plane had a corresponding queue or that packets were receiving the requested behavior under load.

The first-object rule prevented a message from negotiating by accumulation. If several ATM_SERVICECLASS objects appeared, only the first was meaningful. Later ones had to be ignored and not forwarded. A capture containing CBR followed by UBR did not mean two classes, a fallback order or a downstream override. It meant the first value governed and the rest were discarded.

The return direction was intentionally asymmetric. The destination answered with RESV without an ATM_SERVICECLASS object, whether PATH had carried one or not. A successful RESV therefore was not an echo receipt for the three-bit class. Operators had to correlate outbound PATH state, per-hop recognition, reservation state and data-plane configuration rather than infer the whole chain from the reply.

Optionality made compatibility subtle. A node that did not recognize class number 227 followed RSVP’s rule for unknown classes with high bits 11: ignore the object but forward it unchanged. The bytes could cross a node whose software did not understand their meaning. Continuity of the object was thus weaker evidence than hop support.

A node that knew the class number but not the C-Type sent a PathErr for an unknown object type. RFC 3496 said unsupported cases caused setup failure. The sender should notify management and might retry without the object. The retry created a decision, not a repair: is generic connectivity acceptable when the requested ATM service contract has been removed?

If that second attempt succeeded, it proved a generic LSP could be established. It did not prove CBR, VBR or UBR behavior. Automation that celebrated “tunnel up” without recording the dropped object would transform an explicit service failure into an invisible downgrade.

Diffserv did not close the gap automatically. RFC 3270 defined MPLS mappings for behavior aggregates, while RFC 3564 and RFC 4124 developed Diffserv-aware traffic engineering around class types and bandwidth constraints. RFC 5127 later discussed several service classes sharing a treatment aggregate. RFC 3496 owned a narrower seam: one ATM-class request, how it travelled, and what happened when the path could not support the request.

The enduring evidence chain is therefore: PATH emitted, object parsed, class accepted, per-hop state recorded, policy and resources admitted, RESV returned, labels programmed, queues and schedulers configured, behavior measured and application delivered. Each transition has a different owner and observable. A three-bit field can begin that chain. It cannot complete it.

Sources