Summary

  • RFC 3037 recommended implementing base LDP for devices that perform MPLS forwarding along normally routed, destination-based paths; it did not make LDP mandatory for every MPLS device or prove that any instance was configured and operating.
  • The document separated base hop-by-hop label distribution from explicitly routed traffic engineering and exposed several independent receipts: discovery, TCP connection, parameter agreement, operational session, binding exchange, retained state, programmed forwarding and observed traffic.

The most easily overread word in RFC 3037 is not a protocol name. It is “recommended”. In one short requirement-level section, the document recommended implementing LDP on devices that perform MPLS forwarding along normally routed paths chosen by destination-based routing. That was a bounded engineering judgment. It was not a universal mandate, an implementation certificate or a report from a running network.

Published in January 2001 as an Informational RFC, the document answered an applicability question: where did base LDP fit among several possible ways of distributing MPLS labels? Its answer drew a boundary around the ordinary routed path. Reading that boundary accurately requires refusing to let protocol suitability stand in for operational fact.

The path in scope was the normally routed path

MPLS forwarding required adjacent Label Switching Routers to share the meaning of the labels used between and through them. LDP supplied procedures by which one LSR announced a binding it had made. RFC 3037 described those procedures as supporting label distribution along paths already selected by destination-based routing—MPLS hop-by-hop forwarding.

That role could bridge heterogeneous machinery. LDP, an IP routing plane and software capable of programming ATM or Frame Relay cross-connects could carry IP through switching networks without a separate overlay or technology-specific addressing and routing system. Stand-alone LDP also avoided requiring the same piggyback-capable routing protocol at every hop.

Each “could” has a limited object. The architecture could remove one dependency; it did not prove that cross-connect software existed on a named switch, that every hop formed a session, or that a resulting path carried traffic. Applicability identified a way to assemble the system. It did not report that the assembly had occurred.

The same boundary separated base LDP from traffic engineering. Explicitly routed LSPs need not follow the path ordinary routing would select. RFC 3037 named CR-LDP and RSVP-TE extensions as two possible setup mechanisms and recorded that there was then no consensus about technical superiority. Administrators were to choose according to their needs and situation. Base LDP's extension mechanism made additional work possible; it did not make an extension part of the base protocol merely because the extension point existed.

Recommendation attached to a function, not to every box

The requirement statement was precise: implementation was recommended for devices that performed MPLS forwarding along normally routed, destination-based paths. The condition matters. A device outside that function did not become noncompliant merely because it lacked base LDP, and a device containing LDP code did not become operational merely because the applicability statement favoured it.

Implementation is only one receipt. Software may be present while the feature is disabled. An enabled process may discover no peer. Discovery may not lead to a TCP connection. A connection may fail parameter negotiation. An operational session may exchange no useful binding. A binding may never reach the forwarding table. A programmed label may see no packet.

The standard could recommend the first capability without observing any of the later states. That is not a weakness in the document. It is the reason the recommendation can travel across products and operators without pretending to know their runtime.

A session was a sequence, not a single green light

RFC 3037 summarized the LDP control path in ordered steps. Discovery found a potential peer. Session setup established a TCP connection. The peers negotiated parameters, including the label distribution method. Only after agreement did the session become operational for label distribution.

TCP provided reliable delivery for session messages, allowing distributed labels and associated LSP state to avoid periodic refresh. But reliability belonged to the byte stream. It did not prove that a peer accepted the intended meaning, that a binding remained aligned with routing, that forwarding hardware had been programmed or that a packet reached its destination.

The lack of periodic binding refresh also changed the evidence burden. Durable state was efficient, yet an operator investigating a later forwarding failure could not infer freshness from the absence of retransmission. Session continuity, routing dependency, binding lifecycle and data-plane use needed their own timestamps.

The mode menu encoded a resource argument

LDP did not prescribe one universal combination of behaviour. In Downstream Unsolicited mode, an LSR advertised a FEC-label binding when it was ready to forward that FEC. In Downstream on Demand mode, it answered a specific request. Liberal retention kept labels learned from peers even when they were not immediately needed; conservative retention released the unused ones. Independent control allowed an LSR to advertise when it saw fit; ordered control waited for a binding from the FEC next hop or for egress status.

RFC 3037 grouped these choices around scarcity. When label values were constrained, as on ATM and Frame Relay links, it called on-demand distribution, conservative retention and ordered control appropriate. When labels were plentiful, unsolicited distribution, liberal retention and independent control could make a next-hop change faster because useful labels were already present.

“Appropriate” was conditional, not absolute. The protocol permitted other combinations and hybrid variants. Conserving labels traded away retained alternatives; keeping alternatives consumed state. Advertising early changed when an upstream claim appeared; waiting changed setup dependency. The document supplied a decision surface, not a benchmark showing which choice won in every network.

Required capability could still be disabled

The loop-detection rule made the capability-versus-state distinction explicit. LDP defined a mechanism to protect LSPs crossing non-TTL MPLS clouds. A compliant LSR had to implement it, yet an operator could disable it by configuration.

One device could therefore truthfully report conformance and truthfully report that loop detection was off. Even an enabled device did not establish domain-wide protection. The useful evidence chain was implementation support, local configuration, peer parameters, propagated path-vector or hop information, route state and observed forwarding.

The extension mechanism had the same limit. LDP defined how to introduce new messages and TLVs, detect unrecognized ones and respond when an implementation did not support them. RFC 3037 warned that not every future enhancement could be backward compatible. A clean unknown-TLV procedure made evolution safer; it did not prove that two peers shared a particular extension.

Scalability claims named costs, not capacities

The document described why incremental distribution could scale: bindings did not need periodic refresh. It also named the opposing costs. Scarce-label modes limited allocation. Liberal retention reduced redistribution after a next-hop change. The number of TCP connections an implementation supported bounded its peer count. Path-vector loop detection added memory, processing and control traffic.

None of those statements supplied a numerical capacity for a product. An operator still needed observed peer counts, label-space use, memory, CPU, message rates, reconvergence behaviour and forwarding results. A protocol property explains which counters may matter; it is not the counter reading.

Security was similarly narrow. Optional TCP MD5 could make it harder to inject spoofed segments into an LDP session stream. That did not authenticate a FEC as legitimate, authorize a route, prove the truth of a binding or secure the application carried by the resulting LSP.

Later consensus did not rewrite the earlier snapshot

RFC 3037 captured a moment when CR-LDP and RSVP-TE were both prospective answers for explicitly routed LSPs and the document recorded no technical-consensus winner. RFC 3209, RFC 3212 and RFC 3213 subsequently specified the two branches in more detail.

In February 2003, RFC 3468 recorded a later working-group and IESG decision to focus new MPLS signalling work on RSVP-TE and undertake no new CR-LDP work. It deliberately left existing CR-LDP RFC statuses intact and did not prohibit individual contributions. That decision is evidence of a standards-work allocation at a later date. It is not evidence that every operator migrated, that every implementation disappeared, or that the uncertainty written in January 2001 was false when published.

The historical lesson is a discipline of verbs. A standards body recommends. A vendor implements. An operator enables. Peers discover, connect and agree. A control plane distributes. Hardware installs. Packets traverse. RFC 3037 was clear about the first verb. The rest still needed receipts.

Sources

Lu Heng did not author or endorse RFC 3037 or the related standards. His essays are used here as disclosed analytical lenses.