MPLS Generic Associated Channel (G-ACh) Advertisement Protocol
Extracted elements (34)
GAP messages include no checksum by design; integrity is optional and achieved via the authentication mechanism in Section 6. This avoids mandatory processing overhead for deployments that rely on lower-layer integrity guarantees.
The authentication design is based on IS-IS generic cryptographic authentication (RFC 5310) with a shared Key ID scheme that supports multiple simultaneously active keys to facilitate key migration without service interruption.
The GAP is designed around simplicity and one-way information distribution; how the receiver uses advertised data is a local matter outside the protocol scope. This contrasts with negotiation-based protocols, reducing complexity and avoiding oscillation between peer configurations.
The GAP provides no fragmentation and reassembly mechanism. This responsibility is explicitly delegated to applications that need to send data larger than the path MTU, keeping the core protocol simple and avoiding a feature rarely needed by OAM use cases.
For device discovery on a data link, GAP messages must be multicast since the sender does not initially know listener link-layer addresses. The correct destination Ethernet MAC for GAP packets carrying only the GAL (label value 13) is 01-00-5e-80-00-0d per RFC 5332.
All GAP data and peer state retained from prior advertisements MUST be discarded after a system restart to prevent incorrect operation on stale data. All GAP applications MUST be disabled by default and require explicit operator enablement.
Any auto-configuration based on GAP information MUST be disabled by default. The receiver SHOULD prevent oscillation where each endpoint tries to adjust its configuration to match the other.
Clock corrections SHOULD be monotonic to avoid replay attacks, unless operator intervention overrides the monotonic setting. MAC truncation is NOT RECOMMENDED as it reduces authentication strength.
Data sent and received by the GAP MUST be made accessible for operator inspection. Where local configuration is updated by received information, the reason for the change MUST be clear.
Malformed GAP messages MUST be discarded by the receiver, though an error MAY be logged. Remote error logging SHOULD apply rate limiting to prevent excessive log traffic.
Message transmission timers SHOULD be randomized across logical channels on the same physical interface to reduce the likelihood of large synchronized message bursts.
On multipoint channels, a Source Address TLV is REQUIRED. In IP networks, a Source Address SHOULD be included and set to an IP address of the sending device (interface address when the channel is a link). In non-IP MPLS-TP networks, it SHOULD be set to the channel endpoint identifier.
Refresh times SHOULD be set so that at least three updates are sent prior to Lifetime expiration. For example, a Lifetime of 210 seconds requires updates at least once every 60 seconds.
The ACH for Channel Type 0x0059 (GAP) SHALL NOT be followed by the ACH TLV Header defined in RFC 5586. Reserved fields MUST be sent as zero; implementations MUST ignore reserved field values on receipt.
The GAP MUST NOT be used to send TLVs in cleartext where the value requires confidentiality, such as TLVs containing bare cryptographic keying material. Applications requiring confidentiality must implement their own confidentiality mechanism.
The Message Identifier (MI) MUST NOT be assumed to be a sequence number. A sender MUST NOT reuse an MI over a given channel until confident all ADBs associated with it have been expired by the receiver.
Use of GAP message authentication is RECOMMENDED. HMAC-SHA-1 MUST be supported; HMAC-SHA-256 MAY also be supported. The Authentication Keystring SHOULD NOT be a human-memorable string; implementations MUST support random binary values of appropriate length.
When an ADB element for the GAP application (Application ID 0x0000) is present in a GAP message, it MUST precede other elements. Application 0x0000 GAP messages MUST be processed in the order received.
The G-ACh Advertisement Protocol (GAP) operates by having a configured endpoint transmit GAP messages over the G-ACh associated with an MPLS LSP, pseudowire, or section. Messages carry a collection of TLV objects organized per-application, identified by Application IDs from an IANA registry.
The Lifetime field (16-bit, seconds) in an ADB element specifies how long the receiver should retain static TLV data. A Lifetime of zero causes data to be immediately marked as expired; if no TLVs are present in the ADB, all previously received data for that application is expired.
IANA allocated Channel Type 0x0059 in the 'MPLS Generalized Associated Channel (G-ACh) Types' registry for the G-ACh Advertisement Protocol.
IANA allocated three Address Family Numbers for MPLS-TP endpoint identifiers: 26 (MPLS-TP Section Endpoint Identifier), 27 (MPLS-TP LSP Endpoint Identifier), and 28 (MPLS-TP Pseudowire Endpoint Identifier).
IANA created the 'G-ACh Advertisement Protocol Application Registry' under Generic Associated Channel (G-ACh) Parameters, with Application ID range 0x0000–0xFFFF, IETF Review allocation policy, and initial entry 0x0000 for the GAP itself.
IANA created the 'G-ACh Advertisement Protocol: GAP TLV Objects (Application ID 0)' registry with Type ID range 0–255, IETF Review allocation policy, and initial entries: Source Address (0), GAP Request (1), GAP Flush (2), GAP Suppress (3), GAP Authentication (4).
GAP messages are sent in cleartext. An unauthorized party with access to the MPLS data plane can observe message content. Confidentiality is not guaranteed by the protocol; sensitive data requiring confidentiality must not be sent via GAP without application-level encryption.
Unauthorized transmission or manipulation of GAP messages can corrupt receiver state about legitimate senders. Message authentication using HMAC (Section 6) provides authenticity and integrity. The Timestamp field enables replay-attack protection when checked against current time within a reasonable tolerance.
Application Data Block (ADB) element format: Application ID (16 bits), Element Length (16 bits, total including Application ID and Element Length fields), Lifetime (16 bits, seconds), Reserved (16 bits), followed by zero or more TLV objects.
GAP Authentication TLV (Type=4): Reserved (16 bits), Key ID (16 bits), followed by Authentication Data containing the MAC output. The Authentication Data field is set to all zeros before MAC computation and then overwritten with the computed MAC.
GAP Flush TLV (Type=2): a null object (Length=0) instructing the receiver to flush all GAP data for the (sender, channel) pair. Application data in the same message is still processed normally; the flush does not apply to data in the carrying message.
GAP message header follows the ACH and contains: Version (4 bits, set to 0), Reserved (12 bits), Message Length (16 bits, octets after ACH), Message Identifier (32 bits), and Timestamp (64-bit NTP transmit timestamp per RFC 5905 Section 6).
GAP Request TLV (Type=1): requests the receiver to transmit an immediate unicast GAP update. If Length is zero, an update for all applications is requested; otherwise Value contains a sequence of 16-bit Application IDs specifying which applications to update.
GAP Suppress TLV (Type=3): requests the receiver to cease sending GAP updates for a Duration (16-bit seconds). If Length=2 (empty Application ID list), suppression of all GAP messages is requested; otherwise only the listed applications are suppressed. Duration=0 cancels existing suppress requests.
GAP TLV object format: Type (8 bits, scoped to application), Reserved (8 bits), Length (16 bits, octets of Value field, no padding required), followed by variable-length Value. GAP messages contain no checksum.
Source Address TLV (Type=0): Reserved (16 bits), Address Family (16 bits, from IANA Address Family Numbers registry), followed by variable-length Address field indicating the sending device or channel endpoint.