ietf-corpus

rfc-6827

Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols

A. Malis (Editor), A. Lindem (Editor), D. Papadimitriou (Editor)
date2013-01 streamIETF areartg wgccamp statusPROPOSED STANDARD pages30 canonicalhttps://www.rfc-editor.org/rfc/rfc6827 doi10.17487/RFC6827
The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. [STANDARDS-TRACK]

obsoletes

updates

Extracted elements (27)

design-rationale §2

An ASON RA may be identified by the combination of its OSPF Instance ID and OSPF Area ID. Using just the OSPF Area ID is RECOMMENDED when proper network-wide configuration permits, because it simplifies RA isolation via OSPF's built-in area-ID matching on packet receipt.

routing

design-rationale §2

ASON Routing Area (RA) hierarchy does not map to OSPF area hierarchy. Instead, successive hierarchical levels of RAs MUST be represented by separate instances of the OSPFv2 protocol, with routing information exchanged between levels via import/export between protocol instances.

routing

design-rationale §7.1

Routing information imported/exported between RA levels MAY be transformed (filtered or aggregated) as long as the result is self-consistent. This policy-based flexibility is intentionally left outside the scope of the routing protocol specification to accommodate operator diversity.

routing

design-rationale §9

The TE LSA extensions defined in this document are not used for Shortest Path First (SPF) computation and have no direct effect on IP routing. ASON routing domains are further bounded by normal administrative domain boundaries, limiting the scope of any misconfiguration or attack.

routing, security

interoperability-note §8

ASON extensions are scoped to ASON routing domains and MUST NOT be combined with global Internet or Layer 3 VPN routing in the same OSPFv2 instance. If a Routing Controller must participate in both domains, separate OSPFv2 instances are required.

routing

interoperability-note §10.1

The same codepoint values (12 for Export Upward, 13 for Export Downward) MUST be used for the Inter-RA Export sub-TLVs regardless of whether they appear inside the Link TLV, Node Attribute TLV, or Router Address TLV, ensuring consistent interpretation across all advertisement contexts.

routing, registry

normative-requirement §6 MUST

A single OSPF router (acting as the Protocol Controller) MUST be able to advertise TE information on behalf of multiple transport-layer nodes, since the control-plane routing adjacency topology and the transport topology are not assumed to be congruent.

routing

normative-requirement §8 MUST

Exchange of TE link attributes (traffic engineering information) upward or downward in the ASON hierarchy MUST be under strict policy control. Pacing and min/max thresholds for triggered updates are strongly RECOMMENDED to limit scalability impact.

routing

normative-requirement §4 MUST

It MUST be possible for a router to originate more than one TE LSA containing the Node Attribute TLV when used for ASON reachability advertisement, because a router may support multiple transport nodes. This relaxes the Node Attribute TLV advertisement rules of RFC 5786.

routing

normative-requirement §8 MUST

Routing information exchange upward/downward between adjacent RAs MUST, by default, be limited to reachability information. Prefix aggregation and similar transformations are RECOMMENDED to reduce the volume of imported/exported data when consistency is maintained.

routing

normative-requirement §2 MUST

Successive hierarchical levels of ASON Routing Areas MUST be represented by separate instances of the OSPFv2 protocol. Inter-level routing information exchange involves export and import of routing information between protocol instances, not OSPF area hierarchy.

routing

normative-requirement §7.2.2 MUST

The direction and advertising RA ID carried in Inter-RA Export Upward/Downward sub-TLVs MUST be retained and re-advertised in the receiving RA along with the associated routing information, enabling loop prevention at all subsequent levels.

routing

normative-requirement §6.1 MUST

The Local and Remote TE Router ID sub-TLV MUST be included in a Link TLV when an OSPF router advertises ASON information on behalf of transport nodes with TE Router IDs different from the Router Address TLV value. If omitted or set to 0, the Link TLV is excluded from transport-plane path computation and the condition SHOULD be logged.

routing

normative-requirement §6.2 MUST

