RFC 4397
A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture
RFC 4397: A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture 🦋
Okay bestie, let's get the header tea first ☕. This is RFC 4397 from the Network Working Group, and it's Informational, which means it's giving "here's some info" energy, not "you must do this" energy 💅. It was written by I. Bryskin (Independent Consultant) and A. Farrel (Old Dog Consulting), and it's dated February 2006 🎀. The header doesn't list any Obsoletes or Updates entries, so it isn't replacing or changing any other RFC.
Status of This Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 🌸
Copyright (C) The Internet Society (2006).
Abstract 🔥
Generalized Multiprotocol Label Switching (GMPLS) was developed by the IETF to make it easier to set up Label Switched Paths (LSPs) in a bunch of different data plane technologies and across several architectural models. The ITU-T has specified an architecture for controlling Automatically Switched Optical Networks (ASON).
This document gives you a lexicography for interpreting GMPLS terminology within the context of the ASON architecture 📖.
It's important to note that GMPLS works in a wider set of contexts than just ASON. The definitions in this document don't give exclusive or complete interpretations of GMPLS concepts. This document simply lets GMPLS terms be used within the ASON context 💜.
Table of Contents 🧚
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. GMPLS Terminology Sources ..................................3
2.2. ASON Terminology Sources ...................................4
2.3. Common Terminology Sources .................................4
3. Lexicography ....................................................4
3.1. Network Presences ..........................................4
3.2. Resources ..................................................5
3.3. Layers .....................................................6
3.4. Labels .....................................................7
3.5. Data Links .................................................7
3.6. Link Interfaces ............................................8
3.7. Connections ................................................9
3.8. Switching, Termination, and Adaptation Capabilities .......10
3.9. TE Links and FAs ..........................................11
3.10. TE Domains ...............................................13
3.11. Component Links and Bundles ..............................13
3.12. Regions ..................................................14
4. Guidance on the Application of this Lexicography ...............14
5. Management Considerations ......................................15
6. Security Considerations ........................................15
7. Acknowledgements ...............................................15
8. Normative References ...........................................16
9. Informative References .........................................161. Introduction ✨
GMPLS was built by the IETF to help set up Label Switched Paths (LSPs) across a variety of data plane technologies, such as Packet Switching Capable (PSC), Layer Two Switching Capable (L2SC), Time Division Multiplexing (TDM), Lambda Switching Capable (LSC), and Fiber Switching Capable (FSC) 🌈.
The ITU-T has specified an architecture for controlling Automatically Switched Optical Networks (ASON). This architecture is the foundation for many ITU-T Recommendations 💅.
Here's the tea: GMPLS and ASON were designed by different people in different standards bodies, and they come from very different histories (the Internet and transport networks, respectively). So the terminology is different 🙈.
This document gives you a lexicography for interpreting GMPLS terminology within the context of the ASON architecture. This lets people who already know the ASON Recommendations generally understand GMPLS documents 🦋. The definitions here don't give exclusive or complete interpretations of GMPLS concepts.
2. Terminology 🎀
Throughout this document, angle brackets (< and >) show the context a term applies in. For example, <Data Plane> in the description of a term means that the term applies within the data plane 🫶.
2.1. GMPLS Terminology Sources
GMPLS terminology is mainly defined in [RFC3945]. Other documents with key definitions include [RFC4201], [RFC4202], [RFC4204], and [RFC4206] 📚.
Before you try to use this document to make a broader mapping between GMPLS and ASON, I'd really recommend getting familiar with these other documents first 🧠.
For details on GMPLS signaling, check out [RFC3471] and [RFC3473]. For details on GMPLS routing, check out [RFC4203] and [RFC4205] 💖.
2.2. ASON Terminology Sources
The ASON architecture is specified in ITU-T Recommendation G.8080 [G-8080]. It was developed from the generic functional architectures and requirements specified in [G-805], [G-807], and [G-872]. The ASON terminology is defined across several Recommendations in the ASON family, such as [G-8080], [G-8081], [G-7713], [G-7714], and [G-7715] ✨.
You absolutely have to be familiar with these documents before you apply the lexicography in this document, no cap 👑.
2.3. Common Terminology Sources
This work builds on the shared view of ASON requirements, plus the requirements expressed in [RFC4139], [RFC4258], and [RFC4394] 🌸.
3. Lexicography 🧚
3.1. Network Presences
3.1.1. GMPLS Terms
Transport node <Data Plane> is a logical network device that can originate and/or terminate a data flow, and/or switch it on the route to its destination 🍓.
Controller <Control Plane> is a logical entity that models all the control plane intelligence (routing, traffic engineering (TE), and signaling protocols, path computation, etc.). A single controller can manage one or more transport nodes. Separate functions (such as routing and signaling) may be hosted at distinct sites, and so could be considered separate logical entities, referred to for example as the routing controller, the signaling controller, etc. 🧠
Label Switching Router (LSR) <Control & Data Planes> is a logical combination of a transport node and the controller that manages that transport node. Many LSR implementations collocate all the control plane and data plane functions associated with a transport node in one physical presence, which makes the term LSR concrete rather than logical 💅.
In some cases, the term LSR may be applied more loosely to mean just the transport node or just the controller function, depending on the context 🦋.
Node <Control & Data Planes> is a synonym for an LSR 💜.
Control plane network <Control Plane> is an IP network used to deliver control plane (protocol) messages exchanged by controllers 🌈.
3.1.2. ASON Terms
A GMPLS transport node is an ASON network element 🎀.
A GMPLS controller is the set of ASON functional components that controls a given ASON network element (or partition of a network element). In ASON, this set of functional components may exist in one place or in multiple places 🫶.
A GMPLS node is the combination of an ASON network element (or partition of a network element) and its associated control components ✨.
The GMPLS control plane network is the ASON Signaling Communication Network (SCN). Note that both routing and signaling exchanges are carried by the SCN 📡.
3.2. Resources
3.2.1. GMPLS Terms
Non-packet-based resource <Data Plane> is a channel of a certain bandwidth that can be allocated in a network data plane of a particular technology for the purpose of delivering user traffic. Examples of non-packet-based resources are timeslots, lambda channels, etc. ⭐
Packet-based resource <Data Plane> is an abstraction that hides the means for delivering traffic with particular parameters (most importantly, bandwidth) and a particular quality of service (QoS) over PSC media. Examples of packet-based resources are forwarding queues, schedulers, etc. 💅
Layer Resource (Resource) <Data Plane>. A non-packet-based data plane technology may yield resources in different network layers (see section 3.3). For example, some TDM devices can operate with VC-12 timeslots, some with VC-4 timeslots, and some with VC4-4c timeslots. There are also multiple layers of packet-based resources (i.e., one per label in the label stack). Therefore, we define layer resource (or simply resource) irrespective of the underlying data plane technology as a basic data plane construct 🧩. It's defined by a combination of a particular data encoding type and a switching/terminating bandwidth granularity. Examples of layer resources are: PSC1, PSC4, ATM VP, ATM VC, Ethernet, VC-12, VC-4, Lambda 10G, and Lambda 40G 🌸.
These three definitions give rise to the concept of Resource Type. It isn't a formal term, but it's really useful shorthand for figuring out how and where a resource can be used, depending on the switching type, data encoding type, and switching/terminating bandwidth granularity (see section 3.8) 🔥.
All other descriptions in this memo are tightly bound to the resource 💖.
3.2.2. ASON Terms
ASON terms for resource:
- In the context of link discovery and resource management (allocation, binding into cross-connects, etc.), a GMPLS resource is one end of a link connection.
- In the context of routing, path computation, and signaling, a GMPLS resource is a link connection or trail termination.
A resource type is identified by a client CI (Characteristics Information) that could be carried by the resource 🦋.
3.3. Layers
3.3.1. GMPLS Terms
Layer <Data Plane> is a set of resources of the same type that could be used for establishing a connection or for connectionless data delivery 🌈.
Note. In GMPLS, the existence of a non-blocking switching function in a transport node in a particular layer is modeled explicitly as one of the functions of the link interfaces connecting the transport node to its data links.
A GMPLS layer is not the same as a GMPLS region. See section 3.12 🙈.
3.3.2. ASON Terms
A GMPLS layer is an ASON layer network ✨.
3.4. Labels
3.4.1. GMPLS Terms
Label <Control Plane> is an abstraction that provides an identifier for use in the control plane, in order to identify a transport plane resource 🏷️.
3.4.2. ASON Terms
A GMPLS label is the portion of an ASON SNP name that follows the SNPP name 💜.
3.5. Data Links
Ok bestie, that's all for part 1! Part 2 is coming up next with 3.5 and everything after it, so stay tuned 🎀💖
3.5.1. GMPLS Terms ✨
okay bestie, let's talk data links 🦋
Unidirectional data link end <Data Plane> is a set of resources that belong to the same layer and that could be allocated for the transfer of traffic in that layer from a particular transport node to the same neighboring transport node in the same direction. A unidirectional data link end is connected to a transport node by one or more link interfaces (see section 3.6). 💅
Bidirectional data link end <Data Plane> is an association of two unidirectional data link ends that exist in the same layer and that could be used for the transfer of traffic in that layer between a particular transport node and the same neighbor in both directions. A bidirectional data link end is connected to a transport node by one or more link interfaces (see section 3.6). 🌸
Unidirectional data link <Data Plane> is an association of two unidirectional data link ends that exist in the same layer, that are connected to two transport nodes adjacent in that layer, and that could be used for the transfer of traffic between the two transport nodes in one direction. 🎀
Bidirectional data link <Data Plane> is an association of two bidirectional data link ends that exist in the same layer, that are connected to two transport nodes adjacent in that layer, and that could be used for the transfer of traffic between the two transport nodes in both directions. 👑
3.5.2. ASON Terms
ok so the ASON version is a little different 🧚
A GMPLS unidirectional data link end is a collection of connection points from the same client layer that are supported by a single trail termination (access point).
A GMPLS data link is an ASON link supported by a single server trail. 💜
3.6. Link Interfaces ✨
3.6.1. GMPLS Terms
Unidirectional link interface <Data Plane> is an abstraction that connects a transport node to a unidirectional data link end and represents (hides) the data plane intelligence like switching, termination, and adaptation in one direction. In GMPLS, link interfaces are often referred to as "GMPLS interfaces," and it should be understood that these are data plane interfaces and the term does not refer to the ability of a control plane interface to handle GMPLS protocols. no cap, this part is easy to mix up 🙈
A single unidirectional data link end could be connected to a transport node by multiple link interfaces, with one of them, for example, realizing switching function, while others realize the function of termination/adaptation. 🍓
Bidirectional link interface <Data Plane> is an association of two or more unidirectional link interfaces that connects a transport node to a bidirectional data link end and represents the data plane intelligence like switching, termination, and adaptation in both directions. 🫶
Link interface type <Data Plane> is identified by the function the interface provides. There are three distinct functions: switching, termination, and adaptation. Hence, there are three types of link interface. Thus, when a Wavelength Division Multiplexing (WDM) link can do switching for some lambda channels, and termination and TDM OC48 adaptation for some other lambda channels, we say that the link is connected to the transport node by three interfaces, each of a separate type: switching, termination, and adaptation. 🌈
3.6.2. ASON Terms
A GMPLS interface is the set of trail termination and adaptation functions between one or more server layer trails and a specific client layer subnetwork (which commonly is a matrix in a network element). ✨
The GMPLS interface type may be identified by the ASON adapted client layer, or by the terminated server layer, or a combination of the two, depending on the context. In some cases, a GMPLS interface comprises a set of ASON trail termination/adaptation functions, for which some connection points are bound to trail terminations and others to matrices. 💖
3.7. Connections 🦋
3.7.1. GMPLS Terms
In GMPLS, a connection is known as a Label Switched Path (LSP). 🎀
Unidirectional LSP (connection) <Data Plane> is a single resource or a set of cross-connected resources of a particular layer that could deliver traffic in that layer between a pair of transport nodes in one direction. 🌸
Unidirectional LSP (connection) <Control Plane> is the signaling state necessary to maintain a unidirectional data plane LSP. 💅
Bidirectional LSP (connection) <Data Plane> is an association of two unidirectional LSPs (connections) that could simultaneously deliver traffic in a particular layer between a pair of transport nodes in opposite directions.
In the context of GMPLS, both unidirectional constituents of a bidirectional LSP (connection) take identical paths in terms of data links, are provisioned concurrently, and require a single (shared) control state. 👑
Bidirectional LSP (connection) <Control Plane> is the signaling state necessary to maintain a bidirectional data plane LSP. 🌈
LSP (connection) segment <Data Plane> is a single resource or a set of cross-connected resources that constitutes a segment of an LSP (connection). 🧚
3.7.2. ASON Terms
A GMPLS LSP (connection) is an ASON network connection. 💜
A GMPLS LSP segment is an ASON serial compound link connection. ⭐
3.8. Switching, Termination, and Adaptation Capabilities 🫶
3.8.1. GMPLS Terms
Switching capability <Data Plane> is a property (and defines a type) of a link interface that connects a particular data link to a transport node. This property/type characterizes the interface's ability to cooperate with other link interfaces connecting data links within the same layer to the same transport node for the purpose of binding resources into cross-connects. Switching capability is advertised as an attribute of the TE link local end associated with the link interface. 🔥
Termination capability <Data Plane> is a property of a link interface that connects a particular data link to a transport node. This property characterizes the interface's ability to terminate connections within the layer that the data link belongs to. 🍓
Adaptation capability <Data Plane> is a property of a link interface that connects a particular data link to a transport node. This property characterizes the interface's ability to perform a nesting function, meaning to use a locally terminated connection that belongs to one layer as a data link for some other layer. 🙈
The need for advertisement of adaptation and termination capabilities within GMPLS has been recognized, and work is in progress to determine how these will be advertised. It is likely that they will be advertised as a single combined attribute, or as separate attributes of the TE link local end associated with the link interface. ✨
3.8.2. ASON Terms
In ASON applications:
The GMPLS switching capability is a property of an ASON link end representing its association with a matrix. 💖
The GMPLS termination capability is a property of an ASON link end representing potential binding to a termination point. 🎀
The GMPLS adaptation capability is a property of an ASON link end representing potential adaptation to/from a client layer network. 🌸
3.9. TE Links and FAs 🦋
3.9.1 GMPLS Terms
TE link end <Control Plane> okay so this is a grouping that's all about advertising and routing the resources of one particular layer 💅. The big payoff is that it lets you decouple path selection from resource assignment 🧚. You can pick a path centrally in terms of TE link ends, and then do the resource assignment (resource reservation and label allocation) in a distributed way during connection setup 🫶. A TE link end might reflect zero, one or more data link ends in the data plane, and it's associated with exactly one layer. Very clean, no notes 🎀.
TE link <Control Plane> is a grouping of two TE link ends that belong to two neighboring transport nodes in a particular layer 🦋. Now here's the twist: a data link gives you real network flexibility in a particular layer, so it's a "real" topological element 🌸. A TE link is a logical routing element, though 😭. For example, an LSP path gets computed in terms of TE links (or really, TE link ends), but the LSP is actually provisioned over, meaning resources are allocated from, data links 💜.
A Virtual TE link is a TE link associated with zero data links 🌈.
TE link end advertising <Control Plane>. A controller that manages a particular transport node advertises its local TE link ends 📡. Any controller in the TE domain can make a TE link available for its own local path computation, but only if it gets consistent advertisements for both TE link ends ✨. Strictly speaking, there's no such thing as TE link advertising, just TE link end advertising 🙈. A TE link end advertisement may contain info about multiple switching capabilities. This does not mean a multi-layer TE link end, though. It's really a joint advertisement of the ends of multiple parallel TE links, each representing resources in a separate layer 🔥. The advertisement can carry attributes shared by all the TE links in the group (like protection capabilities, Shared Risk Link Groups (SRLGs), etc.) 💖. It can also carry separate info for each TE link (like switching capability, data encoding, unreserved bandwidth, etc.) ⭐. And it can include info about inter-layer relationships of the advertised resources (like termination and adaptation capabilities), in case the control plane decides to use them as termination points of higher-layer data links 🧚. Those higher-layer data links aren't real yet, though. They stay abstract until the underlying connections are set up in the lower layers 😭.
LSPs that get created in lower layers to provide data links (extra network flexibility) in higher layers are called hierarchical connections or LSPs (H-LSPs), or just hierarchies 🌳. LSPs created to provide data links in the same layer are called stitching segments 🧵. H-LSPs and stitching segments could, but don't have to, be advertised as TE links 🎀. If they are advertised as TE links (LSPs advertised as TE links are often called TE-LSPs), they become available for path computations on any controller inside the TE domain they were advertised into 👑. H-LSPs and stitching segments can be advertised individually or in TE bundles 💅. And an H-LSP or stitching segment can be advertised as a TE link into the same TE domain it was provisioned in, or into a separate one 🦋.
A set of H-LSPs that is created (or could be created) in a particular layer to provide network flexibility (data links) in other layers is called a Virtual Network Topology (VNT) 🌸. One single H-LSP can provide several data links, each in a different layer 🍓.
Forwarding Adjacency (FA) <Control Plane> is a TE link that doesn't need a direct routing adjacency (peering) between the controllers managing its ends in order to guarantee control plane connectivity (a control channel) between them 💜. An FA example is an H-LSP or stitching segment advertised as a TE link into the same TE domain where it was dynamically provisioned 🫶. In that case, control plane connectivity between the controllers at the ends of the H-LSP or stitching segment is guaranteed by concatenating the control channels that interconnect the ends of each of its constituents 🧚. Contrast that with an H-LSP or stitching segment advertised as a TE link into a TE domain that's different from the one where it was provisioned 🙈. That one generally needs a direct routing adjacency set up within the TE domain where the TE link is advertised, so that control plane connectivity between the TE link ends is guaranteed 😭. Therefore, is not an FA 💀.
3.9.2 ASON Terms
The ITU term for a TE link end is Subnetwork Point (SNP) pool (SNPP) 🌈.
The ITU term for a TE link is SNPP link ✨.
The ITU term for an H-LSP is trail 🦋.
3.10. TE Domains
3.10.1 GMPLS Terms
TE link attribute is a parameter of the set of resources associated with a TE link end that matters in the context of path computation 💅.
Full TE visibility is a situation where a controller receives all unmodified TE advertisements from every other controller in a particular set of controllers 👀.
Limited TE visibility is a situation where a controller receives summarized TE information, or doesn't receive TE advertisements from at least one controller in a particular set of controllers 🙈.
A TE domain is a set of controllers where each one has full TE visibility within that set 👑.
The TE database (TED) is a memory structure inside a controller that holds all TE advertisements generated by all controllers within a particular TE domain 🗂️.
Vertical network integration is a set of control plane mechanisms and coordinated data plane mechanisms that span multiple layers 🌸. The control plane mechanisms live on one or more controllers and operate either within a single control plane instance or between control plane instances 🧚. The data plane mechanisms consist of collaboration and adaptation between layers within a single transport node 🔥.
Horizontal network integration is a set of control plane mechanisms and coordinated data plane mechanisms that span multiple TE domains within the same layer 🌈. The control plane mechanisms live on one or more controllers and operate either within a single control plane instance or between control plane instances 🫶. The data plane mechanisms consist of collaboration between TE domains 💖.
3.11. Component Links and Bundles
3.11.1 GMPLS Terms
Component link end <Control Plane> is a grouping of resources of a particular layer that isn't advertised as an individual TE link end 🎀. A component link end can represent one or more data link ends, or any subset of resources that belong to one or more data link ends 💜.
Component link <Control Plane> is a grouping of two or more component link ends associated with neighboring transport nodes (meaning directly interconnected by one or more data links) in a particular layer 🦋. Component links are equivalent to TE links, except that their component link ends aren't advertised separately ✨.
TE bundle <Control Plane> is an association of several parallel component links (meaning they connect the same pair of transport nodes) whose attributes are identical, or whose differences are negligible enough that the TE domain can view the whole association as a single TE link 🍓. A TE bundle gets advertised the same way a TE link does: the associated component link ends are represented as a single TE link end, called a TE bundle end, and that's what gets advertised 📡.
3.12. Regions
3.12.1 GMPLS Terms
TE region <Control Plane> is a set of one or more layers associated with the same type of data plane technology 🌈. A TE region is sometimes called an LSP region, or just a region 🌸. Examples of regions include IP, ATM, TDM, photonic, fiber switching, etc. 🧚 Regions and region boundaries matter a lot to the signaling sub-system of the control plane, because LSPs get signaled quite differently (meaning they use different signaling object formats and semantics) in different regions 🔥. Advertising, routing, and path computation can also be done differently in different regions 💅. For example, computing paths across photonic regions needs a wider set of constraints (e.g., optical impairments, wavelength continuity, etc.) and has to be done in different terms (e.g., in terms of individual resources, like lambda channels, rather than in terms of TE links) compared to path computation in regions like IP or TDM 🌟.
4. Guidance on the Application of this Lexicography ✨
As discussed in the introduction to this document, this lexicography is meant to bring the concepts and terms associated with GMPLS into the context of the ITU-T's ASON architecture 🦋. So it should help people who know ASON see how they can use GMPLS features and functions to meet the requirements of an ASON 💖. For example, service providers who want to set up a protected end-to-end service might read [SEG-PROT] and [E2E-PROT], and want to understand how the GMPLS terms used relate to the ASON architecture 🧐. That way they can confirm that they'll satisfy their requirements 💅.
This lexicography should NOT be used to obtain or derive definitive definitions of GMPLS terms 🚫. For definitions that apply across all GMPLS architectural models, go to the RFCs listed in the references sections of this document 📚. [RFC3945] gives an overview of the GMPLS architecture and should be read first 🎀.
5. Management Considerations ⚙️
Both GMPLS and ASON networks need management 🛠️. Both GMPLS and ASON specifications put a lot of effort into operator control and monitoring, as well as Operations and Management (OAM) functionality 💜.
These concepts are, however, out of scope for this document 🙈.
6. Security Considerations 🔐
Security is also a significant requirement of both GMPLS and ASON architectures 🚨.
Again, though, this informational document is only meant to provide a lexicography, so the security concerns are out of scope here 💀. Please don't skip over this one, bestie, because security is a big deal for both architectures 😭.
7. Acknowledgements 🫶
The authors would like to thank participants in the IETF's CCAMP working group and the ITU-T's Study Group 15 for their help in producing this document 🌈. Special shoutout to everyone who attended the Study Group 15 Question 14 Interim Meeting in Holmdel, New Jersey during January 2005 👑. Further thanks to all participants of Study Group 15 Questions 12 and 14 who shared valuable discussion, feedback and suggested text 💖.
Many thanks to Ichiro Inoue for his useful review and input, and to Scott Brim and Dimitri Papadimitriou for lengthy and constructive discussions 🧚. Ben Mack-Crane and Jonathan Sadler provided very helpful reviews and discussions of ASON terms 🦋. Thanks to Deborah Brungard and Kohei Shiomoto for additional review comments 🌸.
8. Normative References ✨
okay so these are the docs you need to have read before this one makes any sense, bestie 📚 they're the load-bearing beams 💅
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October
2004.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link
Bundling in MPLS Traffic Engineering (TE)", RFC
4201, October 2005.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol
Label Switching (GMPLS) Traffic Engineering (TE)",
RFC 4206, October 2005.9. Informative References 🦋
these ones are the extra reading 🤓 good for context, deep dives, and when you're feeling extra. the ITU stuff lives somewhere else, so I've kept that pointer too 🌸
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A.,
and L. Ong, "Requirements for Generalized MPLS
(GMPLS) Signaling Usage and Extensions for
Automatically Switched Optical Network (ASON)", RFC
4139, July 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., Ed., "Requirements for Generalized
Multi-Protocol Label Switching (GMPLS) Routing for
the Automatically Switched Optical Network (ASON)",
RFC 4258, November 2005.
[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.
[E2E-PROT] Lang, J., Ed., Rekhter, Y., Ed., and D.
Papadimitriou, D., Ed., "RSVP-TE Extensions in
support of End-to-End Generalized Multi-Protocol
Label Switching (GMPLS)-based Recovery", Work in
Progress, April 2005.
[SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Farrel, "GMPLS Based Segment Recovery", Work in
Progress, May 2005.For information on the availability of the following documents, check out http://www.itu.int 🌍
[G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for
the automatically switched optical network (ASON).
[G-805] ITU-T Recommendation G.805 (2000), Generic
functional architecture of transport networks.
[G-807] ITU-T Recommendation G.807/Y.1302 (2001),
Requirements for the automatic switched transport
network (ASTN).
[G-872] ITU-T Recommendation G.872 (2001), Architecture of
optical transport networks.
[G-8081] ITU-T Recommendation G.8081 (2004), Terms and
definitions for Automatically Switched Optical
Networks (ASON).
[G-7713] ITU-T Recommendation G.7713 (2001), Distributed Call
and Connection Management.
[G-7714] ITU-T Recommendation G.7714 Revision (2005),
Generalized automatic discovery techniques.
[G-7715] ITU-T Recommendation G.7715 (2002), Architecture and
Requirements for the Automatically Switched Optical
Network (ASON).Authors' Addresses 💌
meet the people behind the doc 🫶
Igor Bryskin
Independent Consultant
EMail: i_bryskin@yahoo.com
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.ukFull Copyright Statement ⚖️
the legal bit, so I'm keeping it word-for-word 🙈 no edits, no vibes, just the facts
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein 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,
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 💜
this part is all about who owns what 👑 the IETF doesn't take a side on patents or licensing for the tech in here. if you want to see IPR disclosures or ask for licenses, the IETF keeps a repository at http://www.ietf.org/ipr. and if you spot a patent or something that might be needed to build this, tell the IETF at ietf-ipr@ietf.org. the rules for rights in RFC docs live in BCP 78 and BCP 79 📖
Acknowledgement 🌷
shoutout to the IETF Administrative Support Activity (IASA) 🎀 they're the reason the RFC Editor function gets funded, so the docs keep coming out 💖
📦 where this page comes from
- ietf: rfc4397 2006-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms