RFC 3108: When Forward Pointed Both Ways

Summary

In RFC 3108, SDP called traffic “forward” when it moved away from the ATM node being described; ATM bearer signaling called it “forward” when it moved away from the endpoint that initiated bearer setup. In a backward setup, the same parameter changed names between layers.
The four-byte eecid joined a service-level call record to a later bearer request one-to-one. It was a locally scoped correlation key—not a caller identity, global connection name or proof that media flowed.

A correct value in the wrong coordinate system

Imagine two control panels beside one media gateway. The first says that a peak cell rate is forward because the traffic leaves the gateway. The second says that the identical rate is backward because the remote gateway initiated the bearer and this gateway received the setup request. Neither panel is mistaken. Each has chosen a different origin.

That was the translation problem written into RFC 3108, published on the Standards Track in May 2001. The document extended the syntax of the original Session Description Protocol, RFC 2327, so controllers and gateways could describe ATM and AAL2 bearer connections. It supplied attributes for addresses, adaptation layers, traffic descriptors, quality parameters, bearer types, channel identifiers and service choices. The descriptions could travel with SIP, MGCP or Megaco/H.248 control exchanges.

The historical interest lies beneath that inventory. Service-level call control and ATM bearer signaling were independent systems. The party that began a telephone or multimedia call did not necessarily begin the switched virtual connection carrying it. As soon as those roles separated, familiar directional words stopped being portable.

RFC 3108 defined forward relative to the ATM node under consideration: away from that node. Backward meant toward it. The rule stayed stable regardless of who initiated the service call or bearer. ATM and AAL2 signaling used another convention. There, forward ran from the endpoint that sent the bearer setup request to the endpoint that received it.

When the service-originating gateway also initiated the bearer, the frames could align. In the backward bearer model, the service-originating gateway instead terminated the bearer request. A traffic descriptor moving away from that gateway remained forward in its SDP description but became backward in the ATM setup. The gateway had to swap the meaning. Byte-for-byte fidelity would have produced semantic error.

Direction was data, not grammar

RFC 3108 made direction explicit in attributes such as atmQOSparms and atmTrfcDesc. Their directionFlag could be f, b or fb: forward, backward or both. For these lines, the flag was mandatory even when other parameters were unspecified, inapplicable or supplied elsewhere and therefore shown as .

The traffic values were not decorative. A descriptor could carry peak and sustainable cell rates, burst sizes, delay variation, transit delay and acceptable loss ratios. If a gateway attached a valid value to the wrong direction, the session description could still parse while the intended resource contract was inverted. One path might receive the wrong capacity or quality constraint; a controller could then report agreement between messages that had never agreed about the same flow.

This is why RFC 3108 cannot be reduced to an ATM vocabulary for SDP. It specified a translation boundary. An implementation needed to retain at least four facts: which node an SDP description was about, which endpoint initiated service-level control, which endpoint initiated bearer setup, and which convention governed the field currently being processed. “Forward” without those facts was incomplete evidence.

Wildcards reinforced the point. In several fields, $ let the recipient select a permitted value. A hyphen could mean irrelevant, implied, unspecified or known through another mechanism, depending on the field. A parser could establish that the syntax was legal; it could not establish that the selected value existed in hardware, had been admitted by policy or made sense for the application.

One service call, one bearer request, one local join

Separate control paths created a second problem. A service-level instruction could arrive at a gateway before an ATM setup request. When the bearer request later appeared from the network, the gateway needed to know which earlier service context it belonged to.

RFC 3108 used eecid, the end-to-end connection identifier, for that join. In the cited ATM and ISUP settings it was synonymous with the four-byte bnc-id, but SDP used a neutral name. The value correlated one received bearer-setup request with one service-level call-control record.

The selector changed with the setup model. For forward bearer establishment, the call-terminating gateway selected the eecid, sent it through SDP toward the call-originating gateway, then received it back in the bearer request initiated by that originating side. For backward establishment, the call-originating gateway selected it, sent it to the terminating side through SDP, then received it back when the terminating gateway initiated the bearer.