The Local TE Router ID sub-TLV MUST be included in a Node Attribute TLV when an OSPF router advertises ASON information on behalf of transport nodes with TE Router IDs different from the Router Address TLV value. If omitted or set to 0, the Node Attribute TLV is not used for SCN reachability.

routing

normative-requirement §8 MUST

The number of ASON routing hierarchy levels MUST be maintained under strict policy control to prevent unbounded growth in the volume of routing information propagated across the hierarchy.

routing

normative-requirement §7.2.2 MUST NOT

When exporting routing information downward, any TE LSA tagged with an Inter-RA Export Upward sub-TLV MUST NOT be exported downward into the RA identified by the sub-TLV's RA ID, preventing re-introduction of routing information into the RA from which it was received.

routing

normative-requirement §7.2.2 MUST NOT

When exporting routing information upward in the ASON hierarchy, any TE LSA tagged with an Inter-RA Export Downward sub-TLV MUST NOT be re-exported upward, preventing information from being re-introduced into the level from which it originated.

routing

protocol-element §5.1

Local adaptation is advertised as one or more Interface Switching Capability Descriptor (ISCD) sub-TLVs (type 15) within the Link TLV. A link between layers requires at least two ICSDs: one for the server-layer termination capability and one for the client-layer adaptation capability.

routing

protocol-element §6.1

The Local and Remote TE Router ID sub-TLV unambiguously identifies the local and remote transport-node endpoints for a TE link. When present, it supersedes the Link-ID sub-TLV for transport-plane path computation, and the Link-ID sub-TLV MUST be ignored.

routing

protocol-element §4

The Node Attribute TLV (defined in RFC 5786) is reused for ASON reachability advertisement. For ASON, it MUST carry the Local TE Router ID sub-TLV to associate a block of IPv4/IPv6 address prefixes with a specific transport node identified by TE Router ID.

routing

registry §10.3

A new IANA registry 'Types for sub-TLVs of Router Address TLV (Value 1)' was created. Types 0-32767 are assigned via Standards Action (type 0 reserved); types 32768-32777 are experimental and unregistered; types 32778-65535 require a future Standards Track RFC. Inter-RA Export Upward (12) and Downward (13) were the initial allocations.

registry, routing

registry §10.2

IANA assigned codepoints in the 'Types for sub-TLVs of TE Node Attribute TLV (Value 5)' registry (RFC 5786): Local TE Router ID sub-TLV (5), Inter-RA Export Upward sub-TLV (12), and Inter-RA Export Downward sub-TLV (13), all in the Standards Action range.

registry, routing

security-consideration §9

Any mechanism used to secure normal OSPF LSA exchanges applies equally to TE LSAs in the ASON context. OSPFv2 cryptographic authentication using HMAC-SHA (RFC 5709) can provide significant protection against active attacks on TE LSA exchanges.

security, routing

security-consideration §9 MUST

RCs implementing inter-RA export/import MUST enforce policy control on both the maximum amount of routing information advertised between RAs and the maximum rate of advertisement. This limits the blast radius of a compromised RC to only the RAs to which it is directly attached.

security, routing

wire-format §7.2.1

The Inter-RA Export Upward (Type 12) and Inter-RA Export Downward (Type 13) sub-TLVs each have Length 4 and a Value field containing the 4-octet RA ID from which the routing information was exported. These sub-TLVs may appear in Link, Node Attribute, and Router Address TLVs.

routing

wire-format §6.1

The Local and Remote TE Router ID sub-TLV (Type 10, Length 8) is a sub-TLV of the OSPFv2 TE LSA Link TLV. Its Value field contains a 4-octet Local TE Router Identifier followed by a 4-octet Remote TE Router Identifier; neither value may be 0.

routing

wire-format §6.2

The Local TE Router ID sub-TLV (Type 5, Length 4) is a sub-TLV of the OSPFv2 TE LSA Node Attribute TLV. Its Value field contains a single 4-octet Local TE Router Identifier that associates advertised reachability prefixes with a specific transport node.

routing