RFC 4258

Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)

📅 published November 2005, from ietf

RFC 4258 (Part 1 of 4) 🌈

Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) 💖

Okay bestie, the header info first 🎀 This one's a Request for Comments: 4258, written by D. Brungard, Ed. from ATT 💅. It's Category: Informational 📚 and it's dated November 2005 🦋. The header doesn't list anything it obsoletes or updates, so no drama there ✨.

Status of This Memo 📄

This memo gives info to the Internet community. It is not a standard of any kind 🙈. Distribution of this memo is unlimited 🌸.

Copyright (C) The Internet Society (2005). 💜

Abstract ✨

Okay so GMPLS is this whole suite of protocols built to control lots of different switching technologies and applications 🔥. It's giving versatility. One of the big things it handles is requesting Time Division Multiplexing (TDM) connections, including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs) 🌈.

This doc zooms in on the routing requirements GMPLS needs so it can support everything an Automatically Switched Optical Network (ASON) can do, as defined by the ITU-T 🧚. Main character energy 👑.

Table of Contents 📋

1. Introduction ....................................................2
2. Conventions Used in This Document ...............................4
3. ASON Routing Architecture and Requirements ......................4
   3.1. Multiple Hierarchical Levels of ASON Routing Areas (RAs) ...5
   3.2. Hierarchical Routing Information Dissemination .............6
   3.3. Configuration ..............................................8
        3.3.1. Configuring the Multi-Level Hierarchy ...............8
        3.3.2. Configuring RC Adjacencies ..........................8
   3.4. Evolution ..................................................8
   3.5. Routing Attributes .........................................8
        3.5.1. Taxonomy of Routing Attributes ......................9
        3.5.2. Commonly Advertised Information .....................9
        3.5.3. Node Attributes ....................................10
        3.5.4. Link Attributes ....................................11
4. Security Considerations ........................................12
5. Conclusions ....................................................12
6. Contributors ...................................................15
7. Acknowledgements ...............................................15
8. References .....................................................16
   8.1. Normative References ......................................16
   8.2. Informative References ....................................16

1. Introduction 🎀

Okay so GMPLS gives you a bunch of capabilities, and one of them is controlling different switching technologies 💖. It can request TDM connections over SONET/SDH (see [T1.105] and [G.707], respectively) and over Optical Transport Networks (OTNs, see [G.709]) 🌸.

BUT there are certain capabilities needed to support the ITU-T G.8080 control plane architecture for an ASON ✨. So it's desirable to figure out what GMPLS needs for this. The ASON control plane architecture is defined in [G.8080] 🦋. ASON routing requirements are in [G.7715], and for ASON link state protocols they're in [G.7715.1] 💅. These Recommendations apply to all [G.805] layer networks (like SDH and OTN), and they give protocol-neutral functional requirements and architecture 🔥.

This doc focuses on the routing requirements for the GMPLS suite so it can do the ASON control plane thing 🧚. It summarizes the ASON requirements using ASON terminology 📚. It does not cover GMPLS applicability or GMPLS capabilities 🙈. Any protocol applicability, design, or suggested extensions (routing included) are totally outside this doc's scope 💀. ASON (Routing) terminology sections live in Appendixes 1 and 2 🌈.

The ASON routing architecture is based on these assumptions 🫶:

  • A network gets subdivided based on operator decision and criteria (like geography, administration, and/or technology). ASON calls these subdivisions Routing Areas (RAs) 🗺️.
  • The routing architecture and protocols used after the network is subdivided are the operator's choice 👑. There's a multi-level hierarchy of RAs, defined in ITU-T [G.7715] and [G.7715.1], giving a hierarchical relationship based on containment. In other words, child RAs are always contained within a parent RA 🪆. That containment is what lets routing info get abstracted, which keeps routing info representation scalable 📈. The maximum number of hierarchical RA levels to support is not specified (outside this doc's scope) 🤷‍♀️.
  • Within an ASON RA, and for each level of the routing hierarchy, multiple routing paradigms (hierarchical, step-by-step, source-based) MAY be supported 💅. Path computation can be centralized or distributed, and multiple different routing protocols MAY be supported too 🔥. The architecture does not assume a one-to-one match between a routing protocol and an RA level 🙅‍♀️. It also lets the routing protocols used in different RAs (child and parent RAs included) be different 🌈. How the routing paradigms get realized to support the hierarchical RA levels is not specified 🧚.
  • The routing adjacency topology (basically the associated Protocol Controller (PC) connectivity) and the transport topology are definitely not assumed to be congruent 💀.
  • The requirements support architectural evolution, like changing the number of RA levels, or aggregating and segmenting RAs 🦋.

The ASON routing architecture gives you a conceptual reference architecture 💖. It defines functional components and common information elements so you get end-to-end routing even with protocol heterogeneity, and so managing ASON networks is easier ✨. This description is only conceptual: no physical partitioning of these functions is implied 🫶.

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]. 🔥

Although [RFC2119] describes how these key words are interpreted for protocol specifications and implementations, this doc uses them to describe design requirements for protocol extensions 🌸.

3. ASON Routing Architecture and Requirements 🧚

The fundamental architectural concept is the RA and its related functional components (see Appendix 2 on terminology) 💜. The routing services an RA offers are provided by a Routing Performer (RP) 🎀. An RP is responsible for a single RA, and it MAY be functionally realized using distributed Routing Controllers (RCs) 🦋. The RC itself MAY be implemented as a cluster of distributed entities (ASON calls that cluster a Routing Control Domain (RCD)) 🌈.

The RC components for an RA receive routing topology information from their associated Link Resource Manager(s) (LRMs), and they store that info in the Routing Information Database (RDB) 📚. The RDB is replicated at each RC bound to the same RA, and it MAY contain information about multiple transport plane network layers 🫶. Whenever the routing topology changes, the LRM tells the corresponding RC, which then updates its associated RDB 💅. To keep RDBs synchronized, the RCs cooperate and exchange routing information 🤝. Path computation functions MAY exist in each RC, MAY exist on selected RCs within the same RA, or MAY be centralized for the RA 👑.

In this context, RCs in the same RA talk to each other using a particular routing protocol (or multiple protocols) 💖. In ASON, the communication piece is represented by the protocol controller (PC) component(s), and the protocol messages get carried over the ASON control plane's Signaling Control Network (SCN) ✨. The PC MAY convey information for one or more transport network layers (check the note in Section 3.2) 🌸. The RC is protocol independent, and RC communications MAY be realized by multiple, different PCs within an RA 🔥.

The ASON routing architecture defines a multi-level routing hierarchy of RAs based on a containment model, to support routing information abstraction 🪆. [G.7715.1] defines the ASON hierarchical link state routing protocol requirements for communicating routing information within an RA (one level), to support hierarchical routing information dissemination (including summarized routing info for other levels) 🦋. Communication between any of the other functional components (like the SCN, the LRM, and between RCDs, which is RC-RC communication between RAs) is outside the scope of [G.7715.1] protocol requirements. So it's also outside the scope of this doc 🙈.

ASON routing components are identified by identifiers drawn from different name spaces (see [G.7715.1]) 🧚. These are control plane identifiers for transport resources, components, and SCN addresses 💜. The formats of those identifiers in a routing protocol realization SHALL be implementation specific and outside the scope of this doc 🎀.

The failure of an RC, or the failure of communications between RCs, and the recovery from that failure condition MUST NOT disrupt calls in progress (meaning already established ones) and their associated connections 🫶. Calls being set up MAY fail to complete, and the call setup service MAY be unavailable during recovery actions 😭.

3.1. Multiple Hierarchical Levels of ASON Routing Areas (RAs) 🌸

okay so [G.8080] brings in the idea of a Routing Area (RA), which is basically a way of slicing a network into pieces 🍰 RAs are all about routing information abstraction, meaning they let you hide the messy details and only show what's needed. Except for the single RA case, RAs nest inside each other like a set of matryoshka dolls 🪆: a higher-level (parent) RA contains lower-level (child) RAs, and those child RAs MAY also contain RAs, and so on. So RAs contain RAs, recursively, building up successive hierarchical levels. it's giving fractal energy 🌀✨

BUT (and this is important bestie) the containment relationship only describes how the RAs are organized on paper, architecturally. It does NOT tell any specific routing protocol how to actually do its thing. Stuff like OSPF multi-areas or path computation is up to the protocol. Also, how the routing paradigm supports the hierarchy, and how many hierarchical levels get supported, depends on the routing protocol and is outside the scope of this document 🙅‍♀️

Now, in a multi-level hierarchy, RCs at the different levels have to be told apart 👀 Before any pair of RCs starts talking, they MUST verify that they are bound to the same parent RA (see Section 3.2). An RA identifier (RA ID) is required to set the scope where RCs can communicate. To tell apart RCs that are bound to the same RA, you need an RC identifier (RC ID), and the RC ID MUST be unique within its containing RA. Main character energy for identifiers 💅

Here's the vibe: an RA represents a partition of the data plane, and its RA ID is used in the control plane as a reference to that data plane partition 🧚 Each RA within a carrier's network SHALL be uniquely identifiable. RA IDs MAY be associated with a transport plane name space, whereas RC IDs are associated with a control plane name space 🦋

3.2. Hierarchical Routing Information Dissemination 💌

Routing information can be exchanged between RCs bound to adjacent levels of the RA hierarchy, meaning Level N+1 and Level N, where Level N represents 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 within an RA MAY be viewed as internal links (intra-RA links). The external links to an RA at one level of the hierarchy may be internal links in the parent RA. Intra-RA links of a child RA MAY be hidden from the parent RA's view 🙈

The physical location of RCs for adjacent RA levels, their relationship, and their communication protocol(s) are outside the scope of this document, so no assumption is made about how RCs talk across adjacent levels 🤷‍♀️ If routing information gets exchanged between an RC, its parent, and its child RCs, it SHOULD include reachability (see Section 3.5.3) and MAY include node and link topology, upon policy decision 🫶 Communication between RAs only takes place between RCs with a parent/child relationship. RCs of one RA never communicate with RCs of another RA at the same level. There SHOULD not be any dependencies on the different routing protocols used within an RA or in different RAs 🌈

Multiple RCs bound to the same RA MAY transform (filter, summarize, etc.) and then forward information to RCs at different levels. However, in this case, the resulting information at the receiving level must be self-consistent. Basically, you have to keep the transform operations performed at different levels consistent with each other so the information gets processed properly 🧠 This MAY be achieved using a number of mechanisms.

Note: There is no implied relationship between multi-layer transport networks and multi-level routing. Implementations MAY support a hierarchical routing topology (multi-level) with a single routing protocol instance for multiple transport switching layers, or a hierarchical routing topology for one transport switching layer. 🦄

1. Type of Information Exchanged 📦

The type of information flowing upward (Level N to Level N+1) and the type flowing downward (Level N+1 to Level N) are used for similar purposes, namely, exchanging reachability information and summarized topology information so routing can happen across multiple RAs. Summarizing topology information may impact the accuracy of routing and may require additional path calculation, so keep that in mind 🤓

The following information exchanges are expected:

  • Level N+1 visibility to Level N reachability and topology (or upward information communication), which allows RC(s) at Level N+1 to determine the reachable endpoints from Level N ⬆️
  • Level N visibility to Level N+1 reachability and topology (or downward information communication), which allows RC(s) bound to an RA at Level N to develop paths to reachable endpoints outside of the RA ⬇️

2. Interactions between Upward and Downward Communication 🔁

When both upward and downward information exchanges contain endpoint reachability information, a feedback loop could potentially be created 😱 Consequently, the routing protocol MUST include a method 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, and
  • 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.

The routing protocol SHALL 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. This is a necessary condition for routing protocols to be loop free, so it's not optional, bestie 🔥

3. Method of Communication 📡

Two approaches exist for communication between Level N and N+1:

  • The first approach places an instance of a Level N routing function and an instance of a Level N+1 routing function in the same system. The communications interface is within a single system and is thus not an open interface subject to standardization. However, information re-advertisement or leaking MUST be performed in a consistent manner to ensure interoperability and basic routing protocol correctness (e.g., cost/metric value). 🧩
  • The second approach places the Level N routing function on a separate system from the Level N+1 routing function. In this case, a communication interface must be used between the systems containing the routing functions for different levels. This communication interface and its mechanisms are outside the scope of this document 🙃

3.3. Configuration ⚙️

3.3.1. Configuring the Multi-Level Hierarchy 🪆

The RC MUST support static (i.e., operator assisted) configuration and MAY support automated configuration of the information describing its relationship to its parent and its child within the hierarchical structure (including RA ID and RC ID). When applied recursively, the whole hierarchy is thus configured. Recursion slaps every time 💖

3.3.2. Configuring RC Adjacencies 🤝

The RC MUST support static (i.e., operator assisted) configuration and MAY support automated configuration of the information describing its associated adjacencies to other RCs within an RA. The routing protocol SHOULD 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. Evolution 🦋

The containment relationships of RAs may change, motivated by events such as mergers, acquisitions, and divestitures. Corporate drama, but make it networking 💼

The routing protocol SHOULD be capable of supporting architectural evolution in terms of the number of hierarchical levels of RAs, as well as the aggregation and segmentation of RAs. RA ID uniqueness within an administrative domain may facilitate these operations. The routing protocol is not expected to automatically initiate and/or execute these operations. Reconfiguring the RA hierarchy may not disrupt calls in progress, though calls being set up may fail to complete, and the call setup service may be unavailable during reconfiguration actions 📞 so it's not a perfect vibe, but it's not a total disaster either 😭

3.5. Routing Attributes 🎀

Routing for transport networks is performed on a per-layer basis, where the routing paradigms MAY differ among layers and within a layer. Not all equipment supports the same set of transport layers or the same degree of connection flexibility at any given layer. A server layer trail may support various clients, involving different adaptation functions. Equipment may also support variable adaptation functionality, whereby a single server layer trail dynamically supports different multiplexing structures. As a result, routing information MAY include layer-specific, layer-independent, and client/server adaptation information. Layers, layers, layers, it's a whole thing 🧁

3.5.1. Taxonomy of Routing Attributes 🏷️

Attributes can be organized according to the following categories:

  • Node related or link related
  • Provisioned, negotiated, or automatically configured
  • Inherited or layer specific (client layers can inherit some attributes from the server layer, while other attributes such as Link Capacity are specified by layer)

(Component) link attributes MAY be statically or automatically configured for each transport network layer. This may lead to unnecessary repetition. Hence, the inheritance property of attributes MAY also be used to optimize the configuration process ✨

ASON uses the term SubNetwork Point (SNP) for the control plane representation of a transport plane resource. The control plane representation and transport plane topology are NOT assumed to be congruent, and the control plane representation SHALL not be restricted by the physical topology. The relational grouping of SNPs for routing is termed an SNP Pool (SNPP). The routing function understands topology in terms of SNPP links. Grouping MAY be based on different link attributes (e.g., SRLG information, link weight, etc). Two-tier naming situation, very dramatic 🎭

Two RAs may be linked by one or more SNPP links. Multiple SNPP links may be required when component links are not equivalent for routing purposes with respect to the RAs to which they are attached, to the containing RA, or when smaller groupings are required 🔗

3.5.2. Commonly Advertised Information 📣

Advertisements MAY contain the following common set of information, regardless of whether they are link or node related:

  • RA ID of the RA to which the advertisement is bounded
  • RC ID of the entity generating the advertisement
  • Information to uniquely identify advertisements
  • Information to determine whether an advertisement has been updated
  • Information to indicate when an advertisement has been derived from a different level RA

3.5.3. Node Attributes ✨

okay so every node belongs to an RA 🏠, which means the RA ID is basically an attribute of every node 💖. Since there's no difference between abstract nodes and ones that can't be broken down any further 🤷‍♀️, the same attributes MAY be used to advertise both. In the tables below, Capability means how much support a link state routing protocol needs to have, and Usage means how much operational control the operator SHOULD have 🎀.

These are the Node Attributes:

      Attribute        Capability      Usage
      -----------      -----------     ---------
      Node ID          REQUIRED        REQUIRED
      Reachability     REQUIRED        OPTIONAL

               Table 1. Node Attributes

Reachability info is the set of endpoints a node can reach 🌸. It MAY be advertised as a set of external address or address prefixes (like the User Network Interface (UNI) ones), or as a set of SNPP link IDs or SNPP ID prefixes 🦋. Whichever one you pick MUST stay consistent within its scope, because mixing them up is a whole mess 💀. These are control plane identifiers, and their formats in a protocol are implementation specific and outside what this doc covers 🙈.

Note: nodes with more internal details (abstract nodes) and nodes that can't be split up are NOT treated differently here. So a node's attributes aren't just for single switches. They MAY also apply to a higher-level node that represents a subnetwork 🧚.

Here are the Link Attributes 🔗:

      Link Attribute                   Capability      Usage
      ---------------                  -----------     ---------
      Local SNPP link ID               REQUIRED        REQUIRED
      Remote SNPP link ID              REQUIRED        REQUIRED
      Layer Specific Characteristics   see Table 3

                        Table 2. Link Attributes

The SNPP link ID MUST be enough to uniquely identify the matching transport plane resource (within the Node ID scope) 🔥. That's because the data plane and control plane are kept separate (see Section 3.5.1), and the control plane view and transport plane topology are NOT assumed to match 💅. The SNPP link ID format depends on the routing protocol.

Note: when the far end of an SNPP link is outside the RA, the remote SNPP link ID is OPTIONAL 🌈.

These are the link characteristic attributes 💜:

  • Signal Type: This tells you the characteristic information of the layer network ✨.
  • Link Weight: This is the metric that shows how desirable one link is compared to another, for example when computing a path 🛣️.
  • Resource Class: This is the set of administrative groups the operator assigns to this link. A link MAY belong to zero, one, or more administrative groups 👑.
  • Local Connection Types: This one says whether the local SNP is a Termination Connection Point (CP), a Connection Point (CP), or can be flexibly set up as a TCP 🧸.
  • Link Capacity: This is the sum of available and potential bandwidth for a given network transport layer 🍓. Other capacity measures MAY also be considered 💖.
  • Link Availability: This shows survivability, like what protection type the link has 🛡️.
  • Diversity Support: This is diversity info, like the SRLG information for the link 🦄.
  • Local Adaptation Support: This shows which client layer adaptations the TCP tied to the local SNPP supports 🎀. It only applies when the local SNP is a TCP or can be flexibly set up as one 🫶.
      Link Characteristics            Capability      Usage
      -----------------------         ----------      ---------
      Signal Type                     REQUIRED        OPTIONAL
      Link Weight                     REQUIRED        OPTIONAL
      Resource Class                  REQUIRED        OPTIONAL
      Local Connection Types          REQUIRED        OPTIONAL
      Link Capacity                   REQUIRED        OPTIONAL
      Link Availability               OPTIONAL        OPTIONAL
      Diversity Support               OPTIONAL        OPTIONAL
      Local Adaptation Support        OPTIONAL        OPTIONAL

                     Table 3. Link Characteristics
Note: sending layer-specific attributes separately MAY be chosen 📨. But that can lead to pointless duplication 😭. You can avoid it with the inheritance property, so attributes you can work out from the local adaptation info don't need to be advertised 🧠. So an optimization MAY be used when several layers are present, by marking which attributes can be inherited from a server layer ✨.

4. Security Considerations ✨

Okay, serious moment, bestie 🚨. The ASON routing protocol MUST deliver the operational security objectives where they're needed 🔐. The big overall security goals (defined in ITU-T Recommendation [M.3016]) are confidentiality, integrity, and accountability 💜. How much each one matters can vary 🤍. These goals don't automatically mean the routing protocol itself has to do the work, since they MAY be met by other established means 🫶.

Note: when you're doing a threat analysis on a proposed routing protocol, it SHOULD cover masquerade, eavesdropping, unauthorized access, loss or corruption of information (including replay attacks), repudiation, forgery, and denial of service attacks 💀🚨. Don't skip any of these, periodt 😤.

5. Conclusions 🎀

So here's the wrap-up 🌷. The ASON routing architecture and its parts are described in terms of routing functions 🧩. This is only a concept, so it doesn't imply any physical split of those functions 🫧.

Here's what the ASON routing architecture assumes 💅:

  • A network gets divided into ASON RAs, which MAY support multiple routing protocols 🌈. No one-to-one relationship SHALL be assumed 🙅‍♀️.
  • Routing Controllers (RCs) handle exchanging routing information (primitives) for the RA 🦋. The RC is protocol independent and MAY be made from multiple, different protocol controllers inside an RA ✨. The routing info swapped between RCs SHALL be subject to policy constraints set at the reference points (External- and Internal-NNI) 🔒.
  • In a multi-level RA hierarchy built on containment, RCs from different RAs only talk when there's a parent/child relationship between those RAs 👑. RCs of child RAs NEVER talk to RCs of other child RAs 🙈. There SHOULD not be any dependencies between the routing protocol used inside a child RA and the one used by its parent 💜. The routing info exchanged inside the parent RA SHALL be independent of both the routing protocol running in a child RA and any control distribution choice (for example, centralized or fully distributed) 🍓.
  • For an RA, the whole set of RCs is called an ASON routing (control) domain 🏰. The routing info exchanged between routing domains (inter-RA, i.e., inter-domain) SHALL be independent of both the intra-domain routing protocol(s) and the intra-domain control distribution choice(s), like centralized or fully distributed 🌸. RCs tied to different RA levels MAY be collocated in the same physical element or physically distributed 🧚.
  • The routing adjacency topology (the PC connectivity topology linked to it) and the transport network topology SHALL NOT be assumed to match 🙃.
  • The routing topology SHALL support multiple links between nodes and RAs 🔗✨.

Next, GMPLS routing is expected to offer the following functionality, so it can set up the ASON hierarchical routing architecture (see [G.7715] and [G.7715.1]) 🤩:

  • RAs SHALL be uniquely identifiable within a carrier's network, each having a unique RA ID within that network 🪪.
  • Within one RA level, the routing protocol SHALL support spreading hierarchical routing info (including summarized routing info for other levels) so the multiple hierarchical RA levels architecture works 📡. How many hierarchical RA levels a routing protocol supports is implementation specific 🧠.
  • The routing protocol SHALL support routing info based on a shared set of information elements defined in [G.7715] and [G.7715.1]. These are split between link attributes and abstract node attributes (each one representing either a subnetwork or just a node) 🧩. [G.7715] notes that the way routing info gets represented and exchanged will change depending on the routing protocol used 🎀.
  • The routing protocol SHALL converge so the distributed RDBs become synchronized after some time ⏳✨.

To support hierarchical routing info spreading within an RA, the routing protocol MUST deliver 💖:

  • Processing of routing info exchanged between adjacent levels of the hierarchy (Level N+1 and N), including reachability and, when policy allows, decision summarized topology info 🌳.
  • Self-consistent info at the receiving level after any transformation (filter, summarize, etc.), plus forwarding of info from one RC to RC(s) at different levels when multiple RCs are tied to one RA 🔁.
  • A mechanism that stops info propagated into the Level N RA's RC from being reintroduced back into the adjacent level RA's RC it originally came from 🚫🔁.

To support operator-assisted changes to the containment relationships between RAs, the routing protocol SHALL support evolution in terms of the number of hierarchical levels of RAs 🦋. Examples include non-disruptive operations like adding and removing RAs at the top or bottom of the hierarchy, adding or removing a hierarchical level of RAs in the middle of it, and aggregation and segmentation of RAs 🌈. The number of hierarchical levels that can be supported is routing protocol specific and reflects a containment relationship. For instance, inserting an RA means supporting a different routing protocol domain in part of the network 🧩.

Reachability info (see Section 3.5.3) for the endpoints a node can reach MAY be advertised either as a set of UNI Transport Resource addresses or address prefixes, or as a set of associated SNPP link IDs or SNPP link ID prefixes. These are assigned and selected consistently within their applicability scope 🎀. The formats of the control plane identifiers in a protocol are implementation specific 💜. Using a routing protocol within one RA should not restrict which routing protocols can be used in other RAs (child or parent) 🫶.

Since ASON doesn't restrict which control plane architecture you choose, either a collocated architecture or a physically separated architecture may be used 🏗️. A collection of links and nodes, like a subnetwork 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 👑✨. Iconic, honestly 🥹💖.

6. Contributors ✨

This one's a team shoutout 🫶 This document came out of the CCAMP Working Group's ASON Routing Requirements design team, and these are the design team members who wrote it with each other:

  • Wesam Alanqar (Sprint)
  • Deborah Brungard (ATT)
  • David Meyer (Cisco Systems)
  • Lyndon Ong (Ciena)
  • Dimitri Papadimitriou (Alcatel)
  • Jonathan Sadler (Tellabs)
  • Stephen Shew (Nortel)

7. Acknowledgements 💜

The authors wanna thank Kireeti Kompella, who kicked off the whole idea of an ASON Routing Requirement Design Team 👑. They also thank ITU-T SG15/Q14 for reviewing everything so carefully and giving input.

8. References 📚

8.1. Normative References

These are the must-read ones 🌸

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2. Informative References

For info on where to find the following documents, check out http://www.itu.int 🦋

[G.707]    ITU-T Rec. G.707/Y.1322, "Network Node Interface for the
           Synchronous Digital Hierarchy (SDH)", December 2003.

[G.709]    ITU-T Rec. G.709/Y.1331, "Interfaces for the Optical
           Transport Network (OTN)", March 2003.