The apparent round trip was a deliberate handoff. The node that would terminate bearer setup chose the value by which it could recognize the future request. RFC 3108 required uniqueness within that terminating node, not across the Internet or even across all gateways. The assigning node controlled release and reuse. Although it could free the value after the request arrived, the document recommended retaining it until the connection ended.

That scope rules out several seductive inferences. An eecid did not name a person, authenticate a subscriber, allocate an ATM circuit or prove that two-way media existed. It was a local database key crossing two protocol paths. A matching value established correlation. The subsequent setup and connect exchange established bearer state. Packet and application measurements were still needed to establish service.

RFC 3108 also stopped short of owning the bearer encoding. It described ways contemporary bearer protocols might carry the value—such as particular information elements—but left that transport to those protocols. The SDP record and the ATM signaling record could express the same correlation while remaining separately governed artifacts.

Description, setup and traffic were three different things

The call-establishment examples make the separation visible. Media gateway controllers exchanged service information. Each controller instructed its gateway. One gateway then sent an ATM setup directly to the other, with the previously exchanged eecid. The receiver used the key to locate the earlier control context and returned a connect message. Only after that sequence could media use the bearer.

An operator who recorded only the SDP body would know what was described, not what was built. A control acknowledgement could show that a gateway accepted an instruction, not that the remote network admitted the SVC. A setup message could show an attempt, not a connect. A connect could show bearer establishment, not acceptable delay, loss or bidirectional application behavior.

RFC 3108's chain attribute addressed another version of the same separation. Consecutive SDP descriptions might be alternatives for one session, or they might describe different layers—an IP session and its ATM carrier, for example. chain allowed the records to remain clean and distinct while stating that one belonged with the next or previous description. Linkage was not execution. A chain connected descriptions; it did not certify that either layer ran.

This layered reading also prevents later SDP history from being projected backward. RFC 3264 formalized an offer/answer model in 2002, after RFC 3108. RFC 4566 and RFC 8866 later revised SDP itself. They show a continuing lineage, but they do not prove that every 2001 ATM description followed a later exchange pattern or that RFC 3108 conventions saw broad deployment.

Security belonged to the envelope

RFC 3108 was candid about security. It noted that encryption of ATM and AAL2 bearers had not been conventionalized like RTP payload encryption, and authentication of their bearer signaling had not been conventionalized either. The SDP k= line could represent a key or a way to obtain one, but representation was not evidence of protection.

Descriptions might come from equipment in untrusted subscriber premises. Rather than create a new security system inside the description, the RFC relied on the encapsulating protocol or lower layers. SIP, MGCP and Megaco environments could use IPsec authentication and optional encryption. “Could” mattered. A secure construction in a specification did not say a particular exchange used it, which peers shared an association, or whether the bearer itself was encrypted.

The evidentiary chain therefore needed independent records: the exact SDP body, its sender and node of reference; service-call roles; bearer-setup origin; translated direction fields; eecid allocator and scope; bearer request and connect; authentication and encryption state; installed QoS; counters; packets in both directions; and the application's outcome.

The history is a warning against portable words

RFC 3108 is easy to dismiss as an elaborate appendix to a fading transport technology. That misses its durable lesson. Distributed systems often reuse ordinary words—owner, active, local, primary, forward—across layers. A word remains stable while its coordinate system changes. The resulting message can be valid, signed and faithfully copied, yet wrong at the next control surface.

The media gateway in 2001 could not resolve that problem by choosing the more authoritative document. Both descriptions were authoritative within their own layers. It had to translate between them and preserve enough provenance to know which frame applied. The correlation key then joined the records without pretending to collapse them.

Both layers said forward. They did not disagree about the wire; they disagreed about where direction began. The gateway's job was to keep that distinction alive until running bearer state and observed media could replace description with evidence.

Both Layers Said Forward. They Meant Opposite Directions: RFC 3108

Why it matters

Summary

A correct value in the wrong coordinate system

Direction was data, not grammar

One service call, one bearer request, one local join

Description, setup and traffic were three different things

Security belonged to the envelope

The history is a warning against portable words

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing