IS-IS Flooding Scope Link State PDUs (LSPs)
Extracted elements (31)
Circuit scope flooding was introduced because IIHs — the only existing circuit-scope PDU — are unreliable; individual IIHs may be lost without affecting protocol correctness. When circuit-scope information (e.g., TRILL Appointed Forwarder data per RFC 7176) exceeds a single PDU or requires reliability, periodic retransmission is inefficient and still cannot guarantee delivery.
RFC 5311 provides a backwards-compatible solution to the 256-LSP-per-IS limit but requires alias system IDs and imposes restrictions on Extended LSP content. FS-LSPs provide a less constrained alternative, explicitly accepting non-interoperability with legacy routers as a trade-off.
Standard TLVs are limited to 255 octets because of their 8-bit Type and Length fields. When sub-TLV usage grows, splitting object information across multiple TLVs requires repeating identifying keys and increases receiver complexity. Extended TLVs with 16-bit fields solve this without that overhead.
The 5-bit PDU Type field caps IS-IS at 32 PDU types. To conserve this scarce space, new PDUs carry a Scope field so that multiple flooding scopes share the same PDU type codes (FS-LSP=10, FS-CSNP=11, FS-PSNP=12), allowing future scopes without new PDU type allocations.
Domain scope (DFS/E-DFS) is not yet applicable to Layer 2 IS-IS deployments because current Layer 2 standards (e.g., RFC 6325) support only a single area. Domain scope for Layer 2 will be fully definable when multi-area Layer 2 support is standardized.
FS PDU extensions are not backwards compatible with legacy IS-IS implementations. Legacy routers do not support the FS Update Process and will likely treat received FS PDUs as errors. Correct operation requires that all routers in the flooding domain of a given scope support both FS PDUs and that specific scope.
A Scope field value of 0 is reserved and MUST NOT be used. Received FS-LSPs with scope 0 MUST be ignored and MUST NOT be flooded; received FS-CSNPs and FS-PSNPs with scope 0 MUST be ignored.
Circuit scope FS-LSPs (scopes L1CS, L2CS, E-L1CS, E-L2CS) MUST NOT be flooded on any circuit other than the one on which they were received or locally generated; their FS-LSDB is circuit-specific and contains only FS-LSPs with matching scope on that circuit.
Domain scope FS-LSPs (DFS, E-DFS) MUST be flooded on all circuits regardless of which levels are supported on that circuit.
Extended TLVs and extended sub-TLVs MUST be used together; mixing standard sub-TLVs inside an extended TLV, or extended sub-TLVs inside a standard TLV, is invalid. A given flooding scope supports either standard or extended TLV formats, but not both.
For LxFS/E-LxFS FS-LSPs to be usable by the Decision Process, a valid standard LSP #0 from the same IS at the corresponding level MUST be present in the LSDB. Information supporting use of the originating IS as a transit node MUST NOT be used when the Overload bit is set in that standard LSP #0.
If future sub-sub-TLV levels are introduced, the Type and Length field sizes in those new sub-types MUST match the size used in the parent, preserving consistent encoding depth.
Information in the Scope Flooding Support TLV (type 243) MUST NOT be considered in adjacency formation; it is purely informational for scope deployment validation and troubleshooting.
On point-to-point circuits, when a new adjacency reaches the UP state, FS-CSNPs for all supported scopes MUST be sent and the SRM bit MUST be set for all FS-LSPs associated with the supported scopes, ensuring FS-LSDB synchronization from the start.
Receipt of an FS-PSNP with U=1 MUST cause the SRM bit to be cleared for all FS-LSPs with the matching scope currently marked for flooding on that circuit, suppressing retransmissions to a neighbor that cannot process that scope.
Routers supporting FS PDUs SHOULD send PSNPs with U=1 when an FS-LSP is received for an unsupported scope, and SHOULD trigger management notifications for both unsupported-scope FS PDU receipts and received U=1 PSNPs.
TLVs that are restricted to standard LSP #0 MUST NOT appear in LxFS LSPs.
When an FS-LSP is purged, the original state of the P (priority) bit MUST be preserved so that priority information survives the purge lifecycle.
When IS-IS is deployed for Layer 3 routing, FS-LSP #0 with domain scope MUST include at least one of: IPv4 Traffic Engineering Router ID (TLV 134) or IPv6 Traffic Engineering Router ID (TLV 140), enabling receivers to determine reachability to the originating IS across area boundaries.
Each supported flooding scope maintains an independent FS-LSDB and a corresponding instance of the Update Process. Flooding of FS-LSPs, FS-CSNPs, and FS-PSNPs is limited to circuits participating in the given scope; consistent scope support on a circuit by all attached routers is required.
Four circuit scope flooding identifiers are defined: L1CS (scope 1, standard TLVs), L2CS (scope 2, standard TLVs), E-L1CS (scope 64, extended TLVs), and E-L2CS (scope 65, extended TLVs). All use the FS LSP ID Extended format. The FS-LSDB is specific to both the scope and the individual circuit.
Four level-flooding scopes extend LSP set capacity without alias system IDs: L1FS (scope 3), L2FS (scope 4), E-L1FS (scope 66), E-L2FS (scope 67). All use the FS LSP ID Extended format, providing 64K additional LSPs per IS per level. LxFS LSPs are used by the level-specific Decision Process as additional information from the same IS.
The Scope Flooding Support TLV (type 243, length 1–127) is carried in IIH PDUs to announce which flooding scopes an IS supports on a circuit. Each value byte encodes a 7-bit Supported Scope and a Reserved bit. In L1 LAN IIHs, L2 and L2 circuit scopes MUST NOT be advertised; in L2 LAN IIHs, L1 and L1 circuit scopes MUST NOT be advertised.
Two domain flooding scopes are defined: DFS (scope 5, standard TLVs) and E-DFS (scope 68, extended TLVs). Both use the FS LSP ID Extended format and enable domain-wide flooding that preserves originator identity, avoiding the information loss inherent in inter-level leaking procedures.
Three new PDU types are added to the 'IS-IS PDU Registry': 10 (FS-LSP), 11 (FS-CSNP), 12 (FS-PSNP). A new 'LSP Flooding Scope Identifier Registry' is created with Expert Review procedure; values 1–63 designate standard TLV PDUs and 64–127 designate extended TLV PDUs. Initial assignments: L1CS=1, L2CS=2, L1FS=3, L2FS=4, DFS=5, E-L1CS=64, E-L2CS=65, E-L1FS=66, E-L2FS=67, E-DFS=68.
TLV type 243 (Scope Flooding Support) is registered in the 'IS-IS TLV Codepoints' registry (IIH=Y, LSP=N, SNP=N, Purge=N). The registry is extended to allow codepoints up to 65535; values above 255 are usable only in PDUs designated for extended TLVs.
New FS PDUs are subject to the same security concerns as standard LSP/CSNP/PSNP PDUs addressed in RFC 5304 and RFC 5310. Authentication TLVs MAY be included in FS PDUs using scope-specific or shared authentication configuration. The additional PDU types increase router processing load, expanding the attack surface for denial-of-service attacks.
Extended TLVs and extended sub-TLVs use a 16-bit Type field and a 16-bit Length field encoded in network byte order, allowing Length values greater than 255 octets. Standard TLV code points may be reused in extended TLVs by encoding the 8-bit type as a 16-bit integer with the 8 most significant bits set to zero.
FS-CSNP PDU (type 11): Scope field bits 1–7 hold the flooding scope; bit 8 is Reserved. Fixed header includes Source ID (ID Length + 1 octets), Start FS-LSP ID, and End FS-LSP ID (each ID Length + 2 octets). Variable-length fields are limited to those supported by standard CSNP.
FS-LSP PDU (type 10): the Maximum Area Addresses field is replaced by an 8-bit Scope field where bits 1–7 encode the flooding scope and bit 8 is the Priority (P) bit. The FS LSP ID is either Standard format (Source ID + 1-octet Pseudonode ID + 1-octet FS LSP Number) or Extended format (Source ID + 2-octet Extended FS LSP Number); the format is determined per-scope at scope definition time.
FS-PSNP PDU (type 12): Scope field bits 1–7 hold the flooding scope; bit 8 is the Unsupported (U) bit. U=1 signals that the sending IS does not support the specified scope. When U=1, variable-length fields other than authentication MUST NOT be included in the PDU.