Application-Aware Targeted LDP
updates
- rfc-7473 — Controlling State Advertisements of Non-negotiated LDP Applications
Extracted elements (25)
Applications such as remote LFAs and BGP auto-discovered pseudowires automatically initiate asymmetric Extended Discovery to any LSR without explicit configuration on the remote LSR. The TAC mechanism was introduced because the responding LSR otherwise has no information about the targeted application to control session acceptance or apply per-application limits.
TAC and SAC are complementary: TAC enables symmetric awareness and controls which applications can be advertised at all, while SAC allows asymmetric disabling of receipt for specific already-negotiated applications. TAC should be used when the responding LSR is not aware of the targeted application; SAC should be used when the responding LSR is explicitly configured for the application.
If the receiver LSR does not receive the TAC TLV in the Initialization message, or does not understand it, TAC negotiation is considered unsuccessful and session establishment proceeds per RFC 5036 without application-aware controls.
This document updates RFC 7473 to enable advertisement of LDP FEC label bindings over tLDP sessions based on TAC-negotiated applications, with TAC taking precedence over SAC for enabling applications and SAC taking precedence over TAC for disabling advertisements.
After a configuration change renegotiating TAC via the Capability message, if there is no common TAE between the new and peer TAE lists, the LSR MUST send a 'Session Rejected/Targeted Application Capability Mismatch' Notification and close the session.
After a tLDP session using the TAC mechanism is established, both LSRs MUST distribute FEC label bindings for the negotiated applications only. An LSR operating in downstream on-demand mode MUST request FEC label bindings for the negotiated applications only.
By default, an LSR SHOULD accept tLDP Hellos in order to then accept or reject the tLDP session based on the application information. An LSR SHOULD allow configuration of any TA-Id to facilitate private TA-Ids by network operators.
For determining correspondence between targeted applications and application state per RFC 7473, an LSR MUST use defined mappings: LDPv4 Tunneling to IPv4 Prefix-LSPs, LDPv6 Tunneling to IPv6 Prefix-LSPs, LDP FEC 128 PW to FEC 128 P2P-PW, etc.
If a receiver LSR receives the same TA-Id in more than one TAE, it MUST process the first element and ignore duplicates. If it receives an unknown TA-Id, it MUST silently ignore that TAE and continue processing the rest of the TLV.
In the Initialization message, the S-bit of the TAC TLV MUST be set to 1, and the E-bit of each TAE MUST be set to 1 to enable the targeted application.
On receipt of a valid TAC TLV, an LSR MUST generate its own TAC TLV. If at least one common TAE exists between the received and generated TAC TLVs, the session MUST proceed to establishment; otherwise the LSR MUST send a 'Session Rejected/Targeted Application Capability Mismatch' Notification and close the session.
The initiating LSR SHOULD tear down the corresponding tLDP adjacency after sending or receiving a 'Session Rejected/Targeted Application Capability Mismatch' Notification message.
The SAC mechanism MUST take precedence over the TAC mechanism with respect to disabling state information advertisements. A peer MUST NOT send state information for an application if the other peer announced disinterest via SAC, even if the application was negotiated via TAC.
The TAC is advertised on tLDP sessions only. If the tLDP session changes to a link session, an LSR SHOULD withdraw the TAC with the S-bit set to 0. Similarly, if a link session changes to tLDP, an LSR SHOULD advertise the TAC via the Capability message.
The TAC mechanism MUST take precedence over the SAC mechanism with respect to enabling applications. LDP peers MUST NOT advertise state information for a non-negotiated application even if a peer sends a SAC TLV expressing interest in it.
The U-bit of the TAC TLV MUST be set to 1 to indicate that this capability must be silently ignored if unknown.
When the responding LSR playing the active role receives a 'Session Rejected/Targeted Application Capability Mismatch' Notification, it MUST set its session setup retry interval to 0xFFFF (maximum). When it detects a configuration change pertaining to TAC, it MUST clear the session setup backoff delay to reattempt session establishment.
Each targeted application is mapped to specific LDP FEC element types. For example, LDPv4 Remote LFA maps to IPv4 prefix FECs, LDP FEC 129 PW maps to Generalized PWid FEC elements, and mLDP Tunneling maps to P2MP, MP2MP-up, MP2MP-down, HSMP-downstream, and HSMP-upstream FECs.
The Targeted Application Capability (TAC) TLV is a new LDP capability TLV used to advertise and negotiate a list of targeted applications during tLDP session initialization. It is encoded as a standard LDP capability TLV with Capability Data containing one or more Targeted Application Elements (TAEs).
IANA assigned status code 0x0000004C with E-bit=1 ('Session Rejected/Targeted Application Capability Mismatch') in the 'Status Code Name Space' sub-registry of the 'LDP Parameters' registry.
IANA assigned TLV code point 0x050F ('Targeted Application Capability') in the 'TLV Type Name Space' sub-registry of the 'LDP Parameters' registry.
IANA created a new 'LDP Targeted Application Identifier' registry (range 0x0001-0xFFFE) under 'LDP Parameters'. IETF Review governs 0x0001-0x1FFF; First Come First Served governs 0x2000-0xF7FF. Initial values include LDPv4/v6 Tunneling (0x0001-0x0002), mLDP Tunneling (0x0003), Remote LFA (0x0004-0x0005), FEC 128/129 PW (0x0006-0x0007), and others through 0x000D.
This document does not introduce new security changes to LDP beyond RFC 5036. DoS attacks via Extended Hellos can be mitigated by filtering using access lists defining permitted addresses for Extended Discovery. Additionally, with TAC, the tLDP session is only established after successful TAC negotiation, and LSRs MUST only advertise TA-Ids they are configured to support.
The TAC TLV uses the standard LDP TLV encoding with U-bit set to 1, a 16-bit TLV Code Point (0x050F), and a Length field. The Capability Data contains zero or more TAEs, each a 32-bit field with a 16-bit TA-Id and a 1-bit E-bit (Enable) followed by reserved bits.
The Targeted Application Element (TAE) is a 32-bit structure: a 16-bit TA-Id identifying the targeted application, a 1-bit E-bit (1=advertising, 0=withdrawing), and 15 reserved bits.