Summary

  • RFC 5376 allowed an inter-AS PCE response to carry an opaque path-segment identifier, preserving a provider's topology and commercial confidentiality without turning the identifier into proof of LSP establishment or traffic delivery.
  • Because a source PCC might neither see nor fully trust every downstream PCE, the architecture needed a later mechanism by which each AS could verify that signaling expanded the segment its own PCE had actually computed.
  • Requests, policy decisions, computed segments, signaling, reservations, forwarding observations and application outcomes are separate receipts; cumulative cost is also meaningful only under a declared, comparable metric policy.

A useful answer with a narrow meaning

The attractive fiction in cross-domain automation is that one successful response closes the whole transaction. A requester supplies endpoints and constraints, a path computation element returns an answer, and the dashboard marks the service ready. RFC 5376 resists that compression. Its subject is the information that PCEs and path computation clients need when computing an MPLS or GMPLS traffic-engineered path across autonomous systems. It is a requirements document, published as Informational in November 2008, not a claim that the later control plane or data plane has already done its work.

The source PCC may send a request to an inter-AS PCE. That PCE can consult another inter-AS PCE or one or more intra-AS PCEs. The source need not know the identities, internal graphs or policy engines behind each contributed segment. This lets separate operators cooperate without creating one omniscient controller. It also means the source cannot infer a complete trust chain merely because one peer returned syntactically valid PCECP data.

The response is evidence of computation under particular inputs and policy at a particular time. It can expose AS numbers or AS border routers where disclosure is acceptable. Where it is not, the response can carry a path-segment identifier: a compact reference standing in for hidden intra-domain hops. That reference enables composition. It does not prove that the identifier was expanded during signaling, that the expanded route matched the earlier computation, that resources were available, that an LSP became operational, or that user traffic reached its destination.

Calling the token a receipt for those later events would make confidentiality do the work of observation. An opaque value can faithfully name a concealed result while saying nothing about whether a separate actor later used that result. The evidence chain remains open until each consequential transition produces its own record.

Confidentiality created a verification obligation

The privacy benefit is real. Providers can have security and commercial reasons not to expose their topology, available capacity or detailed engineering choices. A cooperative PCE chain can even conceal the existence of a downstream PCE from parties other than its direct peer. RFC 5376 therefore requires inter-AS computation to support useful abstraction instead of demanding that every participant reveal its internal graph.

The cost of abstraction is not ignorance; it is a more precise handoff. RFC 5376 says an AS needs a mechanism, reflected in the corresponding signaling, to verify that the signaled path conforms to the segment computed by its local PCE. The local PCE is the authority for the hidden segment. The opaque identifier is the reference it issues. Later expansion is a distinct act that must remain bound to the earlier decision.

This prevents a subtle substitution. Suppose a downstream domain returns key K for a path satisfying the stated bandwidth, protection and border conditions. A later signaling component expands K to some internal route. If the owner cannot compare that expansion with what its PCE committed to, the source may receive a seemingly successful setup while the hidden domain has silently substituted another segment. The source cannot inspect the internal hops, so verification must occur where the facts and authority live: inside the owning AS, with a result that can be recorded without revealing the entire topology.

The principle is not that every party must see everything. It is that concealment must not erase accountability at the boundary where a reference becomes an action. An operator can disclose a stable segment identifier, a computation context and a conformity result while retaining the sensitive graph. Minimum disclosure and auditable execution reinforce one another when the receipts are designed deliberately.

The request crossed a policy border

An inter-AS request carries more than two endpoints. It may identify desired or excluded ASes and ASBRs and indicate whether a hop is mandatory. It can ask for protection, diversity or disjointness, with the important question of whether the property applies end to end or only within one AS. It also carries the requesting AS number so the receiving PCE can apply its own local policy.

That local policy is not a nuisance outside the protocol. It is part of the decision. A provider may reject the request. It may change priority or reinterpret bandwidth, fast-reroute, DS-TE class and related parameters. A constraint expressed for MPLS may need translation when it enters a GMPLS domain. Two fields that share syntax need not carry identical operational meaning on both sides of an administrative boundary.

The reply should therefore preserve policy provenance: which requester supplied the demand, which PCE evaluated it, which AS owned the relevant resources, which constraints were accepted, which were modified and which caused rejection. “Path found” without that context invites a later system to treat a locally qualified answer as an unconditional promise.

A policy rejection is not evidence that PCE failed. It may be the clearest evidence that distributed authority worked. The remote domain retained the right to decide how its resources could be used. Conversely, authentication of a PCE peer proves an identity or credential relationship; it does not authorize every request, every AS sequence or every resource claim that the peer can encode.

Cost crossed the boundary; comparability did not

RFC 5376 permits a response to report cumulative inter-AS path cost. It explicitly leaves normalization of that cost outside scope. That omission matters. A number can be correctly transported and correctly summed while remaining unsuitable for comparison if domains use different metrics, scales, objectives or policy adjustments.

A control plane that ranks candidate paths by the largest-looking or smallest-looking returned number without proving comparability has manufactured an optimization claim. The figure may combine delay-like weights in one domain, administrative preferences in another and a transformed GMPLS constraint in a third. The arithmetic is reproducible; the semantics are not yet common.

This also limits statements about global optimality. Per-domain computation can produce a workable constrained path without guaranteeing the best end-to-end answer. An operator should record the objective function, metric version, domains included, normalization policy and constraints omitted before describing a path as optimal. Otherwise “lowest cost” is merely a label attached after several independent authorities made locally rational choices.

The practical lesson is to keep cost as attributed evidence. Store what each domain supplied, how a coordinating PCE combined it and which policy transformed it. If a common metric policy is later adopted, older records can be re-evaluated. If the system stores only the final scalar, the original uncertainty becomes irreversible.

Trust followed peers, not the entire chain

PCE peers need to authenticate identities, validate exchanged data and protect sensitive communication. RFC 5376 points toward encryption and key-management discipline suitable for communication that crosses AS boundaries. Later PCEP and TLS specifications improved the concrete transport mechanisms, but they did not convert a cooperative topology into universal trust.

The distinction is structural. A source PCC may authenticate the PCE it contacts. That PCE may rely on a second PCE, which may rely on a local engine. The source's secure session terminates at its peer; it does not automatically attest every downstream computation. A chain of trust is recommended, yet the requirements acknowledge that such a chain may not always be available.

Policy objects sharpen the point. A transport may carry an opaque policy object unchanged to a policy component. If stronger origin, integrity or authorization checks are required for the policy itself, the components that understand it must perform them. A protected envelope cannot validate semantics it does not interpret.

The correct evidence record therefore names both the transport peer and the authority that made each substantive decision. It distinguishes successful message protection from authorization, local computation from composition and a path key from its signaling-time expansion. This is the same discipline that prevents an authenticated API call from being mistaken for approval of everything inside its payload.

Six receipts instead of one green state

A defensible inter-AS workflow can be represented as six linked but independent records:

  1. the request receipt: endpoints, requesting AS, desired and excluded ASes or ASBRs, mandatory flags, bandwidth, protection, diversity and policy context;
  2. the policy receipt: the evaluating authority, accepted constraints, rewrites, rejection reasons and metric interpretation;
  3. the computation receipt: contributing PCEs where disclosable, algorithm and state version, explicit hops or opaque segment references, and uncertainty;
  4. the conformity receipt: evidence from the owning AS that later signaling expanded the exact locally computed segment;
  5. the setup receipt: RSVP-TE or another signaling result, reservation state, assigned labels and operational LSP state;
  6. the outcome receipt: forwarding telemetry, packet delivery, service-level observation and application acknowledgement.

Only the first three belong to a successful computation response. The fourth protects the opaque handoff. The fifth concerns establishment. The sixth belongs to operations and the application. A system may correlate them under one intent identifier, but it should never overwrite them with a single status called success.

This separation also supports reversal. A domain can withdraw a segment reference, reject a changed request, rotate a peer credential or recompute after topology change without pretending the previous path never existed. Auditors can see which conclusion was valid at which time. A later failure does not falsify the earlier computation; an earlier computation does not excuse a later setup failure.

What the requirements did not promise

RFC 5376 did not specify the signaling mechanism that expands a path-segment identifier. RFC 5520 later defined path keys for confidentiality, while RFC 5440 specified PCEP. Hierarchical PCE, stateful extensions and TLS protection later extended the architecture. These developments add control surfaces and evidence opportunities. They do not collapse the stages.

Nor does an opaque segment reveal the hidden internal route to the source. That is the point. Verification can prove conformance without publishing every hop. A claim that the requester knows the exact internal path would defeat the confidentiality contract; a claim that nobody can verify it would defeat accountability. The design space lies between those extremes.

Finally, no standards text here proves a present provider deployment, a commercial agreement, a measured performance result or a delivered service. Those questions require current operational evidence. The durable contribution of RFC 5376 is narrower: it described what inter-AS computation had to express so independently governed domains could cooperate without surrendering policy or topology.