RFC 4652
Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements
RFC 4652: Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements ✨
Okay bestie, first things first 💖 here's the title block so you know who's behind this and what it's about 🎀
- RFC number: 4652
- Authors: D. Papadimitriou (Ed.) of Alcatel 👑, L. Ong of Ciena 🦋, J. Sadler of Tellabs 🌸, S. Shew of Nortel 💜, and D. Ward of Cisco ⭐
- Category: Informational 🧚
- Date: October 2006 📅
- Obsoletes / Updates: neither is listed in the title block 🙈
Status of This Memo
This memo gives information to the Internet community 🫶. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌈.
Copyright Notice
Copyright (C) The Internet Society (2006). 💅
Abstract
Okay so the Generalized MPLS (GMPLS) suite of protocols was built to control different switching technologies and different applications 🔥. That includes requesting TDM connections, like Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Networks (OTNs) 🦋.
This document checks how the IETF routing protocols hold up against the routing requirements for an Automatically Switched Optical Network (ASON), as defined by ITU-T ✨. It's giving "does this actually work?" energy 💀.
1. Introduction 🌸
Certain capabilities are needed to support the ITU-T Automatically Switched Optical Network (ASON) control plane architecture, as defined in [G.8080] 🎀.
[RFC4258] lays out the routing requirements for the GMPLS routing suite of protocols, so it can support the capabilities and functionality of ASON control planes identified in [G.7715] and in [G.7715.1] 💜. The ASON routing architecture gives a conceptual reference architecture, with functional components and common information elements defined so end-to-end routing works even when protocols are mixed, and so managing ASON networks gets easier 🧚. This description is only conceptual, though: no physical partitioning of these functions is implied 🙈.
BUT (and this is a big but) [RFC4258] doesn't cover GMPLS routing protocol applicability or capabilities 😭. So this document evaluates the IETF Routing Protocols against the requirements identified in [RFC4258] 💅. The result of that evaluation is in Section 5 🔥. A close look at applicability scenarios, and how those scenarios turned out, is in Section 6 ✨.
ASON (Routing) terminology sections are in Appendices A and B 📚.
2. 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] 🫶. These are the official vibes, so read them carefully 🔥.
The reader is expected to already know the terminology introduced in [RFC4258] 🤓.
3. Contributors 🌈
This document is the result of the CCAMP Working Group ASON Routing Solution design team's joint effort 👑. Iconic teamwork, honestly 🎀.
Dimitri Papadimitriou (Alcatel, Team Leader and Editor)
EMail: dimitri.papadimitriou@alcatel.be
Chris Hopps (Cisco)
EMail: chopps@rawdofmt.org
Lyndon Ong (Ciena Corporation)
EMail: lyong@ciena.com
Jonathan Sadler (Tellabs)
EMail: jonathan.sadler@tellabs.com
Stephen Shew (Nortel Networks)
EMail: sdshew@nortel.com
Dave Ward (Cisco)
EMail: dward@cisco.com4. Requirements: Overview 🦋
Here's what GMPLS routing protocols are expected to do so they can build the ASON hierarchical routing architecture (see [G.7715] and [G.7715.1]) 💅:
- Routing Areas (RAs) shall be uniquely identifiable within a carrier's network, each having a unique RA Identifier (RA ID) within the carrier's network 🔥.
- Within a RA (one level), the routing protocol shall support dissemination of hierarchical routing information (including summarized routing information for other levels) in support of an architecture of multiple hierarchical levels of RAs. The number of hierarchical RA levels that a routing protocol supports is implementation specific 🧚.
- The routing protocol shall support routing information based on a common set of information elements as defined in [G.7715] and [G.7715.1]. Those are divided between attributes about links and abstract nodes (each representing either a sub-network or simply a node) 💜. [G.7715] recognizes that the way routing information gets represented and exchanged will vary with the routing protocol used 🌸.
- The routing protocol shall converge, so the distributed Routing DataBases (RDB) become synchronized after a period of time ⏳.
To support dissemination of hierarchical routing information, the routing protocol must deliver:
- Processing of routing information exchanged between adjacent levels of the hierarchy (i.e., Level N+1 and N), including reachability and (upon policy decision) summarized topology information 🎀.
- Self-consistent information at the receiving level, resulting from any transformation (filter, summarize, etc.) and forwarding of information from one Routing Controller (RC) to RC(s) at different levels, when multiple RCs are bound to a single RA 👑.
- A mechanism to prevent re-introduction of information propagated into the Level N RA's RC back to the adjacent level RA's RC from which this information was originally received 🙈. No echo chamber allowed 💀.
Note: The number of hierarchical levels to be supported is routing protocol specific, and it reflects a containment relationship ✨.
Reachability information may be advertised either as a set of UNI Transport Resource address prefixes, or as a set of associated Subnetwork Point Pool (SNPP) link IDs/SNPP link ID prefixes, assigned and selected consistently within their applicability scope 🌈. The formats of the control plane identifiers in a protocol realization are implementation specific 🧚. Using a routing protocol within a RA should not restrict the choice of routing protocols for use in other RAs (child or parent) 💜. Not gonna lie, that's a very reasonable ask 💅.
As ASON doesn't restrict the control plane architecture choice, either a co-located architecture or a physically separated architecture may be used 🦋. A collection of links and nodes, such as a sub-network or RA, must be able to represent itself to the wider network as a single logical entity, with only its external links visible to the topology database 🫶.
5. Evaluation 🔥
This section evaluates how well existing IETF routing protocols support the requirements summarized from [RFC4258] in Section 4 💖. The candidate routing protocols are the Interior Gateway Protocol (IGP), which means OSPF and Intermediate System to Intermediate System (IS-IS), plus BGP 🌸. BGP is not addressed in the current version of this document 😭. BGP isn't considered a candidate protocol, mainly for these reasons:
- Non-support of TE information exchange. Each BGP router advertises only its path to each destination in its vector for loop avoidance, with no costs or hop counts. Each BGP router knows little about network topology 🙈.
- BGP can only advertise routes that are eligible for use (local RIB), or routing loops can occur. There is one best route per prefix, and that's the route that gets advertised 💀.
- BGP isn't widely deployed in optical equipment and networks 🌈.
5.1. Terminology and Identification 🎀
- Pi is a physical (bearer/data/transport plane) node 🧚.
- Li is a logical control plane entity that is associated to a single data plane (abstract) node. The Li is identified by the TE Router_ID. The latter is a control plane identifier defined as follows 💜:
[RFC3630]: Router_Address (top level) TLV of the Type 1 TE LSA
[RFC3784]: Traffic Engineering Router ID TLV (Type 134)Note: This document doesn't define what the TE Router ID is. It simply states the use of the TE Router ID to identify Li. [RFC3630] and [RFC3784] provide the definitions 🫶.
- Ri is a logical control plane entity that is associated to a control plane "router". The latter is the source for topology information that it generates and shares with other control plane "routers" 👑. The Ri is identified by the (advertising) Router_ID 🦋:
[RFC2328]: Router ID (32-bit)
[RFC1195]: IS-IS System ID (48-bit)The Router_ID, which is represented by Ri and which corresponds to the RC_ID [RFC4258], doesn't get involved in identifying the logical entities that represent data plane resources, like links 🌸. The Routing DataBase (RDB) is associated to the Ri 💖. Note that, in the ASON context, an arrangement where multiple Ris announce routing information related to a single Li is under evaluation 🔥.
Aside from the Li/Pi mappings, these identifiers aren't assumed to be in any particular entity relationship, except that the Ri may have multiple Lis in its scope 🌈. The relationship between Ri and Li is simple at any moment in time: an Li may be advertised by only one Ri at any time. However, an Ri may advertise a set of one or more Lis 🧚. So the routing protocol MUST be able to advertise multiple TE Router IDs (see Section 5.7) 💅.
Note: Si is a control plane signaling function associated with one or more Lis 🦋. This document doesn't assume any specific constraint on the relationship between Si and Li. It also doesn't discuss issues of control plane accessibility for the signaling function, and it makes no assumptions about how control plane accessibility to the Si is achieved 🫶.
5.2. RA Identification 💜
G.7715.1 notes some necessary characteristics for RA identifiers. For example, they may provide scope for the Ri, and they must be provisioned to be unique within an administrative domain 👑. The RA ID format itself is allowed to be derived from any global address space 🎀. Provisioning RA IDs for uniqueness is outside the scope of this document 🙈.
Under these conditions, GMPLS link state routing protocols provide the capability for RA Identification without further modification ✨.
5.3. Routing Information Exchange 🦋
okay so this section is about routing info being swapped between Ri entities through routing adjacencies, all inside one hierarchical level 🧚. Mapping routing info between levels needs its own special handling, which is covered in Section 5.5 💅
Here's the big thing: the control plane never sends Pi identifiers 🙅♀️. Those are data plane addresses, and the Li/Pi mapping stays (link) local. The transport LMP document [RFC4394] describes that exchange if you want to see it in action ✨
Quick example so it clicks 🎀. The transport plane identifier is the Pi (the ID given to the physical element), and it could look like "666B.F999.AF10.222C". The control plane identifier is the Li (the ID given by the control plane), and it could look like "192.0.2.1".
So the control plane only shares the control plane identifier ("192.0.2.1") and never the transport plane one ("666B.F999.AF10.222C"). The mapping stays local. When Si gets a control plane message asking for "192.0.2.1", it just knows that means the data plane entity with transport plane identifier "666B.F999.AF10.222C" 🧠✨ iykyk, it's giving telepathy.
Also, the Li and Pi address spaces may be identical 🌸
The control plane carries:
- its view of the data plane link end-points and other link connection end-points 🔗
- the identifiers scoped by the Lis, which are referred to as an associated IPv4/IPv6 addressing space 💜 Note that these identifiers may be either bundled TE link addresses or component link addresses.
- when OSPF or IS-IS is the IGP supporting traffic engineering, [RFC3477] RECOMMENDS that the Li value (referred to as the "LSR Router ID") be set to the TE Router ID value 👑
Which means OSPF and IS-IS already carry enough node identification info without any extra changes 🙌 literally iconic.
5.3.1. Link Attributes 💎
[RFC4258] gives us a list of link attributes and characteristics that a routing protocol needs to advertise 📋 All TE link attributes and characteristics are handled by OSPF and IS-IS right now (see Table 1), except Local Adaptation support. The reason is that GMPLS routing doesn't currently use dedicated TE link attributes to describe cross/inter-layer relationships 🥲
Bandwidth also needs more thought 💭 GMPLS Routing defines an Interface Switching Capability Descriptor (ISCD), which tells you the (maximum/ minimum) bandwidth per priority that an LSP can use. It's usually paired with the Unreserved Bandwidth sub-TLV, which tells you how much bandwidth on a TE link is still unreserved 🫶
In the ASON context, there are other ways to represent bandwidth accounting 🌈 for example, as a set of tuples <signal_type; number of unallocated timeslots>. That one might also need new signal types beyond the ones defined in [RFC3946], so you can represent support for contiguously concatenated signals, meaning STS-(3xN)c SPE / VC-4-Nc, where N = 4, 16, 64, 256.
Still, the method in [RFC4202] is the most straightforward option, because it doesn't need any bandwidth accounting change from an LSR perspective 🎯 (especially when the ISCD sub-TLV info is combined with the Unreserved Bandwidth sub-TLV info). Slay 💅
Here's the GMPLS OSPF mapping 👀:
Link Characteristics GMPLS OSPF
----------------------- ----------
Local SNPP link ID Link-local part of the TE link identifier
sub-TLV [RFC4203]
Remote SNPP link ID Link remote part of the TE link identifier
sub-TLV [RFC4203]
Signal Type Technology specific part of the Interface
Switching Capability Descriptor sub-TLV
[RFC4203]
Link Weight TE metric sub-TLV [RFC3630]
Resource Class Administrative Group sub-TLV [RFC3630]
Local Connection Types Switching Capability field part of the
Interface Switching Capability Descriptor
sub-TLV [RFC4203]
Link Capacity Unreserved bandwidth sub-TLV [RFC3630]
Max LSP Bandwidth part of the Interface
Switching Capability Descriptor sub-TLV
[RFC4203]
Link Availability Link Protection sub-TLV [RFC4203]
Diversity Support SRLG sub-TLV [RFC4203]
Local Adaptation support See above
Table 1. TE link attributes in GMPLS OSPF-TEAnd the GMPLS IS-IS one 🧁:
Link Characteristics GMPLS IS-IS
----------------------- -----------
Local SNPP link ID Link-local part of the TE link identifier
sub-TLV [RFC4205]
Remote SNPP link ID Link-remote part of the TE link identifier
sub-TLV [RFC4205]
Signal Type Technology specific part of the Interface
Switching Capability Descriptor sub-TLV
[RFC4205]
Link Weight TE Default metric [RFC3784]
Resource Class Administrative Group sub-TLV [RFC3784]
Local Connection Types Switching Capability field part of the
Interface Switching Capability Descriptor
sub-TLV [RFC4205]
Link Capacity Unreserved bandwidth sub-TLV [RFC3784]
Max LSP Bandwidth part of the Interface
Switching Capability Descriptor sub-TLV
[RFC4205]
Link Availability Link Protection sub-TLV [RFC4205]
Diversity Support SRLG sub-TLV [RFC4205]
Local Adaptation support See above
Table 2. TE link attributes in GMPLS IS-IS-TE📝 Note: Link Attributes represent layer resource capabilities and their utilization, so the IGP should be able to advertise these attributes on a per-layer basis 🌸
5.3.2. Node Attributes 🧩
Node attributes are the "Logical Node ID" (from Section 5.1) plus the reachability info described in Section 5.3.3 ✨
5.3.3. Reachability Information 🗺️
Reachability can be advertised using the techniques in [OSPF-NODE]. The local addresses go in an OSPF TE LSA node attribute TLV, and there's a specific sub-TLV for each address family (like IPv4 and IPv6) 🌷 But [OSPF-NODE] is restricted to advertising Host addresses and not prefixes, so it needs an enhancement (more on that below) 🙈
To advertise blocks of reachable address prefixes, you also need a summarization mechanism. That mechanism may take the form of a prefix length (which says how many significant bits are in the prefix) or a network mask 💜
IS-IS doesn't have a similar mechanism 😬 And the Extended IP Reachability TLV [RFC3784] is focused on IP reachable end-points (terminating points), as its name says 🙃
5.4. Routing Information Abstraction 🎀
G.7715.1 describes both static and dynamic ways to abstract routing info for advertisement at a different level of the routing hierarchy 🪄 But the info still gets advertised as link and node advertisements, matching the link state routing protocol used at that level. So no special new capabilities are needed in the routing protocol, beyond being able to tell locally when routing info came from outside a particular RA 💅
How the abstraction itself works is outside the scope of GMPLS routing protocols 🙌
5.5. Dissemination of Routing Information in Support of Multiple Hierarchal Levels of RAs 🪜
G.7715.1 doesn't define specific mechanisms for multiple hierarchical levels of RAs beyond the abstraction support we just talked about 🥹 Here's the problem: if RCs bound to adjacent levels were allowed to redistribute routing info in both directions, with no extra mechanisms, they couldn't tell when routing info was looping 🔁💀
To stop that looping, IS-IS [RFC1195] only allows advertising routing info upward in the level hierarchy, and doesn't allow advertising it downward 🚫⬇️ [RFC2966] defines the up/down bit so you can advertise downward with the "IP Internal Reachability Information" TLV (Type 128) and the "IP External Reachability Information" TLV (Type 130). [RFC3784] extends this to the "Extended IP Reachability" TLV (Type 135) 💖
Here's how the mechanism works. The up/down bit is set to 0 when routing info is first injected into IS-IS. If routing info gets advertised from a higher level to a lower level, the up/down bit is set to 1, which means it has traveled down the hierarchy ⬇️ Routing info with the up/down bit set to 1 may only be advertised down the hierarchy, meaning to lower levels 🔒 This works no matter how many levels there are 🌈
However, this doesn't apply to the "Extended IS Reachability" TLV (Type 22) used to propagate the summarized topology (see Section 5.3), the traffic engineering info listed in Table 1, or the reachability info (see Section 5.3.3) 🧐
OSPFv2 [RFC2328] stops inter-area routes (learned from area 0) from being passed back to area 0 🚧 But GMPLS uses Type 10 (area-local scope) LSAs to propagate TE info [RFC3630], [RFC4202] 🌟 Type 10 Opaque LSAs aren't flooded beyond the borders of their associated area. So there needs to be a way for a Type 10 Opaque LSA to carry the info that a piece of routing info was learned from a higher-level RC when it's passed down to a lower-level RC 🧠 Any downward RC from this level that receives an LSA with this info would omit that info from the LSA, so it doesn't sneak back into a higher-level RC 🙅♀️💜
5.6. Routing Protocol Convergence ⚡
Link state protocols were designed to propagate detected topological changes, like interface failures and link attribute modifications 🏃♀️ The convergence period is short and involves a minimum of routing info exchange ⭐
So, existing routing protocol convergence already includes mechanisms that are sufficient for ASON applications 👑🫶
5.7. Routing Information Scoping ✨
okay so bestie, this is the part where the routing protocol has to keep track of who's who 💅 The routing protocol MUST support a single Ri advertising on behalf of more than one Li 🫶 Since each Li is identified by a unique TE Router ID, the routing protocol MUST be able to advertise multiple TE Router IDs. That is, for [RFC3630], multiple Router Addresses and for [RFC3784] multiple Traffic Engineering Router Ids 🦋
The Link sub-TLV that is currently part of the top level Link TLV associates the link to the Router_ID 🌸 However, having the Ri advertising on behalf of multiple Lis creates the following issue, as there is no longer a 1:1 relationship between the Router_ID and the TE Router_ID, but a 1:N relationship is possible (see Section 5.1). As the link-local and link-remote (unnumbered) ID association may not be unique per abstract node (per Li unicity), the advertisement needs to indicate the remote Lj value and rely on the initial discovery process to retrieve the {Li;Lj} relationship(s). In brief, as unnumbered links have their ID defined on per Li bases, the remote Lj needs to be identified to scope the link remote ID to the local Li. Therefore, the routing protocol MUST be able to disambiguate the advertised TE links so that they can be associated with the correct TE Router ID. 😭 this is so important, the links need to know whose they are!!
Moreover, when the Ri advertises on behalf multiple Lis, the routing protocol MUST be able to disambiguate the advertised reachability information (see Section 5.3.3) so that it can be associated with the correct TE Router ID. 💖
6. Evaluation Scenarios 🌈
The evaluation scenarios are the following; they are respectively referred to as cases 1, 2, 3, and 4. 🧚
In Figure 1, below,
- R3 represents an LSR with all components collocated. 🍓
- R2 shows how the "router" component may be disjoint from the node. 🎀
- R1 shows how a single "router" may manage multiple nodes. 👑
------------------- -------
|R1 | |R2 |
| | | | ------
| L1 L2 L3 | | L4 | |R3 |
| : : : | | : | | |
| : : : | | : | | L5 |
Control ---+-----+-----+--- ---+--- | : |
Plane : : : : | : |
----------------+-----+-----+-----------+-------+---+--+-
Data : : : : | : |
Plane -- : -- -- | -- |
----|P1|--------|P3|--------|P4|------+-|P5|-+-
-- \ : / -- -- | -- |
\ -- / | |
|P2| ------
--
Figure 1. Evaluation Cases 1, 2, and 3Case 1 as represented refers either to direct links between edges or to "logical links" as shown in Figure 2 (or any combination of them). 🦋
------ ------
| | | |
| L1 | | L2 |
| : | | : |
| : R1| | : R2|
Control Plane --+--- --+---
Elements : :
------------------+-----------------------------+------------------
Data Plane : :
Elements : :
----+-----------------------------+-----
| : : |
| --- --- --- |
| | |----------| P |----------| | |
---+--| | --- | |---+---
| | | | | |
| | P1|-------------------------| P2| |
| --- --- |
----------------------------------------
Figure 2. Case 1 with Logical LinksAnother case (referred to as Case 4) is constituted by the Abstract Node as represented in Figure 3. There is no internal structure associated (externally) to the abstract node. 🌸
--------------
|R4 |
| |
| L6 |
| : |
| ...... |
---:------:---
Control Plane : :
+------+------+------+
Data Plane : :
---:------:---
|P8 : : |
| -- -- |
--+-|P |----|P |-+--
| -- -- |
--------------
Figure 3. Case 4: Abstract NodeNote: the "signaling function" referred to as Si, i.e., the control plane entity that processes the signaling messages, is not represented in these figures. 🙈
7. Summary of Necessary Additions to OSPF and IS-IS 💜
The following sections summarize the additions to be provided to OSPF and IS-IS in support of ASON routing. 🔥
7.1. OSPFv2 🍓
Reachability Extend Node Attribute sub-TLVs to support address
prefixes (see Section 5.3.3).
Link Attributes Representation of cross/inter-layer relationships
in link top-level link TLV (see Section 5.3.1).
Optionally, provide for per-signal-type bandwidth
accounting (see Section 5.3.1).
Scoping TE link advertisements to allow for retrieving
their respective local-remote TE Router_ID
relationship(s) (see Section 5.7).
Prefixes part of the reachability advertisement
(using Node Attribute top-level TLV) needs to be
associated to its respective local TE Router_ID
(see Section 5.7).
Hierarchy Provide a mechanism by which Type 10 Opaque LSA may
carry the information that a particular piece of
routing information has been learned from a
higher-level RC when propagated to a lower-level RC
(so as not to re-introduce this information into a
higher-level RC).7.2. IS-IS 🎀
Reachability Provide for reachability advertisement (in the form
of reachable TE prefixes).
Link Attributes Representation of cross/inter-layer relationships
in Extended IS Reachability TLV (see Section
5.3.1).
Optionally, provide for per-signal-type bandwidth
accounting (see Section 5.3.1).
Scoping Extended IS Reachability TLVs to allow for
retrieving their respective local-remote TE
Router_ID relationship(s) (see Section 5.7).
Prefixes part of the reachability advertisement
needs to be associated to its respective local TE
Router_ID (see Section 5.7).
Hierarchy Extend the up/down bit mechanisms to propagate the
summarized topology (see Section 5.3) and traffic
engineering information as listed in Table 1, as
well as reachability information (see Section
5.3.3).8. Security Considerations 🚨
⚠️ Okay bestie, this section is SERIOUS, so read it properly!! ⚠️
The introduction of a dynamic control plane to an ASON network exposes it to additional security risks that may have been controlled or limited by the use of management plane solutions. The routing protocols play a part in the control plane and may be attacked so that they become unstable or provide incorrect information for use in path computation or by the signaling protocols. 💀
Nevertheless, there is no reason why the control plane components cannot be secured, and the security mechanisms developed for the routing protocol and used within the Internet are equally applicable within an ASON context. 🫶
[RFC4258] describes the requirements for security of routing protocols for the Automatically Switched Optical Network. Reference is made to [M.3016], which lays out the overall security objectives of confidentiality, integrity, and accountability. These are well discussed for the Internet routing protocols in [THREATS]. 🔐
A detailed discussion of routing threats and mechanisms that are currently deployed in operational networks to counter these threats is found in [OPSECPRACTICES]. A detailed listing of the device capabilities that can be used to support these practices can be found in [RFC3871]. ✨
9. Acknowledgements 🌷
The authors would like to thank Adrian Farrel for having initiated the proposal of an ASON Routing Solution Design Team and the ITU-T SG15/Q14 for their careful review and input. 💖
10. References 📚
10.1. Normative References 🧚
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP
and dual environments", RFC 1195, December 1990.
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide
Prefix Distribution with Two-Level IS-IS", RFC
2966, October 2000.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", RFC 3784, June 2004.
[RFC3871] Jones, G., Ed., "Operational Security Requirements
for Large Internet Service Provider (ISP) IP
Network Infrastructure", RFC 3871, September 2004.
[RFC3946] Mannie, E. and D. Papadimitriou, "Generalized
Multi-Protocol Label Switching (GMPLS) Extensions
for Synchronous Optical Network (SONET) and
Synchronous Digital Hierarchy (SDH) Control", RFC
3946, 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.
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed.,
"Intermediate System to Intermediate System (IS-IS)
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4205, October 2005.
[RFC4258] Brungard, D., "Requirements for Generalized Multi-
Protocol Label Switching (GMPLS) Routing for the
Automatically Switched Optical Network (ASON)", RFC
4258, November 2005.10.2. Informative References 🦋
okay so these are the "good to know" references, not the must-read ones 📚
[RFC4394] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J.,
and D. Papadimitriou, "A Transport Network View of
the Link Management Protocol (LMP)", RFC 4394,
February 2006.
[OPSECPRACTICES] Kaeo, M., "Operational Security Current Practices",
Work in Progress, July 2006.
[OSPF-NODE] Aggarwal, R. and K. Kompella, "Advertising a
Router's Local Addresses in OSPF TE Extensions",
Work in Progress, June 2006.
[THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic
Threats to Routing Protocols", RFC 4593, October
2006.For info on ITU documents, check http://www.itu.int 🌐
[G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and
Requirements for the Automatically Switched Optical
Network (ASON)", June 2002.
[G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing
Architecture and Requirements for Link State
Protocols", November 2003.
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the
Automatically Switched Optical Network (ASON)",
June 2006.
[M.3016] ITU-T Rec. M.3016.0, "Security for the Management
Plane: Overview", May 2005.Appendix A. ASON Terminology 🧚
okay this is the glossary bit, and it's giving ASON vocab overload 💀 but it's so important to know what everyone means!
This document makes use of the following terms:
- Administrative domain (see Recommendation G.805): for the purposes of [G.7715.1], an administrative domain is the stuff that belongs to one player, like a network operator, a service provider, or an end-user. administrative domains of different players don't overlap with each other 🫶
- Control plane: this is the call and connection control crew. through signaling, it sets connections up and tears them down, and it can restore a connection if something fails 🔧
- (Control) Domain: a bunch of control entities grouped together for some purpose. the control plane gets split into domains that match the administrative domains, and inside each one, the splitting keeps going recursively. a routing control domain is an abstract thing that hides how the RC distribution works 🎀
- External NNI (E-NNI): interfaces sitting between protocol controllers that live in different control domains 🌸
- Internal NNI (I-NNI): interfaces sitting between protocol controllers that live inside the same control domain 🌷
- Link (see Recommendation G.805): a "topological component" that describes a fixed relationship between one "subnetwork" or "access group" and another one. links aren't limited to being provided by a single server trail 🔗
- Management 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 collection of managed objects grouped to meet organizational needs, based on geography, technology, policy, or some other structure, and across functional areas like fault, configuration, accounting, performance, and security (FCAPS). the goal is consistent control. management domains can be disjoint, contained, or overlapping, so the resources in one administrative domain can be spread across several overlapping management domains 🗂️
the same resource can be in several management domains at once, but a management domain shall not cross the border of an administrative domain 🚧
- Subnetwork Point (SNP): a control plane abstraction that stands for an actual or potential transport plane resource. SNPs in different subnetwork partitions might 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 is either the output of a Trail Termination function or the input to a Trail Termination Sink function 🔌
- Transport plane: provides bi-directional or unidirectional transfer of user information from one location to another. it can also carry some control and network management information. it's layered, and it's equivalent to the Transport Network defined in the G.805 Recommendation 🛤️
- User Network Interface (UNI): interfaces sitting between protocol controllers, one side being a user and the other side being a control domain. note: there's no routing function tied to a UNI reference point 🙅♀️
Appendix B. ASON Routing Terminology 🌈
the routing side of the ASON glossary, and it's just as iconic 👑
This document makes use of the following terms:
- Routing Area (RA): an RA is a partition of the data plane, and its identifier is used inside the control plane to represent that partition. per [G.8080], an RA is defined by a set of sub-networks, the links connecting them, and the interfaces representing the ends of the links leaving that RA. an RA can contain smaller RAs connected by links. the smallest possible version is an RA containing two sub-networks joined by one single link 🗺️
- Routing Database (RDB): the repository for local topology, network topology, reachability, and other routing info. it gets updated as part of the routing information exchange, and it can also hold configured information. an RDB can hold routing info for more than one Routing Area (RA) 🗃️
- Routing Components: the functions of the ASON routing architecture. they split into protocol independent ones (Link Resource Manager or LRM, Routing Controller or RC) and protocol specific ones (Protocol Controller or PC) ✨
- Routing Controller (RC): handles the (abstract) information needed for routing, and handles routing information exchange with peering RCs by working on the RDB. the RC has access to a view of the RDB. the RC is protocol independent 🧠
note: since the RDB can hold routing info for multiple RAs (and maybe multiple layer networks), the RCs accessing the RDB may share the routing information 🤝
- Link Resource Manager (LRM): supplies all the relevant component and TE link info to the RC, and tells the RC about any state changes to the link resources it controls 📡
- Protocol Controller (PC): handles protocol-specific message exchanges, based on the reference point the info is exchanged over (like E-NNI or I-NNI), plus internal exchanges with the RC. the PC function is protocol dependent 🧩
Authors' Addresses 💌
here's where to find the authors, bestie 🫶
Dimitri Papadimitriou, Ed.
Alcatel
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 2408491
EMail: dimitri.papadimitriou@alcatel.be
Lyndon Ong
Ciena Corporation
PO Box 308
Cupertino, CA 95015 , USA
Phone: +1 408 705 2978
EMail: lyong@ciena.com
Jonathan Sadler
Tellabs
1415 W. Diehl Rd
Naperville, IL 60563
EMail: jonathan.sadler@tellabs.com
Stephen Shew
Nortel Networks
3500 Carling Ave.
Ottawa, Ontario, CANADA K2H 8E9
Phone: +1 613 7632462
EMail: sdshew@nortel.com
Dave Ward
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134 USA
Phone: +1-408-526-4000
EMail: dward@cisco.comFull Copyright Statement ⚖️
the legal stuff, but make it cute 🎀
Copyright (C) The Internet Society (2006).
this document is covered by the rights, licenses, and restrictions in BCP 78. except where that says otherwise, the authors keep all their rights 📜
this document and the info in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED. that includes, but isn't limited to, any warranty that using the info won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 💅
Intellectual Property 🔐
the IETF is being careful here, and honestly, respect 🫡
the IETF takes no position on whether any Intellectual Property Rights or other rights claimed to cover the implementation or use of this technology are valid or in scope. it also takes no position on whether a license under those rights might be available. it hasn't made any independent effort to find those rights either. info on the procedures for rights in RFC documents is in BCP 78 and BCP 79 📚
copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission to use those proprietary rights for implementers or users of this spec can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🗄️
the IETF invites anyone interested to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology that may be required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📮
Acknowledgement 🌸
funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💖
🦋✨ that's the whole doc, bestie. period 💅
📦 where this page comes from
- ietf: rfc4652 2006-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms