Summary

  • RFC 3033 assigned Internet meanings to Q.2941 Generic Identifier and Q.2957 User-to-user Signaling fields, allowing ATM call control to distinguish a session identifier, a resource identifier and carried setup data.
  • A correct value was only a coordination input: the RFC separately required successful VC establishment, called-side interpretation and an IP-layer move, and warned that its assignment might not constitute a complete interoperable protocol.

Imagine freezing the procedure at its most misleading instant. A SETUP message contains a perfectly formed IPv4 session identifier: source and destination addresses, protocol, source port and destination port. The receiving signalling system can tell which conversation the caller means. Nevertheless, the conversation is still multiplexed over the default virtual circuit. The new VC has not yet been proved to exist, and no IP-layer state has been shown to change.

That gap is the subject of RFC 3033. Published in January 2001 as a Proposed Standard, it assigned Internet meanings inside two optional ATM signalling information elements. Its title is unusually literal: it specifies an information field and a protocol identifier. The document calls this an indispensable framework for long-lived and quality-sensitive sessions over ATM, then adds a decisive limit. It may not specify the complete protocol needed for interoperable implementation; that work lies outside its scope.

The example contains three events, not one

For a long-lived session, RFC 3033 sketches a sequence. First, the session shares a default VC between routers. A router detects that the session is likely to persist and sets up a new VC for it. Only if that VC is established successfully does the router move the session.

The called side must perform another handoff. Its B-ISDN signalling entity has to recognise that the incoming call corresponds to an Internet-protocol session and notify the IP layer. The IP layer then moves the session to the new VC. The identifier supplies a common subject for that coordination. It does not perform the detection, create the circuit, deliver the notification, update the forwarding state or carry a confirming packet.

The sequence is easy to compress in a diagram and dangerous to compress in evidence. “Session identifier accepted” is not “VC established”. “VC established” is not “session moved”. “Session moved” is not “traffic observed on the new path”. Each statement needs its own receipt.

Two containers served different purposes

RFC 3033 worked with Q.2941 Generic Identifier and Q.2957 User-to-user Signaling, often abbreviated UUS. They can look similar because both travel in ATM call-control messages. The RFC insists that they are not interchangeable.

Generic Identifier was designed to transfer identifiers between control planes. The ATM network could inspect its contents, and the element could contain more than one typed identifier. UUS was designed to carry user data through the control planes. Its protocol discriminator identified the upper-layer use, while the ATM network did not inspect the user information. The two mechanisms also had different exception and interworking rules. Generic Identifier was limited to 63 octets; UUS to 133.

“Transferred transparently” was a carriage property, not a truth certificate. It meant that an element without coding-rule errors could cross the ATM network under the applicable signalling rules. It did not mean that both endpoints attached the same meaning to the value, that the value authenticated its sender, or that the requested operation occurred.

Typing turned bytes into a bounded claim

Inside Generic Identifier, RFC 3033 assigned related-application values for IPv4, ST2+, IPv6 and MPLS. It assigned identifier type 0x01 to Session and 0x02 to Resource, while reserving a range for later IANA assignment and 0xFE for experimental or organisation-specific use.

For IPv4, the session value was a 13-octet tuple: two addresses, protocol and two ports. The IPv6 form used the corresponding 37-octet tuple. Both were intended for explicit reservations; wildcard associations would need another type. An MPLS VCID appeared as a four-octet Resource identifier. The type therefore answered a necessary question: are these bytes naming a session, a resource or a private experiment?

It did not answer every question. A signalling message could contain multiple identifiers, and RFC 3033 did not define their order. It did not define the semantics of repeated identifiers of the same type, or of a Generic Identifier element containing no identifiers. Even the response rule exposed the boundary. A CONNECT or ADD PARTY ACK had to contain at least one Generic Identifier after a corresponding request, but the called party did not have to echo the same value. The rule enabled negotiation; the detailed negotiation procedure was explicitly unspecified.

Presence was thus evidence of a signalling capability, not evidence of agreement. An ATM network that did not support the element could clear the call, discard the element or discard the signalling message. A registry assignment could make a value unambiguous when it survived; it could not force every network to preserve it.

User-to-user signalling carried setup data, not the result

For UUS, RFC 3033 assigned protocol discriminator 0x06 to Internet protocol/application and application identifier 0x02 to an RSVP message. It mapped RSVP Resv into SETUP, ResvConf into CONNECT, and ResvErr or ResvTear into RELEASE. This allowed setup information to travel with ATM call signalling rather than necessarily following a separate IP exchange.

The document compared two procedures for QoS-sensitive sessions. In the sequential procedure, a setup protocol travels over a default or particular VC and the IP session and ATM VC are established in sequence. In the simultaneous procedure, the setup protocol rides inside B-ISDN signalling, permitting both establishment processes to proceed together. Simultaneity could simplify admission control and timers, but the RFC noted that the method could not support at least the PVC case. Both procedures remained necessary.

Carrying an RSVP message does not prove that RSVP admission succeeded. A CONNECT message does not by itself prove that the requested QoS was installed at every relevant layer. A typed UUS payload names what was carried; a reservation state, VC state, traffic observation and application result remain separate facts.

A narrow assignment was honest engineering

RFC 3033 left open support for session aggregation, wildcard-style identifiers, IPv6 flow labels and traffic classes. That incompleteness was not concealed by the Standards Track label. The authors assigned the values they could define and named the model questions still unresolved.

The security discussion was equally bounded. A verified or network-provided calling-party number might contribute to caller authentication. The session identifier itself was not promoted into an authenticator, authorization token or proof of service. The distinction matters because identifiers are tempting authority surrogates: once a field names the right subject, downstream systems often behave as though the subject approved the action and the action completed.

RFC 3033 records a more disciplined design. First make the subject intelligible across a signalling boundary. Then run the separate protocol, observe the state change and verify the traffic effect. The identifier can coordinate reality. It cannot substitute for it.

Sources

Lu Heng did not author or endorse RFC 3033, the ITU-T recommendations or the contextual RFCs. His essays are used here as disclosed analytical lenses.