RFC 6827
Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols
Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols 🦋
Okay bestie, let's start with the title block 💖. This is RFC 6827, a Standards Track doc from January 2013 (ISSN 2070-1721) from the Internet Engineering Task Force (IETF). Three editors wrote it, all marked (Ed.): A. Malis from Verizon Communications, A. Lindem from Ericsson, and D. Papadimitriou from Alcatel-Lucent. It obsoletes RFC 5787 and updates RFC 5786 🎀
Abstract ✨
Okay so the ITU-T 💅 already came up with an architecture and a list of requirements for running an Automatically Switched Optical Network (ASON). Iconic behavior.
The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is built to be the control plane for a whole bunch of network technologies 🌈. That includes optical stuff like time division multiplexing (TDM) networks, which covers the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks.
The requirements for GMPLS routing that meet ASON routing needs, plus an evaluation of the existing GMPLS routing protocols, live in other documents. This one is about the extensions to the OSPFv2 Link State Routing Protocol that let it handle 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 💜
Status of This Memo ✨
This is an Internet Standards Track document 🔥
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741.
For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6827 🍓
Copyright Notice 🌸
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.
Table of Contents 🎀
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................5
2. Routing Areas, OSPF Areas, and Protocol Instances ...............5
3. Terminology and Identification ..................................6
4. Reachability ....................................................7
5. Link Attribute ..................................................8
5.1. Local Adaptation ...........................................8
5.2. Bandwidth Accounting .......................................9
6. Routing Information Scope .......................................9
6.1. Link Advertisement (Local and Remote TE Router ID Sub-TLV) .9
6.2. Reachability Advertisement (Local TE Router ID Sub-TLV) ...11
7. Routing Information Dissemination ..............................11
7.1. Import/Export Rules .......................................12
7.2. Loop Prevention ...........................................12
7.2.1. Inter-RA Export Upward/Downward Sub-TLVs ...........13
7.2.2. Inter-RA Export Upward/Downward Sub-TLV Processing .13
8. OSPFv2 Scalability .............................................14
9. Security Considerations ........................................15
10. IANA Considerations ...........................................15
10.1. Sub-TLVs of the Link TLV .................................15
10.2. Sub-TLVs of the Node Attribute TLV .......................16
10.3. Sub-TLVs of the Router Address TLV .......................16
11. Management Considerations .....................................17
11.1. Routing Area (RA) Isolation ..............................17
11.2. Routing Area (RA) Topology/Configuration Changes .........17
12. Comparison to Requirements in RFC 4258 ........................17
13. References ....................................................25
13.1. Normative References .....................................25
13.2. Informative References ...................................25
14. Acknowledgements ..............................................26
14.1. RFC 5787 Acknowledgements ................................26
Appendix A. ASON Terminology ......................................27
Appendix B. ASON Routing Terminology ..............................28
Appendix C. Changes from RFC 5787 .................................291. Introduction ✨
Okay, so GMPLS [RFC3945] is the protocol suite built to be the control plane for a range of network technologies 💖. That covers optical networks like TDM networks (including SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks.
The ITU-T defines the architecture of the Automatically Switched Optical Network (ASON) in [G.8080] 🌈
[RFC4258] describes the routing requirements for the GMPLS suite of routing protocols, which support the capabilities and functionality of ASON control planes identified in [G.7715] and [G.7715.1] 🦋
[RFC4652] evaluates the IETF Link State routing protocols against the requirements identified in [RFC4258]. Section 7.1 of [RFC4652] summarizes the capabilities that OSPFv2 [RFC2328] has to provide for ASON routing. This document describes the OSPFv2 specifics for ASON routing 💅
Multi-layer transport networks are built from multiple networks of different technologies working in a client-server relationship. The ASON routing model defines routing levels that bring scaling and confidentiality benefits 🫶. In multi-level routing, domains called routing areas (RAs) are arranged in a hierarchy. As described in [RFC4652], there is no implied relationship between multi-layer transport networks and multi-level routing. The multi-level routing mechanisms in this document work for both single-layer and multi-layer networks 🌸
Implementations may support a hierarchical routing topology (multi-level) for multiple transport network layers, and/or a hierarchical routing topology for a single transport network layer 🧚
This document describes how the generic (technology-independent) link attributes get processed. Those attributes are defined in [RFC3630], [RFC4202], and [RFC4203], and this document extends them. As Section 5.2 explains, technology-specific traffic engineering attributes and their processing may be defined in other documents that complement this one 🎀
Note that this work is scoped to the requirements and evaluation expressed in [RFC4258] and [RFC4652] 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 [RFC4258] 💜
1.1. Conventions Used in This Document 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔥
The reader is assumed to be familiar with the terminology and requirements developed in [RFC4258] and the evaluation outcomes described in [RFC4652] 🍓
General ASON terminology is in Appendix A, and ASON routing terminology is in Appendix B 🦋
2. Routing Areas, OSPF Areas, and Protocol Instances 🌸
An ASON routing area (RA) represents a partition of the transport plane. Its identifier is used within the control plane as the representation of that partition ✨
RAs nest inside each other like hierarchy goals. A higher-level (parent) RA contains lower-level (child) RAs, and those child RAs MAY also contain RAs of their own. So RAs contain RAs, recursively defining successive hierarchical RA levels 🪆 Routing information may be exchanged between levels of the RA hierarchy, meaning Level N+1 and Level N, where Level N is made up of the RAs contained by Level N+1 💖. The links connecting RAs may be viewed as external links (inter-RA links), and the links representing connectivity inside an RA may be viewed as internal links (intra-RA links). External links to an RA at one level may be internal links in the parent RA. Intra-RA links of a child RA MAY be hidden from the parent RA's view [RFC4258] 🌈
An ASON RA can be mapped to an OSPF area, but the hierarchy of ASON RA levels does not map to the hierarchy of OSPF areas 🙈 Instead, successive hierarchical levels of RAs MUST be represented by separate instances of the protocol. So inter-level routing information exchange (as described in Section 7) means exporting and importing routing information between protocol instances 🫶
An ASON RA may therefore be identified by the combination of its OSPF Instance ID and its OSPF Area ID. With proper and careful network-wide configuration, this can be done using just the OSPF Area ID, and this process is RECOMMENDED in this document. These concepts are discussed in Section 7 🦋
A key ASON requirement is support for multiple transport planes or layers. Each transport node has associated topology (links and reachability), which is used for ASON routing 👑
3. Terminology and Identification ✨
okay so this section is basically the translation guide 🗺️ it maps the key ASON entities onto their OSPF buddies. if you need the full ASON vocab list, it's all in Appendix A 📖
there are three kinds of identifiers floating around for ASON routing (G.7715.1) 💅: transport-plane names, control-plane identifiers for components, and Signaling Communications Network (SCN) addresses. the vibe here is how the ASON routing IDs match up with the ones already defined for GMPLS routing, and how they keep transport-plane entities and control-plane components separated, whether that's physical or logical. GMPLS is literally all about keeping those identifiers and planes apart 🫶
in OSPF Traffic Engineering (TE) land, an ASON transport node is the same thing as a unique OSPF TE node 🦋 and each OSPF TE node is uniquely identified by the TE Router Address TLV [RFC3630]. in this doc we just call that the TE Router ID 🎀. also, GMPLS advertises TE router addresses as reachable in both the control and transport planes (more on that in Section 4 below 👀). and the TE Router ID should not be confused with the OSPF Router ID, which uniquely identifies an OSPF router inside an OSPF routing domain [RFC2328]. the OSPF Router ID lives in the control-plane component namespace, so they're different people, bestie 💜
the Router Address top-level TLV is mostly the same as in [RFC3630] (definition, processing, and usage all basically unchanged ✨). it specifies a stable OSPF TE node IP address, meaning the address stays reachable whenever there's IP connectivity to the associated OSPF TE node 🌸
now the roles 🎭. ASON defines a Routing Controller (RC) as the entity that handles the (abstract) info needed for routing and swaps routing info with peering RCs by working on the Routing Database (RDB) 💼. ASON also defines a Protocol Controller (PC) as the entity that handles protocol-specific message exchanges based on the reference point the info goes over (like E-NNI or I-NNI), plus the internal exchanges with the RC [RFC4258] 🔥. in this document, an OSPF router that advertises ASON TE topology info does BOTH jobs, RC and PC 👑. the OSPF routing domain is the control plane, and every OSPF router gets uniquely identified by its OSPF Router ID [RFC2328] 🧚
4. Reachability ✨
in ASON, reachability info tells you the set of endpoints the node can reach in the transport plane 🌈. it's about transport-plane resources (think an optical cross-connect interface) and it uses transport-plane identifiers 💅
to advertise whole blocks of reachable address prefixes, there's a summarization mechanism based on the techniques in [RFC5786] 📦. for ASON reachability, those blocks get advertised together with their associated transport-plane node 🎀. that transport-plane node shows up in OSPF TE Link State Advertisements (LSAs) through its TE Router ID, as covered in Section 6 🦋
so to support ASON reachability advertisement, the Node Attribute TLV from [RFC5786] is used to bundle a TE Router ID together with its set of reachable address prefixes 💖. the Node Attribute TLV can carry these sub-TLVs:
- Local TE Router ID sub-TLV: Length: 4; Defined in Section 6.2
- Node IPv4 Local Address sub-TLV: Length: variable; [RFC5786]
- Node IPv6 Local Address sub-TLV: Length: variable; [RFC5786]
a router can run multiple transport nodes (see Section 6 🍓), so it might need to advertise reachability separately for each one. which means the router MUST be able to originate more than one TE LSA containing the Node Attribute TLV when it's doing ASON reachability advertisement 🔥
because of that, the Node Attribute TLV [RFC5786] advertisement rules get relaxed 🫶. a Node Attribute TLV MAY show up in more than one TE LSA originated by the RC, as long as the RC is advertising reachability for a different transport node, identified by the Local TE Router sub-TLV (see Section 6.2) ✨
and as [RFC3630] says, TE-advertised router addresses are also advertised as reachable in the control plane, so they're valid identifiers in the ASON SCN name space too 🌸
5. Link Attribute 🔗
except for local adaptation (more on that below), the mapping of link attributes and characteristics to OSPF TE Link TLV sub-TLVs is unchanged [RFC4652] 💜. the OSPF TE Link TLV sub-TLVs are described in [RFC3630] and [RFC4203] 📖. this info SHOULD be supported on a per-layer basis, meaning one TE LSA per unique combo of switching capability and bandwidth granularity 🎀
5.1. Local Adaptation 🦋
local adaptation is a TE link attribute (a sub-TLV) that describes the cross/inter-layer relationships 🌈
the Interface Switching Capability Descriptor (ISCD) TE Attribute [RFC4202] tells you the TE link can support cross-connection to another link in the same layer 💅. when you advertise link adaptation, it also says whether a locally terminated connection from one layer can be used as a data link for another layer (that's the adaptation capability) 🧚. the info about terminating connections inside that layer (the termination capability) gets advertised along with the adaptation capability 🫶
for example, a link between two optical cross-connects will have at least one ISCD attribute describing the Lambda Switching Capable (LSC) switching capability 🔥. but a link between an optical cross-connect and an IP/MPLS Label Switching Router (LSR) will have at least two ISCD attributes: one for the LSC termination capability, and one for the Packet Switching Capable (PSC) adaptation capability 👑
in OSPFv2, the ISCD is a sub-TLV (type 15) of the top-level Link TLV (type 2) [RFC4203] ✨. the adaptation and termination capabilities each get their own ISCD sub-TLV, both inside the same top-level Link TLV 💖
an interface MAY have more than one ISCD sub-TLV, per [RFC4202] and [RFC4203] 🌸. so the corresponding advertisements should not result in any compatibility issues 🦋
5.2. Bandwidth Accounting 💰
GMPLS routing defines an ISCD that gives you, among other things, the max/min available bandwidth per priority for Label Switched Paths (LSPs) 📊. one or more ISCD sub-TLVs can be associated with an interface, per [RFC4202] and [RFC4203] 🎀. that info, combined with the Unreserved Bandwidth Link TLV sub-TLV [RFC3630], is the basis for bandwidth accounting 💅
in the ASON context, extra info may be included when the other advertised fields aren't enough for a specific technology, like SDH 🌈. defining those technology-specific info elements is beyond the scope of this document 🙈. some technologies won't need anything beyond what's already defined in [RFC3630], [RFC4202], and [RFC4203] ✨
6. Routing Information Scope 🔭
for ASON routing, the control-plane component routing adjacency topology (the associated Protocol Controller (PC) connectivity) and the transport topology are not assumed to be congruent [RFC4258] 🫣. so a single OSPF router (the PC) MUST be able to advertise on behalf of multiple transport-layer nodes 👑. OSPF routers are identified by OSPF Router ID, and transport nodes are identified by TE Router ID 💜
the Router Address TLV [RFC3630] advertises the TE Router ID tied to the advertising Routing Controller (RC) 🎀. TE Router IDs for any additional transport nodes get advertised through the Local TE Router Identifier, which is specified in the Local and Remote TE Router TE sub-TLV and the Local TE Router Identifier sub-TLV described in the sections below 🦋. these Local TE Router Identifiers are typically used as the local endpoints for TE LSPs that terminate on the associated transport node 🌸
using multiple OSPF Routers to advertise TE info for the same transport node is not considered a required use case, so this document doesn't discuss it further 🙃
6.1. Link Advertisement (Local and Remote TE Router ID Sub-TLV) 🔗
when an OSPF Router advertises on behalf of multiple transport nodes, the link endpoints can't be automatically assigned to a single transport node tied to the advertising router 😭. in that case, the local and remote transport nodes MUST be identified by TE Router ID so the transport topology is specified unambiguously 💖
for this, there's a new sub-TLV of the OSPFv2 TE LSA top-level Link TLV that defines the Local and Remote TE Router ID 🧚
the Type field of the Local and Remote TE Router ID sub-TLV is set to 10 (see Section 10) 🎀. the Length field is 8 💅. the Value field holds 4 octets of Local TE Router Identifier followed by 4 octets of Remote TE Router Identifier 🌈. the Local and Remote TE Router Identifier MUST NOT be set to 0 🙅♀️
here's the format of the Local and Remote TE Router ID sub-TLV 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (10) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+this sub-TLV MUST be included as a sub-TLV of the top-level Link TLV if the OSPF router is advertising on behalf of one or more transport nodes whose TE Router IDs differ from the TE Router ID advertised in the Router Address TLV 🫶. for consistency, this sub-TLV MUST be included whenever OSPF is used to advertise ASON info the way described here 💅. if it's not included in a Link TLV, or if a value of 0 is specified for the Local or Remote TE Router Identifier, the Link TLV will not be used for transport-plane path computation 😬. the condition SHOULD be logged for possible action by the network operator 📝
Note: the Link ID sub-TLV identifies the other end of the link (the Router ID of the neighbor for point-to-point links) [RFC3630]. when the Local and Remote TE Router ID sub-TLV is present, it MUST be used to identify the local and remote transport node endpoints for the link, and the Link-ID sub-TLV MUST be ignored. in fact, when the Local and Remote TE Router ID sub-TLV is specified, the Link-ID sub-TLV MAY be omitted 🙌. the Local and Remote TE Router ID sub-TLV, if specified, MUST only be specified once. if it's specified more than once, instances other than the first will be ignored, and the condition SHOULD be logged for possible action by the network operator 🚨
6.2. Reachability Advertisement (Local TE Router ID Sub-TLV) 🦋
okay bestie, picture an OSPF router advertising on behalf of a whole squad of transport nodes at once 🌸 the routing protocol MUST be able to match each bit of reachability info with the correct transport node. no mix-ups, no cap 💅
so for that, there's a brand new sub-TLV living inside the OSPFv2 TE LSA top-level Node Attribute TLV ✨ it links the local prefixes (see above) to a given transport node, identified by its TE Router ID 🎀
the Type field of the Local TE Router ID sub-TLV is assigned the value 5 (see Section 10) 💖 the Length is 4, and the Value field holds the Local TE Router Identifier, encoded over 4 octets 🧚 the format is giving:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (5) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+this sub-TLV MUST be included as a sub-TLV of the top-level Node Attribute TLV if the OSPF router is advertising on behalf of one or more transport nodes whose TE Router IDs are different from the TE Router ID advertised in the Router Address TLV 🙈 for consistency, this sub-TLV MUST be included when OSPF is used to advertise ASON information as described herein. if it's not included in a Node Attribute TLV, or if a value of 0 is specified for the Local TE Router Identifier, the Note Attribute TLV will not be used for determining ASON SCN reachability. and yes, the condition SHOULD be logged so the network operator can take action 📝
7. Routing Information Dissemination 🌈
okay so an ASON routing area (RA) is a partition of the transport plane, and its identifier is how that partition shows up in the control plane 🫶 an RA can hold smaller RAs that are interconnected by links. ASON RA levels do not map directly to OSPF areas. instead, hierarchical levels of RAs are represented by separate OSPF protocol instances. it's still useful to align the RA IDs and the area ID so that RAs can be isolated, as described in Section 11.1 ✨
Routing Controllers (RCs) that support multiple RAs pass information downward and upward through this ASON hierarchy 💅 the vertical routing information dissemination mechanisms in this section do not introduce or imply hierarchical OSPF areas. RCs supporting RAs at multiple levels are structured as separate OSPF instances, and the information exchanged between levels is governed by import and export rules between those instances. the functionality described here doesn't pertain to OSPF areas or OSPF Area Border Router (ABR) functionality 🦋
7.1. Import/Export Rules 🔁
RCs supporting RAs disseminate information upward and downward through the hierarchy by importing and exporting routing information as TE LSAs. TE LSAs are area-scoped Opaque LSAs with Opaque type 1 [RFC3630]. the information that MAY be exchanged between adjacent levels includes the Router Address, Link, and Node Attribute top-level TLVs 🌸
the imported/exported routing information content MAY be transformed (e.g., filtered or aggregated) as long as the resulting information stays consistent. especially when more than one RC is bound to adjacent levels and both are allowed to import/export routing information, these transformations are expected to be performed in a consistent manner 💖 policy-based mechanisms like these are outside the scope of this document.
in practice, and to avoid scalability and processing overhead, the routing information imported/exported downward/upward through the hierarchy is expected to include reachability information (see Section 4) and, under strict policy control, link topology information 🧚
7.2. Loop Prevention 🔄
when more than one RC is bound to an adjacent level of the ASON hierarchy and is configured to export routing information upward or downward, a specific mechanism is required to stop routing information from looping 🙅♀️ looping means re-advertising routing information into an RA that had already advertised that same information upward or downward into an upper or lower level RA. for example, without loop-prevention mechanisms, this could happen when the RC advertising routing information downward is not the same one advertising it upward 😭
7.2.1. Inter-RA Export Upward/Downward Sub-TLVs
the Inter-RA Export sub-TLVs can be used to prevent re-advertising OSPF TE routing information into an RA that previously advertised it 💜 the type value 13 (see Section 10) indicates that the associated routing information has been exported downward. the type value 12 (see Section 10) indicates that it has been exported upward. while it is not required for routing information exported downward, both sub-TLVs will include the Routing Area (RA) ID from which the routing information was exported. this RA is not necessarily the RA that originated the routing information, but the RA it was immediately exported from ✨
these additional sub-TLVs MAY be included in TE LSAs that contain any of the following top-level TLVs:
- Router Address top-level TLV
- Link top-level TLV
- Node Attribute top-level TLV
the Type field of the Inter-RA Export Upward and Inter-RA Export Downward sub-TLVs is assigned the values 12 and 13 respectively (see Section 10) 🎀 the Length field in these sub-TLVs takes the value 4, and the Value field contains the associated RA ID. the RA ID value must be a unique identifier for the RA within the ASON routing domain 🌈
here's how the Inter-RA Export Upward and Inter-RA Export Downward sub-TLVs look:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upward/Downward Type | Length (4) |
| (12/13) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+7.2.2. Inter-RA Export Upward/Downward Sub-TLV Processing
TE LSAs MAY be imported or exported downward or upward through the ASON routing hierarchy 🦋 the direction and advertising RA ID are carried in an Inter-RA Export Upward/Downward sub-TLV. they MUST be retained and advertised in the receiving RA along with the associated routing information 💅
when exporting routing information upward, any information received from a level above (i.e., tagged with an Inter-RA Export Downward sub-TLV) MUST NOT be exported upward 🙈 since an RA at Level N is contained by a single RA at Level N+1, this is the only check needed, and the associated RA ID is used solely for informational purposes.
when exporting routing information downward, any information received from a level below (i.e., tagged with an Inter-RA Export Upward sub-TLV) MUST NOT be exported downward if the target RA ID matches the RA ID associated with the routing information 👀 this extra check is required for downward exports because a single RA at Level N+1 may contain multiple RAs at Level N in the ASON routing hierarchy. in other words, routing information MUST NOT be exported downward into the RA it was received from 🚫
8. OSPFv2 Scalability 📈
the extensions described here only apply to ASON routing domains, and the attendant reachability (see Section 4) and link information is not expected to ever be combined with global Internet or Layer 3 Virtual Private Network (VPN) routing 🌍 if an RC ever needed to participate in both domains, separate OSPFv2 instances would be used. but in a multi-level ASON hierarchy the potential volume of information can get huge, so the recommendations in this section MUST be followed by RCs implementing this specification 😭
- routing information exchange upward/downward in the hierarchy between adjacent RAs MUST, by default, be limited to reachability information. on top of that, several transformations such as prefix aggregation are RECOMMENDED to reduce the amount of information imported/exported by a given RC, as long as those transformations won't impact consistency ✨
- routing information exchange upward/downward in the ASON hierarchy involving TE attributes MUST be under strict policy control. pacing and min/max thresholds for triggered updates are strongly RECOMMENDED 🎀
- the number of routing levels MUST be maintained under strict policy control 🔒
9. Security Considerations 🔐
this document specifies the contents and processing of OSPFv2 TE LSAs [RFC3630] and [RFC4202] 💖 the TE LSA extensions defined here are not used for Shortest Path First (SPF) computation and have no direct effect on IP routing. ASON routing domains are also delimited by the usual administrative domain boundaries 🧚
any mechanisms used for securing the exchange of normal OSPF LSAs can be applied equally to all TE LSAs used in the ASON context. authentication of OSPFv2 LSA exchanges (such as OSPF cryptographic authentication [RFC2328] [RFC5709]) can provide significant protection against active attacks ⚔️ [RFC5709] defines a mechanism for authenticating OSPFv2 packets using the Hashed Message Authentication Code (HMAC) algorithm in conjunction with the SHA family of cryptographic hash functions 🔥
RCs implementing export/import of ASON routing information between RAs MUST also include policy control of both the maximum amount of information advertised between RAs and the maximum rate at which it is advertised 🚨 this is to isolate the consequences of an RC being compromised to the RAs to which that subverted RC is attached. it's giving containment, bestie 🛡️
the "Analysis of OSPF Security According to KARP Design Guide" [OSPF-SEC] provides a comprehensive analysis of OSPFv2 and OSPFv3 security relative to the requirements specified in [RFC6518] 📚
10. IANA Considerations 🏷️
this document defines new sub-TLVs for inclusion in OSPF TE LSAs 🎀 IANA has assigned values per the assignment policies for the registries of code points for these sub-TLVs [RFC3630].
the following subsections summarize the required sub-TLVs ✨
10.1. Sub-TLVs of the Link TLV ✨
okay bestie, this part lists the sub-TLVs that live inside the Link TLV of the OSPF TE LSA 💖 There are three:
- Local and Remote TE Router ID sub-TLV (10)
- Inter-RA Export Upward sub-TLV (12)
- Inter-RA Export Downward sub-TLV (13)
Their codepoints were allocated in the Standards Action range of the "Types for sub-TLVs of TE Link TLV (Value 2)" registry [RFC3630], so they're officially claimed 🎀
Big rule alert: the Inter-RA Export Upward and Inter-RA Export Downward sub-TLVs MUST use the same values whenever they appear in the Link TLV, Node Attribute TLV, and Router Address TLV 🫶 No exceptions, no cap.
10.2. Sub-TLVs of the Node Attribute TLV 🌸
Same energy, different TLV. This document defines these sub-TLVs of the Node Attribute TLV in the OSPF TE LSA:
- Local TE Router ID sub-TLV (5)
- Inter-RA Export Upward sub-TLV (12)
- Inter-RA Export Downward sub-TLV (13)
The codepoints were assigned in the Standards Action range of the "Types for sub-TLVs of TE Node Attribute TLV (Value 5)" registry [RFC5786] 💅
And yep, the same rule applies again: the Inter-RA Export Upward and Inter-RA Export Downward sub-TLVs MUST use the same values when they appear in the Link TLV, Node Attribute TLV, and Router Address TLV ✨
10.3. Sub-TLVs of the Router Address TLV 🧚
The Router Address TLV is advertised in the OSPF TE LSA [RFC3630]. Since this TLV never had any sub-TLVs defined, a "Types for sub-TLVs of Router Address TLV (Value 1)" registry got created 🍓
Here's how the registry guidelines work for the Router Address TLV sub-TLVs:
- Types in the range 0-32767 are to be assigned via Standards Action.
- Type 0 in that Standards Action range (0-32767) is reserved.
- Types in the range 32768-32777 are for experimental use. These will not be registered with IANA and MUST NOT be mentioned by RFCs. 🙈
- Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations covering the range being assigned.
This document defines these sub-TLVs for inclusion in the Router Address TLV:
- Inter-RA Export Upward sub-TLV (12)
- Inter-RA Export Downward sub-TLV (13)
Their codepoints were allocated in the Standards Action range of the "Types for sub-TLVs of Router Address TLV (Value 1)" registry 🦋
Once more with feeling: the Inter-RA Export Upward and Inter-RA Export Downward sub-TLVs MUST use the same values when they appear in the Link TLV, Node Attribute TLV, and Router Address TLV 💜
11. Management Considerations 🌈
11.1. Routing Area (RA) Isolation
If the RA ID is mapped to the OSPF Area ID as recommended in Section 2, OSPF [RFC2328] gives you isolation for free 🎀 On any intra-RA link, packets only get accepted if the area ID in the OSPF packet header matches the area ID of the OSPF interface where the packet was received. So RCs will only form adjacencies and swap reachability information (see Section 4.0) with RCs in the same RA. Other mechanisms for RA isolation are beyond the scope of this document 🧚
11.2. Routing Area (RA) Topology/Configuration Changes
The GMPLS Routing for ASON requirements [RFC4258] say the routing protocol MUST support reconfiguration and SHOULD support architectural evolution 💅 OSPF [RFC2328] supports the dynamic introduction or removal of ASON reachability information by flooding and purging OSPF Opaque LSAs [RFC5250] ✨
Also, when an RA is partitioned or an RC fails, stale LSAs SHOULD NOT be used unless the advertising RC is reachable 🙅♀️ The configuration of OSPF RAs, and the policies that decide how ASON reachability information gets redistributed between RAs, are implementation issues outside the OSPF routing protocol and beyond the scope of this document 🌸
12. Comparison to Requirements in RFC 4258 📋
Next up is the compliance check against [RFC4258] 💖 The table shows how this document measures up to the requirements in that RFC. The first column has a requirements number (1-30) and the relevant section in RFC 4258. The second column describes the requirement, the third column discusses compliance with it, and the fourth column lists the relevant section in this document and/or another RFC that already satisfies the requirement 🦋
Okay bestie, this is the big compliance checklist 💅 Each RFC 4258 requirement gets a yes, no, or "out of scope" 🔥
+----------+---------------------------+---------------+-------------+
| RFC 4258 | RFC 4258 Requirement | Compliance | Reference |
| Section | | | |
| (Req. | | | |
| Number) | | | |
+----------+---------------------------+---------------+-------------+
| 3 (1) | The failure of an RC, or | Implied by | Not an |
| | the failure of | separation of |attribute of |
| |communications between RCs,| transport and | routing |
| |and the subsequent recovery|control plane. | protocol. |
| |from the failure condition | | |
| | MUST NOT disrupt calls in | | |
| | progress. | | |
+----------+---------------------------+---------------+-------------+
| 3.1 (2) | Multiple Hierarchical | Yes | Sections 2 |
| | Levels of ASON Routing | | and 3. |
| | Areas (RAs). | | |
+----------+---------------------------+---------------+-------------+
| 3.1 (3) | Prior to establishing | Yes, when RA |Section 11.1.|
| | communications, RCs MUST | maps to OSPF | |
| |verify that they are bound | Area ID. | |
| | to the same parent RA. | Otherwise, | |
| | | out of scope. | |
+----------+---------------------------+---------------+-------------+
| 3.1 (4) | The RC ID MUST be unique | Yes |RFC 2328 and |
| | within its containing RA. | | Section 3. |
+----------+---------------------------+---------------+-------------+
| 3.1 (5) |Each RA within a carrier's |Yes - although | Sections 2, |
| | network SHALL be uniquely | uniqueness is | 3, and 11.1.|
| | identifiable. RA IDs MAY |the operator's | |
| | be associated with a |responsibility.| |
| |transport-plane name space,| | |
| | whereas RC IDs are | | |
| | associated with a | | |
| | control-plane name space. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (6) | Hierarchical Routing | Yes | Section 7. |
| | Information Dissemination.| | |
+----------+---------------------------+---------------+-------------+
| 3.2 (7) | Routing Information | Yes | Section 7.1.|
| |exchanged between levels N | | |
| | and N+1 via separate | | |
| | instances and | | |
| | import/export. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 3.2 (8) | Routing Information | No - Not | |
| |exchanged between levels N | described. | |
| | and N+1 via external link | | |
| | (inter-RA links). | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (9) | Routing information | Yes | Sections 4, |
| | exchange MUST include | |6, 6.1, 6.2, |
| | reachability information | | and 8. |
| | and MAY include, upon | | |
| | policy decision, node and | | |
| | link topology. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (10) | There SHOULD NOT be any |Yes - separate | Sections 2 |
| | dependencies on the | instances. | and 3. |
| |different routing protocols| | |
| | used within an RA or in | | |
| | different RAs. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (11) |The routing protocol SHALL | Yes | Section 7.2.|
| | differentiate the routing | | |
| |information originated at a| | |
| |given-level RA from derived| | |
| | routing information | | |
| | (received from external | | |
| | RAs), even when this | | |
| |information is forwarded by| | |
| | another RC at the same | | |
| | level. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (12) | The routing protocol MUST | Yes | Section 7.2.|
| | provide a mechanism to | | |
| | prevent information | | |
| |propagated from a Level N+1| | |
| | RA's RC into the Level N | | |
| | RA's RC from being | | |
| | re-introduced into the | | |
| | Level N+1 RA's RC. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (13) | The routing protocol MUST | Yes | Section 7.2.|
| | provide a mechanism to | | |
| | prevent information | | |
| |propagated from a Level N-1| | |
| | RA's RC into the Level N | | |
| | RA's RC from being | | |
| | re-introduced into the | | |
| | Level N-1 RA's RC. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 3.2 (14) | Instance of a Level N | Yes | Sections 2, |
| | routing function and an | | 3, and 7. |
| | instance of a Level N+1 | | |
| | routing function in the | | |
| | same system. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (15) | The Level N routing | Not described | N/A |
| | function is on a separate | but possible. | |
| | system than the Level | | |
| | N+1 routing function. | | |
+----------+---------------------------+---------------+-------------+
| 3.3 (16) |The RC MUST support static | The automation| Sections 2 |
| | (i.e., operator assisted) | requirement is|and 3. Refer |
| | and MAY support automated | ambiguous. | to RFC 2328 |
| | configuration of the | OSPF supports | for OSPF |
| |information describing its | auto-discovery| auto- |
| |relationship to its parent | of neighbors | discovery. |
| | and its child within the | and topology. | |
| | hierarchical structure | Default and | |
| | (including RA ID and RC | automatically | |
| | ID). | configured | |
| | | polices are | |
| | | out of scope. | |
+----------+---------------------------+---------------+-------------+
| 3.3 (17) |The RC MUST support static |Yes - when OSPF|RFC 2328 and |
| | (i.e., operator assisted) |area maps to RA|Section 11.1.|
| | and MAY support automated | discovery is | |
| | configuration of the | automatic. | |
| |information describing its | | |
| | associated adjacencies to | | |
| | other RCs within an RA. | | |
+----------+---------------------------+---------------+-------------+
| 3.3 (18) |The routing protocol SHOULD| Yes | RFC 2328. |
| |support all the types of RC| | |
| | adjacencies described in | | |
| |Section 9 of [G.7715]. The | | |
| | latter includes congruent | | |
| |topology (with distributed | | |
| | RC) and hubbed topology | | |
| |(e.g., note that the latter| | |
| | does not automatically | | |
| | imply a designated RC). | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 3.4 (19) |The routing protocol SHOULD| Yes |RFC 2328, RFC|
| | be capable of supporting | | 5250, and |
| |architectural evolution in | |Section 11.2.|
| | terms of the number of | | |
| |hierarchical levels of RAs,| | |
| |as well as the aggregation | | |
| | and segmentation of RAs. | | |
+----------+---------------------------+---------------+-------------+
|3.5.2 (20)|Advertisements MAY contain | | |
| |the following common set of| | |
| | information regardless of | | |
| | whether they are link or | | |
| | node related: | | |
| | - RA ID of the RA to | Yes | Section |
| | which the | | 7.2.1. |
| | advertisement is | | |
| | bounded | | |
| | - RC ID of the entity | Yes | RFC 2328. |
| | generating the | | |
| | advertisement | | |
| | - Information to | Yes |RFC 2328, RFC|
| | uniquely identify | | 5250. |
| | advertisements | | |
| | - Information to | No - Must | |
| | determine whether an |compare to old.| |
| | advertisement has | | | | | been updated | | |
| | - Information to | Yes | Section |
| | indicate when an | | 7.2.1. |
| | advertisement has been| | |
| | derived from a | | |
| | different level RA. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
|3.5.3 (21)|The Node Attributes' Node |Yes - Prefixes | RFC 5786, |
| |ID and Reachability must be| only for | Sections 4 |
| | advertised. It MAY be | reachability. | and 6. |
| | advertised as a set of | | |
| |associated external (e.g., | | |
| | User Network Interface | | |
| | (UNI)) address/address | | |
| | prefixes or a set of | | |
| | associated Subnetwork | | |
| | Point Pool (SNPP) link | | |
| | IDs/SNPP ID prefixes, the | | |
| |selection of which MUST be | | |
| | consistent within the | | |
| | applicable scope. | | |
+----------+---------------------------+---------------+-------------+
|3.5.4 (22)| The Link Attributes' Local| Yes | Section 6.1.|
| | SNPP link ID, Remote SNPP | | |
| |link ID, and layer specific| | |
| | characteristics must be | | |
| | advertised. | | |
+----------+---------------------------+---------------+-------------+
|3.5.4 (23)| Link Signaling Attributes | Yes | Section 5, |
| |other than Local Adaptation| | RFC 4652 - |
| |(Signal Type, Link Weight, | | Section |
| | Resource Class, Local | | 5.3.1. |
| | Connection Types, Link | | |
| | Capacity, Link | | |
| | Availability, Diversity | | |
| | Support). | | |
+----------+---------------------------+---------------+-------------+
|3.5.4 (24)| Link Signaling Local | Yes | Section 5.1.|
| | Adaptation. | | |
+----------+---------------------------+---------------+-------------+
| 5 (25) | The routing adjacency | Yes | Sections 2, |
| | topology (i.e., the | | 3, and 6. |
| |associated PC connectivity | | |
| |topology) and the transport| | |
| |network topology SHALL NOT | | |
| |be assumed to be congruent.| | |
+----------+---------------------------+---------------+-------------+
| 5 (26) |The routing topology SHALL | Yes |RFC 2328, RFC|
| | support multiple links | | 3630. |
| | between nodes and RAs. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 5 (27) |The routing protocol SHALL | Yes |RFC 2328, RFC|
| | converge such that the | | 5250. |
| | distributed Routing | | |
| | Databases (RDBs) become | | |
| |synchronized after a period| | |
| | of time. | | |
+----------+---------------------------+---------------+-------------+
| 5 (28) |Self-consistent information|Yes - However, | Section 7.1.|
| | at the receiving level | this is not a | |
| | resulting from any | routing | |
| | transformation (filter, | protocol | |
| | summarize, etc.) and | function. | |
| | forwarding of information | | |
| | from one RC to RC(s) at | | |
| | different levels when | | |
| |multiple RCs are bound to a| | |
| | single RA. | | |
+----------+---------------------------+---------------+-------------+
| 5 (29) | In order to support |Partial - OSPF |RFC 2328 and |
| | operator-assisted changes | supports the | RFC 5250. |
| | in the containment | purging of | |
| | relationships of RAs, the | stale | |
| | routing protocol SHALL |advertisements | |
| |support evolution in terms |and origination| |
| | of the number of | of new. The | |
| |hierarchical levels of RAs.|non-disruptive | |
| | For example, support of | behavior is | |
| | non-disruptive operations |implementation | |
| |such as adding and removing| specific. | |
| | RAs at the top/bottom of | | |
| | the hierarchy, adding or | | |
| | removing a hierarchical | | |
| |level of RAs in or from the| | |
| |middle of the hierarchy, as| | |
| | well as aggregation and | | |
| | segmentation of RAs. | | |
+----------+---------------------------+---------------+-------------+
| 5 (30) | A collection of links and |Yes - Within an| Sections 4 |
| |nodes such as a subnetwork | RA it must be | and 6. |
| | or RA MUST be able to | consistent. | |
| | represent itself to the | | |
| | wider network as a single | | |
| |logical entity with only | | |
| |its external links visible | | |
| | to the topology database. | | |
+----------+---------------------------+---------------+-------------+13. References 📚✨
Okay bestie, here's the reading list 🤓 Normative means you really gotta know these, and informative means they're good background that's still super useful 💅
13.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
- [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 🦋
- [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. 🌸
- [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. 💜
- [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. 🧚
- [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. 🍓
- [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008. 🌈
- [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions", RFC 5786, March 2010. ⭐
13.2. Informative References
- [RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", RFC 4258, November 2005. 🫶
- [RFC4652] Papadimitriou, D., Ed., Ong, L., Sadler, J., Shew, S., and D. Ward, "Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements", RFC 4652, October 2006. 💖
- [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009. 🔥
- [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012. 👑
- [OSPF-SEC] Hartman, S. and Zhang, D., "Analysis of OSPF Security According to KARP Design Guide", Work in Progress, November 2012. 🙈
- [G.7715] ITU-T Rec. G.7715/Y.1706, "Architecture and Requirements in the Automatically Switched Optical Network", June 2002. ✨
- [G.7715.1] ITU-T Rec. G.7715.1/Y.1706.1, "ASON Routing Architecture and Requirements for Link State Protocols", February 2004. 🎀
- [G.805] ITU-T Rec. G.805, "Generic Functional Architecture of Transport Networks)", March 2000. 🦋
- [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the automatically switched optical network", February 2012. 💅
14. Acknowledgements 🫶🌷
The editors would like to thank Lyndon Ong, Remi Theillaud, Stephen Shew, Jonathan Sadler, Deborah Brungard, Lou Berger, and Adrian Farrel for their useful comments and suggestions. The whole squad 🥹💜
14.1. RFC 5787 Acknowledgements
The author would like to thank Dean Cheng, Acee Lindem, Pandian Vijay, Alan Davey, Adrian Farrel, Deborah Brungard, and Ben Campbell for their useful comments and suggestions. Main character energy for the whole crew 🎀
Lisa Dusseault and Jari Arkko provided useful comments during IESG review. 🌸
Question 14 of Study Group 15 of the ITU-T provided useful and constructive input. Iconic teamwork, periodt 🌈✨
Appendix A. ASON Terminology ✨
okay so this doc only uses a handful of terms, and they're all ASON stuff 🦋 here's the tea:
Administrative domain: (See Recommendation [G.805].) bestie, for the purposes of [G.7715.1], an administrative domain is the whole pile of resources owned by one player, like a network operator, a service provider, or an end-user 💅 admin domains from different players don't overlap with each other at all.
Control plane: this is the one doing the call control and connection control jobs 📞 through signaling, it sets up and releases connections, and it may restore a connection if something fails 🔧
(Control) Domain: a collection of (control) entities grouped together for some particular purpose ✨ the control plane gets split into domains that match the administrative domains, and inside an administrative domain, further splits of the control plane keep getting applied recursively 🌀 a routing control domain is an abstract entity that hides the details of the RC distribution 🫶
External NNI (E-NNI): interfaces that sit between protocol controllers, between control domains 🌸
Internal NNI (I-NNI): interfaces that sit between protocol controllers, but inside a control domain 🧚
Link: (See Recommendation G.805.) a "topological component" that describes a fixed relationship between a "subnetwork" or "access group" and another "subnetwork" or "access group" 💖 links aren't limited to being provided by a single server trail, so no tunnel vision here 😌
Management plane: this plane handles management functions for the transport plane, the control plane, and the whole system ✨ it also coordinates between all the planes 🎀 the management functional areas it covers are performance, fault, configuration, accounting, and security management 💜
Management domain: (See Recommendation G.805.) a management domain is a collection of managed objects grouped to meet organizational needs, based on geography, technology, policy, or some other structure 🍓 it's for a number of functional areas like Fault, Configuration, Accounting, Performance, and Security (FCAPS), so control stays consistent 🧁 management domains can be disjoint, contained, or overlapping, which means the resources in one administrative domain can be spread across several possibly overlapping management domains 🌈 the same resource can belong to several management domains at once, but a management domain shall not cross the border of an administrative domain 🚧
Subnetwork Point (SNP): the SNP is a control-plane abstraction representing an actual or potential transport-plane resource ✨ SNPs (in different subnetwork partitions) may represent the same transport resource, and a one-to-one correspondence should not be assumed 🙈
Subnetwork Point Pool (SNPP): a set of SNPs grouped together for routing purposes 🌸
Termination Connection Point (TCP): a TCP represents either the output of a Trail Termination function or the input to a Trail Termination Sink function 🦋
Transport plane: this plane gives bidirectional or unidirectional transfer of user information from one location to another 🚀 it can also transfer some control and network management information 💅 the transport plane is layered, and it's equivalent to the Transport Network defined in Recommendation G.805 🔥
User Network Interface (UNI): interfaces that sit between protocol controllers, between a user and a control domain 🫶 Note: there's no routing function associated with a UNI reference point, so it's giving no routing vibes at all 😭
Appendix B. ASON Routing Terminology 🌷
this doc also uses these routing terms, so let's get into it 💜
Routing Area (RA): an RA is a partition of the transport plane, and its identifier is used within the control plane to represent that partition 🎀 per [G.8080], an RA is defined by a set of subnetworks, the links that interconnect them, and the interfaces representing the ends of the links exiting that RA 🧚 an RA can contain smaller RAs that are interconnected by links 🌈 and when you keep subdividing, you end up with an RA containing two subnetworks joined by a single link 🫧
Routing Database (RDB): a repository for the local topology, network topology, reachability, and other routing information ✨ it gets updated as part of the routing information exchange and may also contain information that's configured 💖 the RDB may contain routing information for more than one routing area (RA) 🍓
Routing Components: these are the ASON routing architecture functions 🦋 they can be classified as protocol independent (Link Resource Manager (LRM), Routing Controller (RC)) or protocol specific (Protocol Controller (PC)) 💅
Routing Controller (RC): the RC handles (abstract) information needed for routing and the routing information exchange with peering RCs, and it does all this by operating on the RDB 🧠 it has access to a view of the RDB, and it's protocol independent 🌸
Note: since the RDB may contain routing information about multiple RAs (and possibly multiple layer networks), the RCs accessing the RDB may share the routing information 🤝
Link Resource Manager (LRM): the LRM supplies all the relevant component and TE link information to the RC 📦 it tells the RC about any state changes of the link resources it controls ⚡
Protocol Controller (PC): the PC handles protocol-specific message exchanges according to the reference point over which the information is exchanged (e.g., E-NNI, I-NNI), plus internal exchanges with the RC 🧚 the PC function is protocol dependent 🎀
Appendix C. Changes from RFC 5787 💌
okay so here's everything that changed from RFC 5787, and honestly it's a glow-up 🌟
This document contains the following changes from RFC 5787:
- this document is on the Standards Track now instead of Experimental 🚀 it reflects what was learned from implementing RFC 5787 and from interoperability testing 🧪 that also meant changing the IANA Considerations 📋
- there's a new Section 3 on Terminology and Identification, which maps the key ASON entities to OSPF entities 🗺️
- sections were reorganized so terminology gets explained before the prefix extensions are defined 📚
- there's a new Section 11, Management Considerations, which describes how existing OSPF mechanisms address ASON requirements on Routing Area changes 🛠️
- there's a new Section 12 that compares the document to the requirements in RFC 4258 ✅
- the prefix format now references RFC 5786 instead of defining a separate format, and the Node Attribute TLV in RFC 5786 has been updated as a result 💜
- Routing Information Advertisements were simplified from RFC 5787 ✨
- review comments from ITU-T SG15 and the IESG were incorporated 🫶
Authors' Addresses 💌
okay the authors, the legends who made this happen 👑
Andrew G. Malis
Verizon Communications
60 Sylvan Rd.
Waltham, MA 02451 USA
EMail: andrew.g.malis@verizon.comAcee Lindem
Ericsson
102 Carric Bend Court
Cary, NC 27519
EMail: acee.lindem@ericsson.comDimitri Papadimitriou
Alcatel-Lucent
Copernicuslaan, 50
2018 Antwerpen, Belgium
EMail: dimitri.papadimitriou@alcatel-lucent.comthat's a wrap, bestie!! 🌈💖 every single detail is in place 🫶
📦 where this page comes from
- ietf: rfc6827 2013-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms