Ethernet Traffic Parameters with Availability Information
Extracted elements (20)
IEEE 754 32-bit floating-point is used for the Availability field to align with RFC 8330. While floating-point introduces precision errors above 0.999999, this is acceptable because 0.99999 (five nines, ~5 minutes outage per year) is the practical maximum in telecom networks.
The Bandwidth Availability TLV uses an Index field to create a one-to-one correspondence with Ethernet Bandwidth Profile TLVs, allowing multiple <bandwidth, availability> pairs to be carried without ambiguity when different bandwidth classes have different availability requirements.
Without bandwidth availability information in signaling, a bandwidth request is treated as requiring the highest availability level, which may cause LSP setup to fail even when lower availability would suffice. The TLV addresses this by allowing explicit <bandwidth, availability> pairs in PATH messages.
When a node does not support the Bandwidth Availability TLV, it should send a PathErr message with error code 'Unknown Attributes TLV' per RFC 5420. An LSP could still be set up if sufficient bandwidth exists, though the availability level of reserved bandwidth will be unknown.
If all bandwidth requirements in the Ethernet Bandwidth Profile TLVs have the same availability requirement, one Bandwidth Availability TLV SHOULD be carried with the Index field set to 0.
The Availability field value MUST be less than 1 and is typically one of 0.99, 0.999, 0.9999, or 0.99999, encoded as an IEEE 754 32-bit floating-point number.
The Reserved field (3 octets) SHOULD be set to zero when sent and MUST be ignored when received.
When a Bandwidth Availability TLV is included, the Ethernet Bandwidth Profile TLV MUST also be included. If multiple bandwidth requirements have different availability requirements, multiple Bandwidth Availability TLVs MUST be carried with matching Index field values.
When a node receives Bandwidth Availability TLVs (non-zero index) with no matching index value among the Ethernet Bandwidth Profile TLVs, the message MUST be ignored and MUST NOT be propagated.
When a node receives Bandwidth Availability TLVs with a mix of zero and non-zero indexes, the message MUST be ignored and MUST NOT be propagated.
When all <bandwidth, availability> requirements can be satisfied, the node SHOULD reserve bandwidth resources from each remaining sub-bandwidth portion on its local link to set up the LSP. Optionally, higher availability bandwidth may be allocated to a lower availability request.
When at least one <bandwidth, availability> requirement cannot be satisfied, the node SHOULD generate a PathErr message with error code 'Admission Control Error' and error value 'Requested Bandwidth Unavailable'.
When extra Ethernet Bandwidth Profile TLVs do not match the index of any Bandwidth Availability TLV, the extra Ethernet Bandwidth Profile TLVs MUST be ignored and MUST NOT be propagated.
When two LSPs request bandwidth with the same availability requirement, contention MUST be resolved by comparing node IDs, with the higher node ID assigned the reservation, consistent with RFC 3471 Section 4.2.
The Bandwidth Availability TLV can also be carried by the Ethernet FLOWSPEC object, since it has the same format as the Ethernet SENDER_TSPEC object as defined in RFC 6003.
The Bandwidth Availability TLV is defined as a TLV of the Ethernet SENDER_TSPEC object, carrying a <bandwidth, availability> pair. It enables RSVP-TE signaling to express bandwidth requirements tied to specific availability levels for links with variable discrete bandwidth.
The Ethernet SENDER_TSPEC object MAY include more than one Bandwidth Availability TLV, paired with corresponding Ethernet Bandwidth Profile TLVs, to express multiple <bandwidth, availability> requirements for a single LSP.
IANA updated the 'Ethernet Sender TSpec TLVs/Ethernet Flowspec TLVs' subregistry under 'Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters' to add Type 4 for Bandwidth Availability TLV.
The Bandwidth Availability TLV in RSVP-TE signaling inherits GMPLS security mechanisms from RFC 3945 and RFC 5920, including RSVP-TE authentication and control-plane protection. GMPLS networks are often considered closed, limiting exposure to packet insertion, modification, or inspection by outside parties.
The Bandwidth Availability TLV has a 12-byte format: Type (2 octets, value 4), Length (2 octets, value 0x0C), Index (1 octet), Reserved (3 octets), and Availability (4 octets, IEEE 754 32-bit floating-point). Total length is fixed at 12 bytes.