[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.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 (ASON)", November
           2001 (and Revision, January 2003).

[M.3016]   ITU-T Rec. M.3016.0, "Security for the Management Plane:
           Overview", May 2005.

[T1.105]   ANSI T1.105, "Synchronous Optical Network (SONET) - Basic
           Description including Multiplex Structure, Rates, and
           Formats", 2001.

Appendix 1: ASON Terminology 🧚

Here's the vocab this document uses 💅

Administrative domain (see Recommendation [G.805]): For [G.7715.1]'s purposes, an administrative domain is all the resources that belong to one player, like a network operator, a service provider, or an end-user 🏠. Admin domains of different players don't overlap with each other.

Adaptation function (see Recommendation [G.805]): A "transport processing function" that handles client layer info so it can travel over a server layer trail 🚂.

Client/Server relationship: The link between layer networks that an "adaptation" function sets up, so a link connection in the client layer network gets carried by a trail in the server layer network 🎀.

Control plane: This is the call control and connection control crew 📞. Through signaling, it sets up and releases connections, and it can restore a connection if something fails.

(Control) Domain: A group of control entities bundled together for some purpose 🍓. The control plane gets split into domains that match the administrative domains, and inside each admin domain, the splitting keeps going recursively. A routing control domain is an abstract entity that hides the details of how RCs are distributed ✨.

External NNI (E-NNI): The interfaces between protocol controllers that sit between control domains 🌉.

Internal NNI (I-NNI): The interfaces between protocol controllers that sit inside a single 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: The management crew 📋. It handles management functions for the transport plane, the control plane, and the system as a whole, and it coordinates between all the planes. Its functional areas are performance, fault, configuration, accounting, and security management.

Management domain (see Recommendation [G.805]): A collection of managed objects grouped to meet organizational needs by geography, technology, policy, or some other structure 🗂️. It covers functional areas like configuration, security, and (FCAPS), so control stays consistent. Management domains can be disjoint, contained, or overlapping, so resources inside one admin domain can be spread across several overlapping management domains. One resource can be in several management domains at once, but a management domain shall not cross the border of an administrative domain 🚧.

Multiplexing (see Recommendation [G.805]): Techniques that combine client layer signals 🧵. The many-to-one case is when several link connections from client layer networks are all supported by one server layer trail at the same time.

Subnetwork Point (SNP): A control plane abstraction that stands for 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 group of SNPs bundled together for routing purposes 🫧.

Termination Connection Point (TCP): A TCP is the output of a Trail Termination function, or the input to a Trail Termination Sink function 🔌.

Trail (see Recommendation [G.805]): A "transport entity" made of a matched pair of "unidirectional trails" that can send info in opposite directions at the same time 🔁.

Transport plane: Handles bi-directional or unidirectional transfer of user info from one place to another 📦. It can also carry some control and network management info. It's layered, and it's equivalent to the Transport Network defined in the [G.805] Recommendation 🌈.

User Network Interface (UNI): The interfaces between protocol controllers that sit between a user and a control domain 🙋. Note: there is no routing function associated with a UNI reference point. 🙈

Variable adaptation function: One server layer trail can switch between different multiplexing structures on the fly, meaning link connections for several client layer networks 🦎.

Appendix 2: ASON Routing Terminology 🦋

Now for the routing-specific terms 🌸

Routing Area (RA): An RA is a partition of the data plane, and its identifier is how the control plane represents that partition 🗺️. Per [G.8080], an RA is defined by a set of subnetworks, the links that connect them, and the interfaces at the ends of the links leaving that RA. An RA can contain smaller RAs connected by links. At the very bottom of the subdivision, you get an RA with just two subnetworks connected by a single link 💅.

Routing Database (RDB): The repository for local topology, network topology, reachability, and other routing info 🗃️. It's updated as part of the routing info exchange, and it can also hold configured info. One 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 (the Link Resource Manager or LRM, and the Routing Controller or RC) and protocol specific ones (the Protocol Controller or PC).

Routing Controller (RC): Handles the abstract info needed for routing, and does the routing info exchange with peering RCs by working on the RDB 🧠. The RC gets to look at a view of the RDB, and it's protocol independent.

Note: Since the RDB may hold routing info for several RAs (and possibly several layer networks), the RCs that access the RDB may share routing info 🤝.

Link Resource Manager (LRM): Gives the RC all the relevant component and Traffic Engineering (TE) link info 📊. It tells the RC whenever the state of any link resource it controls changes.

Protocol Controller (PC): Handles protocol-specific message exchanges based on the reference point the info is passing over (like E-NNI or I-NNI), plus internal exchanges with the RC 🛠️. The PC is protocol dependent.

Authors' Addresses 📮

Wesam Alanqar
Sprint

EMail: wesam.alanqar@mail.sprint.com


Deborah Brungard, Ed.
AT&T
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA

Phone: +1 732 4201573
EMail: dbrungard@att.com


David Meyer
Cisco Systems

EMail: dmm@1-4-5.net


Lyndon Ong
Ciena Corporation
5965 Silver Creek Valley Rd,
San Jose, CA 95128, USA

Phone: +1 408 8347894
EMail: lyong@ciena.com


Dimitri Papadimitriou
Alcatel
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium

Phone: +32 3 2408491
EMail: dimitri.papadimitriou@alcatel.be


Jonathan Sadler
1415 W. Diehl Rd
Naperville, IL 60563

EMail: jonathan.sadler@tellabs.com
Stephen Shew
Nortel Networks
PO Box 3511 Station C
Ottawa, Ontario, CANADA K1Y 4H7

Phone: +1 613 7632462
EMail: sdshew@nortelnetworks.com

Legal stuff, but it matters 💜 The Internet Society owns the copyright here, dated 2005 🌈. The document is subject to the rights, licenses, and restrictions in BCP 78, and except as BCP 78 says otherwise, the authors keep all their rights.

The document and the info in it come "AS IS", and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all say they disclaim the following:

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,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔐

The IETF takes no position on whether any Intellectual Property Rights or other rights claimed to cover the tech in this document are valid or in scope 🤷‍♀️. It also doesn't say whether licenses for those rights are available, and it hasn't independently tried to find any such rights. For how rights work with RFC documents, see BCP 78 and BCP 79.

You can get copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of any attempt to get a general license or permission to use those proprietary rights, from the IETF's online IPR repository at http://www.ietf.org/ipr 📂.

The IETF invites anyone interested to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society 💖✨

📦 where this page comes from