OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering
Extracted elements (22)
Because there is no IGP peering on inter-AS links, bidirectional TE link information is unavailable. The ASBR therefore proxies for the remote ASBR by generating an additional LSA describing the remote device's view of the link, enabling CSPF to perform its normal two-way check during path computation.
The document explicitly excludes distribution of TE information between ASes, TE aggregation, and exchange of private information between ASes, in order to preserve AS confidentiality and scaling assumptions while still enabling inter-AS path computation.
Two separate LSA types (Inter-AS-TE-v2 and Inter-AS-TE-v3) are defined for OSPFv2 and OSPFv3 respectively, rather than reusing existing intra-AS TE LSAs, so that inter-AS TE link advertisements can be easily identified and distinguished from intra-AS TE information.
Legacy routers receiving an advertisement for an inter-AS TE link will ignore it because the Link Type carries an unknown value, but will continue to flood the LSA. They will not attempt to use the information as if it were an intra-AS TE link.
For the Inter-AS-TE-v3 LSA, S2 and S1 bits SHOULD be set to 01 for area-scoped flooding, but MAY be set to 10 for AS-scoped flooding. Configuration control SHOULD be provided in ASBR implementations.
Hellos MUST NOT be exchanged over the inter-AS link, and consequently, an OSPF adjacency MUST NOT be formed on inter-AS links.
In OSPFv2 advertisements, the IPv4 Remote ASBR ID sub-TLV MUST be included if the neighboring ASBR has an IPv4 address. If the neighboring ASBR does not have an IPv4 address, the IPv6 Remote ASBR ID sub-TLV MUST be included instead.
In OSPFv3 advertisements, the IPv6 Remote ASBR ID sub-TLV MUST be included if the neighboring ASBR has an IPv6 address. If the neighboring ASBR does not have an IPv6 address, the IPv4 Remote ASBR ID sub-TLV MUST be included instead.
Routers or PCEs capable of processing inter-AS TE link advertisements SHOULD NOT use such links to compute paths that exit an AS and immediately re-enter through another TE link, except as a result of specific policy configuration.
The inter-AS TE link advertisement SHOULD be carried in a Type 10 Opaque LSA if flooding scope is limited to the single IGP area, or MAY be carried in a Type 11 Opaque LSA if information should reach all routers in the AS. Configuration control of this choice SHOULD be provided in ASBR implementations.
The Link ID sub-TLV MUST NOT be used in the Link TLV of an Inter-AS-TE-v2 LSA, and the Neighbor ID sub-TLV MUST NOT be used in the Link TLV of an Inter-AS-TE-v3 LSA, as these OSPF-specific sub-TLVs are not applicable to inter-AS links.
The Remote AS Number sub-TLV MUST be included in the Link TLV of both the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA. At least one of the IPv4 or IPv6 Remote ASBR ID sub-TLVs SHOULD be included.
When TE is enabled on an inter-AS link and the link is up, the ASBR SHOULD advertise the link. When the link is down or TE is disabled, the ASBR SHOULD withdraw the advertisement. The ASBR MUST take precautions against excessive re-advertisements when TE parameters change.
The Inter-AS-TE-v2 LSA is a new Opaque LSA type (Opaque type 6) for advertising OSPFv2 inter-AS TE links. It has the same format as the Traffic Engineering LSA defined in OSPF-TE and may be carried as a Type 10 (area-scoped) or Type 11 (AS-scoped) Opaque LSA.
The Inter-AS-TE-v3 LSA is a new OSPFv3 LSA type with function code 13 for advertising inter-AS TE links in OSPFv3. The U-bit is always set to 1; S2/S1 bits indicate flooding scope (01 for area-scoped, 10 for AS-scoped).
IANA assigned Opaque LSA type 6 to the Inter-AS-TE-v2 LSA, and OSPFv3 LSA function code 13 to the Inter-AS-TE-v3 LSA.
IANA assigned three new sub-TLV values in the 'Types for sub-TLVs in a TE Link TLV' sub-registry: 21 (Remote AS Number), 22 (IPv4 Remote ASBR ID), and 24 (IPv6 Remote ASBR ID).
Configuration information about remote AS numbers and remote ASBR IDs is obtained manually from neighboring administrations and should be carefully checked. If a BGP session exists between ASBRs, inconsistencies (e.g., differing remote AS numbers) SHOULD trigger operator alerts or suppression of the OSPF advertisement, per local policy.
The extensions can be secured within the AS using existing OSPF security mechanisms. There is no exchange of information between ASes, and since no OSPF adjacency is formed on inter-AS links, no OSPF security between ASes is required.
The IPv4 Remote ASBR ID sub-TLV is TLV type 22 and is 4 octets in length, carrying a stable and routable IPv4 address of the remote ASBR. Use of the TE Router Address as specified in the Router Address TLV is RECOMMENDED.
The IPv6 Remote ASBR ID sub-TLV is TLV type 24 and is 16 octets in length, carrying a stable, routable, global IPv6 address of the remote ASBR. Use of the TE Router IPv6 Address as specified in the IPv6 Router Address TLV is RECOMMENDED.
The Remote AS Number sub-TLV is TLV type 21 and is 4 octets in length, carrying the AS number of the neighboring AS. When only 2 octets are used for the AS number, the high-order 2 octets MUST be set to zero.