Summary
- RFC 3186 made a shared MAPOS network look like a transparent point-to-point PPP link by rewriting one or two header octets at the edges, not by eliminating the intermediate network.
- The real path depended on two port modes, an unused MAPOS address pair, stable forwarding in both directions and per-path isolation. Its OAM database described the path but did not forward a frame.
Published in December 2001, MAPOS/PPP Tunneling mode was Informational. The IESG note was unusually direct: it was neither an IETF working-group product nor Standards Track and had not necessarily received the review depth of a standards-track document. The memo documented a design and a reference experiment. It did not certify broad adoption.
The design exploited resemblance. PPP over SONET/SDH placed fixed address and control values at the start of a frame. MAPOS put its own destination in roughly the same space. An ingress switch could replace the fixed PPP bytes with the MAPOS address assigned to the far customer port. The fabric forwarded on that value. The egress switch restored the fixed PPP values. MAPOS version 1 rewrote one octet; MAPOS 16 rewrote two.
This was not another encapsulation wrapped around the customer frame. RFC 3186 emphasized that it added no header overhead. Yet “no new header” did not mean “no new state.” The state moved into switches: peer address, rewrite function, port mode, signal label, internal route and isolation rule.
Turning a port into PPP tunneling mode was a bundle of operations. The switch disabled Node Switch Protocol and Switch-Switch Protocol activity on the customer-facing port, disabled MAPOS broadcast and multicast forwarding there, changed the SONET/SDH Path Signal Label for the selected scrambling mode, and enabled rewriting to a specified destination. Returning to native MAPOS reversed the sequence.
A configuration screen might compress that sequence to one mode value. Running code could not. Each operation had its own success or failure. The label could change while rewriting did not; one end could enter the mode before the other; internal reachability could still be converging. The useful historical object is therefore not “PPP mode = true” but the transition and its receipts.
Path establishment made the control boundary explicit. Operators chose two unused MAPOS addresses corresponding to the two edge ports. They configured both ports, waited for routes and frame forwarding to become stable in both directions, then allowed the customer-facing link to come up. PPP LCP controls could pass transparently only after that point. Until it was reached, the link was supposed to remain down.
The customer saw a link. The operator held the address pair that made the link possible. RFC 3186 recommended managing that pair in a path database, partly to prevent duplicate paths. Its example row recorded user, speed, framing mode, address pair and status. Then the memo drew the boundary that modern control panels often blur: the database was for operations, administration, management and provisioning. It was not used to forward frames.
An “up” row was thus a statement about a service, not the service’s mechanism and not a packet-delivery receipt. Internal SSP state still selected reachability. Edge switches still performed rewriting. Ports still had to be enabled. A record could be correct while a later frame was lost, or stale while forwarding had changed.
Removal also separated declaration from execution. Operators disabled the two customer-facing ports, could update the path database, and could later return detached ports to native MAPOS defaults. Frames arriving after the destination port had been disabled were silently discarded. Silence did not tell the sender which step had occurred or whether the inventory had caught up.
Failure visibility was asymmetric by design. Each customer optical path terminated at its local MAPOS edge. If the near CPE-to-switch link failed, the near side saw SONET/SDH alarms. The far physical interface could remain up because the alarm was not transported through the cloud. Only after PPP LCP Echo expired would the far endpoint report the revealing split: link up, line protocol down.
That timeout was useful evidence, but bounded. It showed that expected echo traffic had not completed in time. It did not locate the break, identify a switch, distinguish one-way loss from a total failure or prove what an application experienced. Inside the cloud, SSP could react to topology change while the endpoint still knew only its end-to-end symptom.
Transparency also did not make a shared link dedicated. MAPOS had no protocol-level quality-of-service control, and POS had no flow control. RFC 3186 said end-to-end throughput was difficult to guarantee, asked operators to provision sufficient inter-switch bandwidth and recommended per-port fairness for oversubscribed designs. The private-wire appearance could coexist with shared capacity and operator-chosen queuing.
The reference implementation offered measured latency, not universal truth. Its test used named equipment, unidirectional OC12c traffic at 30 percent load, fixed framing choices, 25 trials of 150 seconds per frame size and confidence intervals rounded to the tester’s resolution. Under those conditions, the MAPOS switch was faster than the compared router. That result did not measure every load, loss pattern, fairness policy, vendor or application.
The security section is where “transparent” becomes most dangerous as a slogan. The memo argued that a CPE could not directly control the internal MAPOS network in tunneling mode and would find it difficult to inject another stream. It nevertheless called per-path isolation extremely important, warned against path duplication and advised against mixing native MAPOS with PPP tunneling until every switch implemented isolation.
The underlying framing carried no source-address field. In a mixed environment, that absence made isolation harder. The endpoint’s inability to see the fabric was not proof that the fabric could never confuse two paths. Correct separation remained a claim about all participating switches and the operator’s configuration.
RFC 3186 therefore records a recurring Internet bargain. Abstraction made a complex shared network usable as a familiar point-to-point link. It also concentrated decisive evidence on the provider side. To reconstruct what happened, one needs the service order, address pair, two port identities, transition steps, rewrite destinations, directional convergence, database revision, isolation state, keepalive observations and frame evidence. The customer’s clean interface is only one layer of that history.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
