Summary

  • RFC 3476 inserted OIF optical-UNI fields into public LDP and RSVP namespaces, but repeatedly left their content and use to the OIF specification.
  • Its explicit errors—unavailable diversity or service level, unknown connection, unauthorized sender or receiver—show that recognizing a registered number was only the first receipt, not proof of a service.

A number is one of the smallest things a standards institution can govern. That is precisely why it matters. If two implementations attach different meanings to the same numeric value, they can parse the same bits and still disagree about reality. A registry prevents that collision. It does not make the reality happen.

RFC 3476 captured this distinction unusually clearly. Published in March 2003, it was an Informational document, not an Internet Standard. The Optical Internetworking Forum had designed signaling for an optical User Network Interface and wanted to reuse IETF machinery as far as possible: LDP, RSVP, RSVP-TE and the emerging GMPLS work. The few UNI-specific additions needed values in protocol namespaces administered by IANA.

The document therefore looks like a catalogue. For LDP it listed Source ID and Destination ID TLVs in IPv4, IPv6 and NSAP forms. It added an Egress Label, Local Connection ID, Diversity, Contract ID and UNI Service Level. The assigned range ran from 0x0960 to 0x0970. For RSVP it defined a GENERALIZED_UNI object at class number 229, C-Type 1, and a UNI_IPv4_SESSION at class 1, C-Type 11. The GENERALIZED_UNI subobjects carried source and destination transport-network addresses, diversity, egress label and service level.

Yet the catalogue consistently stopped short of pretending that allocation was service definition. For field after field, RFC 3476 said that content and usage were described in the OIF UNI specification. The public number supplied a stable hook. The external specification supplied the rules. An implementation needed both, and an operator still had to decide whether the request was permitted and possible.

The split was not merely editorial. It was institutional. OIF had a service-facing agreement. IETF protocols supplied transport for signaling. IANA kept the shared numeric namespace collision-free. Each institution controlled a different part of the chain. RFC publication did not silently transfer OIF policy into IANA, nor did an IANA entry make an OIF service an IETF standard.

Even the allocation boundary was mixed. UNI-specific LDP status values lived in the private-use range 0x3Fxxxxxx and did not require IANA administration. Two proposed messages, Status Enquiry and Status Response, had already been made obsolete, so the RFC requested no numbers for them. A registry record was therefore also a history of selection: some constructs entered the public namespace, some stayed private, and some disappeared before assignment.

The error codes are the document's most revealing sentences. RSVP could answer that diversity was not available, that the requested service level was not available, or that a connection identifier was invalid or unknown. Policy control could reject an unauthorized sender or unauthorized receiver. Those outcomes were not failures of number recognition. They were decisions at later layers.

Consider a valid GENERALIZED_UNI object. Its class and C-Type may be recognized. Its length and subobjects may parse. Its source and destination TNA fields may be well formed. None of that proves that the sender is entitled to order the circuit, that the receiver consents, that two genuinely diverse optical paths exist, or that capacity is free. The same request can be syntactically flawless and operationally impossible.

This is the boundary between naming and control. A code point says, “interpret these bits as this kind of object.” It does not say, “obey this actor,” “accept this contract,” “allocate this wavelength,” or “declare the customer served.” Confusing those statements lets a low-level registry receipt borrow the authority of every downstream decision.

The surrounding RFCs reinforce the limit. RSVP maintains soft state and reservation messages. RSVP-TE adds tunnel signaling. LDP distributes labels. GMPLS generalizes labels beyond packets. Those mechanisms can carry a request and record protocol state; they do not turn one parsed object into a physical cross-connect. RFCs 3471 through 3475 also separate identity, signaling exchanges, notifications and Call/Connection operations. RFC 3476 adds a namespace seam, not a shortcut across those layers.

Later governance texts make the administrative logic easier to name. RFC 3936 described policies for assigning RSVP values. RFC 8126 emphasized that IANA Considerations should give IANA clear registration instructions while technical documentation belongs elsewhere. Those later documents should not be projected backward as 2003 rules, but they illuminate what RFC 3476 was already doing: publishing a referenceable number without claiming to execute its semantics.

The current IANA registries preserve part of that trail. They are evidence that values were assigned and referenced. They are not field telemetry. A registry page cannot show whether an optical switch accepted a request, whether path computation found diversity, whether a cross-connect was programmed, whether light was present, or whether traffic passed.

Heng Lu's reality-layer discipline turns that historical lesson into an audit method. Start with the raw message and its numeric identifier. Resolve it against the registry as it existed at the relevant time. Open the exact RFC and OIF specification revision. Record the parser result. Then move one layer at a time: identity, authentication, authorization, admission, path computation, resource reservation, hardware programming, signal observation, traffic and service outcome.

Do not collapse the chain. A recognized Source ID is not authenticated authority. A Diversity subobject is not two independent paths. A Service Level field is not a delivered SLA. An Egress Label is not an optical receipt. An absence of an error is not positive proof that all later work completed.

The refusal path deserves equal care. Preserve the error object, code and subcode, the node that emitted it, the time and the request it answered. “Diversity not available” is stronger than a generic failure because it identifies the stated refusal surface. It still does not prove the hidden topology, the accuracy of the resource database or the impossibility of every alternative.

RFC 3476 belongs in Internet history because it shows coordination at its most disciplined scale. A public registry can make independent implementations speak about the same object. That is necessary infrastructure. It is not sovereignty over the service and it is not evidence that the service exists. The number opens the case; the receipts must finish it.

Sources