RFC 4394
A Transport Network View of the Link Management Protocol (LMP)
RFC 4394: A Transport Network View of the Link Management Protocol (LMP) 🦋
Okay bestie, this one is a whole vibe. It's an Informational RFC from February 2006, written by D. Fedyk and O. Aboul-Magd (both Nortel Networks), D. Brungard (AT&T), J. Lang (Sonos, Inc.), and D. Papadimitriou (Alcatel). The title is "A Transport Network View of the Link Management Protocol (LMP)." It doesn't obsolete or update anything, since the header doesn't list either. 🎀
Also, the header is totally clear about what this is: it gives information to the Internet community and does not set any Internet standard. Anyone can distribute it freely. 💅
Status of This Memo 📜
So this memo is just here to share info with the Internet community. It's not a standard, not even a little bit, and it can be passed around with zero restrictions. 🌸
Copyright Notice ©️
Copyright (C) The Internet Society (2006). ✨
Abstract 🧚
Okay so the Link Management Protocol (LMP) was built as part of the Generalized MPLS (GMPLS) protocol suite 🔥. Its job is managing Traffic Engineering (TE) resources and links. The GMPLS control plane, which covers routing and signaling, uses TE links to set up Label Switched Paths (LSPs).
This memo explains how LMP's procedures connect to 'discovery' as defined by the International Telecommunication Union (ITU-T), plus the ITU-T work that's still in progress. It gives a big-picture view of LMP in the context of ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology. It also matches LMP up with the ITU-T discovery work so that the IETF and ITU-T can get on the same page while they keep building. 🫶
Table of Contents 🗂️
1. Introduction ....................................................2
2. ASON Terminology and Abbreviations Related to Discovery .........3
2.1. Terminology ................................................3
2.2. Abbreviations ..............................................4
3. Transport Network Architecture ..................................5
3.1. G.8080 Discovery Framework .................................7
4. Discovery Technologies ..........................................9
4.1. Generalized Automatic Discovery Techniques G.7714 ..........9
4.2. LMP and G.8080 Terminology Mapping .........................9
4.2.1. TE Link Definition and Scope .......................12
4.3. LMP and G.8080 Discovery Relationship .....................13
4.4. Comparing LMP and G.8080 ..................................14
5. Security Considerations ........................................15
6. Informative References .........................................15
7. Acknowledgements ...............................................161. Introduction 🌈
The GMPLS control plane is made of several building blocks, as described in [RFC3945] 💜. Those blocks cover signaling, routing, and link management, which are what you need to set up LSPs. For scalability, lots of physical resources can be bundled into one single TE link, so path computation and GMPLS control plane signaling can treat them as one.
Manually provisioning and managing these links is basically impractical in big networks, so that's why LMP was specified to manage TE links 🙈. There are two mandatory management capabilities: control channel management and TE link property correlation. There are also optional extras, like verifying physical connectivity and fault management. [LMP] defines the messages and procedures for GMPLS TE link management, and [LMP-TEST] defines the SONET/SDH-specific messages and procedures for link verification ✨.
ITU-T Recommendation G.8080 Amendment 1 [G.8080] splits control plane discovery into two separate processes 🍓. One happens in the transport plane space, and the other happens in the control plane space.
The ITU-T made Recommendation G.7714, "Generalized automatic discovery techniques" [G.7714], which defines the functional processes and information exchange for transport plane discovery. That means layer adjacency discovery and physical media adjacency discovery. G.7714 doesn't define any specific methods or protocols 🤷♀️. ITU-T Recommendation G.7714.1, "Protocol for automatic discovery in SDH and OTN networks" [G.7714.1], is where the protocol and procedure for transport plane layer adjacency discovery live. For example, it covers discovering the transport plane layer endpoint relationships and checking that they're connected.
The ITU-T is still working on extending discovery to the control plane too 👑. That includes a discovery framework architecture in G.8080 and a new Recommendation on "Control plane initial establishment, reconfiguration".
2. ASON Terminology and Abbreviations Related to Discovery 📚
ITU-T Recommendation G.8080 Amendment 1 [G.8080] and ITU-T Recommendation G.7714 [G.7714] are the sources for the definitions and mechanisms around transport plane discovery 🔍.
Quick heads-up: in this work, "Transport" means the data plane (sometimes called the transport plane or the user plane). It does not mean the transport layer (layer 4) of the OSI seven layer model, and it's not the kind of transport that protocols like the Transmission Control Protocol (TCP) mean 🙅♀️.
Special care must be taken with the acronym "TCP". In the context of the rest of this document, it means "Termination Connection Point", not the Transmission Control Protocol. 🚨
2.1. Terminology 💅
You're expected to already know the terminology in [LMP] and [LMP-TEST]. These ITU-T terms and abbreviations are also used in this document:
Connection Point (CP): A "reference point" made of a pair of co-located "unidirectional connection points". So it represents the binding of two paired bidirectional "connections" ✨.
Connection Termination Point (CTP): A connection termination point represents the state of a CP [M.3100] 🫧.
Characteristic Information: A signal with a specific format that gets transferred on "network connections". The specific formats are defined in the technology-specific recommendations. For trails, the Characteristic Information is the payload plus the overhead. The information transferred is characteristic of the layer network 🎀.
Link: A subset of ports at the edge of a subnetwork or access group, associated with a matching subset of ports at the edge of another subnetwork or access group 🔗.
Link Connection (LC): A transport entity that transfers information between ports across a link 🌸.
Network Connection (NC): A concatenation of link and subnetwork connections 🧶.
Subnetwork: A set of ports available for routing 'characteristic information' 🗺️.
Subnetwork Connection (SNC): A flexible connection that gets set up and released using management or control plane procedures 🪄.
Subnetwork Point (SNP): An abstraction that represents an actual or potential underlying connection point (CP) or termination connection point (TCP), for control plane representation 💭.
Subnetwork Point Pool (SNPP): A set of SNPs grouped together for routing 🍬.
Termination Connection Point (TCP): A reference point that represents the output of a Trail Termination source function or the input of a Trail Termination sink function. A network connection represents a transport entity between TCPs 🦋.
Trail Termination source/sink function: A "transport processing function" that takes the characteristic information of the layer network at its input, strips out the information related to "trail" monitoring, and passes the rest along at its output 🧹.
Unidirectional Connection: A "transport entity" that transfers information transparently from input to output ➡️.
Unidirectional Connection Point: A "reference point" that represents the binding of the output of a "unidirectional connection" to the input of another "unidirectional connection" 🔁.
2.2. Abbreviations 🔤
LMP: Link Management Protocol 💜
OTN: Optical Transport Network 🌈
PDH: Plesiosynchronous Digital Hierarchy 🍓
SDH: Synchronous Digital Hierarchy 💖
SONET: Synchronous Optical Network ✨
3. Transport Network Architecture 🛣️
Okay so the ITU-T Recommendation [G.805] gives us a generic functional architecture for transport networks, and it's technology-independent, which is literally iconic because it doesn't care what's underneath. It forms the basis for a whole family of technology-specific architectural recommendations for transport networks (e.g., SDH, PDH, OTN, etc.) 💖
G.805 uses a layered model with a client-server relationship between layers. It's recursive too: a network layer is a server to the client layer above it, and a client to the server layer below it 🔁 There are two basic building blocks in G.805: "subnetworks" and "links" 🧩 A subnetwork is a set of ports that are available for routing "characteristic information". A link is a subset of ports at the edge of one subnetwork (or "access group") that's associated with a matching subset of ports at the edge of another subnetwork or access group ✨
G.805 defines two types of connections: link connection (LC) and subnetwork connection (SNC) 🎀 An LC is fixed and inflexible, while an SNC is flexible and gets set up and released using management or control plane procedures. A network connection is a concatenation of subnetwork and link connections. Figure 1 illustrates link and subnetwork connections 🦋
(++++++++) (++++++++)
( SNC ) LC ( SNC )
(o)--------(o)----------(o)--------(o)
( ) CP CP ( )
(++++++++) (++++++++)
subnetwork subnetwork
Figure 1: Subnetwork and Link ConnectionsG.805 defines a set of reference points for identification in both the management and the control planes 🌸 These identifiers are NOT required to be the same. An LC or an SNC is delimited by connection points (CPs), and a network connection is delimited by a termination connection point (TCP) 💅 An LC in the client layer is represented by a pair of adaptation functions and a trail in the server layer network. A trail is the transfer of monitored adapted characteristics information of the client layer network between access points (APs) 🫶
A trail is delimited by two access points, one at each end. Figure 2 shows a network connection and how it relates to LCs and SNCs, and it also shows the CP and TCP reference points 🌈
|<-------Network Connection---------->|
| |
| (++++++++) (++++++++) |
|( SNC ) LC ( SNC ) |
(o)--------(o)----------(o)--------(o)|
TCP( )| CP CP |( )TCP
(++++++++) | | (++++++++)
| |
| Trail |
|<-------->|
| |
--- ---
\ / \ /
- -
AP 0 0 AP
| |
(oo)------(oo)
Figure 2: Network Connection with Link and Subnetwork ConnectionsFor management plane purposes, the G.805 reference points are represented by a set of management objects described in ITU-T Recommendation M.3100 [M.3100] 📋 Connection termination points (CTPs) and trail termination points (TTPs) are the management plane objects for CP and TCP, respectively 🍓
In the same way as in M.3100, the transport resources in G.805 are identified for the purposes of the control plane by entities suitable for connection control 🧚 G.8080 introduces the reference architecture for the control plane of Automatically Switched Optical Networks (ASONs). It also introduces a set of reference points relevant to the ASON control plane, plus how they relate to the matching points in the transport plane 👑 A subnetwork point (SNP) is an abstraction that represents an actual or potential underlying CP, or an actual or potential TCP. A set of SNPs grouped together for the purpose of routing is called an SNP pool (SNPP) 💜 Just like LC and SNC, the SNP-SNP relationship may be static and inflexible (this is called an SNP link connection), or it may be dynamic and flexible (this is called an SNP subnetwork connection) 🔥
3.1. G.8080 Discovery Framework
G.8080 gives us a reference control plane architecture based on the descriptive use of functional components, which represent abstract entities and abstract component interfaces 🧠 The description is generic, and no particular physical partitioning of functions is implied. The input/output information flows linked to the functional components help define what the components do, and they're conceptual, not physical 🌷 Components can be combined in different ways, and the description is not intended to limit implementations. Control plane discovery is described in G.8080 using three components: Discovery Agent (DA), Termination and Adaptation Performer (TAP), and Link Resource Manager (LRM) 💖
The goal of the G.8080 discovery framework is to establish the relationship between CP-CP link connections (transport plane) and SNP-SNP link connections (control plane) ✨ Its fundamental characteristic is the functional separation between the control and transport plane discovery processes and name spaces. G.8080 puts it like this: "This separation allows control plane names to be completely separate from transport plane names, and completely independent of the method used to populate the DAs with those transport names. In order to assign an SNP-SNP link connection to an SNPP link, it is only necessary for the transport name for the link connection to exist". So yes, it's possible to assign link connections to the control plane even when the link connection isn't physically connected 🙈
Discovery has two separate processes: (1) transport plane discovery, i.e., CP-to-CP and TCP-to-TCP connectivity; and (2) control plane discovery, i.e., SNP-to-SNP and SNPP links 🦋
G.8080 Amendment 1 defines the Discovery Agent (DA) as the entity responsible for discovery in the transport plane. The DA operates in the transport name space only, and in cooperation with the Termination and Adaptation Performer (TAP), it provides the separation between that space and the control plane names 🫧 A local DA is only aware of the CPs and TCPs assigned to it. The DA holds the CP-CP link connection in the transport plane so that SNP-SNP link connections can be bound to it later on by the TAP. The CP-CP relationship may be discovered (e.g., per G.7714.1) or provided by a management system 🌸
Control plane discovery happens entirely within the control plane name space (SNPs) 💅 The Link Resource Manager (LRM) holds the SNP-SNP binding information needed for the control plane name of the link connection, while the termination adaptation performer (TAP) holds the relation between the control plane name (SNP) and the transport plane name (CP) of the resource. Figure 3 shows the relationship and the different entities for transport and control discoveries 🌈
LRM LRM
+-----+ holds SNP-SNP Relation +-----+
| |-------------------------| |
+-----+ +-----+
| |
v v
+-----+ +-----+
| o | SNPs in SNPP | o |
| | | |
| o | | o |
| | | |
| o | | o |
+-----+ +-----+
| |
v v Control Plane
+-----+ +-----+ Discovery
| | Termination and | |
---|-----|-------------------------|-----|---------
| | Adaptation Performer | |
+-----+ (TAP) +-----+ Transport Plane
| \ / | Discovery
| \ / |
| +-----+ +-----+ |
| | DA | | DA | |
| | | | | |
| +-----+ +-----+ |
| / \ |
V/ \V
O CP (Transport Name) O CP (Transport Name)
Figure 3: Discovery in the Control and the Transport Planes4. Discovery Technologies 🔍
4.1. Generalized Automatic Discovery Techniques G.7714
Generalized automatic discovery techniques are described in G.7714 to help with resource management and routing for G.8080 💫 The word "routing" here is used in the transport sense, meaning routing connections in an optical network, which is different from the routing context usually associated with packet networks 🧁
G.7714 is concerned with two types of discovery:
- Layer adjacency discovery
- Physical media adjacency discovery
Layer adjacency discovery can be used to correlate physical connections with management configured attributes. Among other features, this capability allows a reduction in configuration and the detection of mis-wired equipment 🙌
Physical media adjacency discovery is a process that allows the physical testing of the media, for the purpose of inventory capacity and verifying the port characteristics of physical media adjacent networks 🔧
G.7714 does not specify specific protocols, but rather the type of techniques that can be used. G.7714.1 specifies a protocol for layer adjacency with respect to SDH and OTN networks for layer adjacency discovery. A GMPLS method for layer discovery using elements of LMP is included in this set of procedures 🌟
An important point about the G.7714 specification is that it specifies a discovery mechanism for optical networks, but not necessarily how the information will be used. It's intended that the transport management plane or a transport control plane may subsequently make use of the discovered information 💜
4.2. LMP and G.8080 Terminology Mapping 🎀
Okay so GMPLS is this whole squad of IP-based protocols (LMP is one of them 💖) that gives you a control plane for multiple data plane techs, like optical/transport networks and their resources (wavelengths, timeslots, etc.). It doesn't lock you into any particular control plane architecture either (see [RFC3945]). G.8080 is kinda its counterpart: it defines a control plane reference architecture for optical/transport networks, also without any restriction on how the control plane gets implemented. They were developed in separate standards forums with different scopes, so they use different terms and definitions. 🙈
Terminology mapping between LMP and ASON (G.805/G.8080) is a huge step toward understanding both architectures ✨. It also opens the door to cooperating wherever cooperation is possible. To make the mapping easier, we split data links in LMP into two types. According to LMP, each node a data link terminates on can consider it either a 'port' or a 'component link'. Both the LMP notions of port and component link are supported by the G.805/G.8080 architecture. G.8080's variable adaptation function is broadly equivalent to LMP's component link, meaning a single server-layer trail that dynamically supports different multiplexing structures 🦋. Also, when the data plane delivers its own addressing space, LMP Interface_IDs and Data Links IDs are used as handles by the control plane to the actual CP Name and CP-to-CP Name, respectively.
The terminology mapping is summarized in the table below. Heads up: it maps ASON terms to GMPLS terms that refer to equivalent objects, but in a lot of cases it's not a one-to-one mapping 👀. More info beyond discovery terminology can be found in [LEXICO].
+----------------+--------------------+-------------------+
| ASON Terms | GMPLS/LMP Terms | GMPLS/LMP Terms |
| | Port | Component Link |
+----------------+--------------------+-------------------+
| CP | TE Resource; | TE Resource; |
| | Interface (Port) | Interface. |
| | |(Comp. link) |
+----------------+--------------------+-------------------+
| CP Name | Interface ID | Interface ID(s) |
| | no further sub- | resources (such as|
| | division for(label)| timeslots, etc.) |
| | resource allocation| on this interface |
| | | are identified by |
| | | set of labels |
+----------------+--------------------+-------------------+
| CP-to-CP Link | Data Link | Data Link |
+----------------+--------------------+-------------------+
| CP-to-CP Name | Data Link ID | Data Link ID |
+----------------+--------------------+-------------------+
| SNP | TE Resource | TE Resource |
+----------------+--------------------+-------------------+
| SNP Name | Link ID | Link ID |
+----------------+--------------------+-------------------+
| SNP LC | TE Link | TE Link |
+----------------+--------------------+-------------------+
| SNP LC Name | TE Link ID | TE Link ID |
+----------------+--------------------+-------------------+
| SNPP | TE Link End | TE Link End |
| | (Port) | (Comp. Link) |
+----------------+--------------------+-------------------+
| SNPP Name | Link ID | Link ID |
+----------------+--------------------+-------------------+
| SNPP Link | TE Link | TE Link |
+----------------+--------------------+-------------------+
| SNPP Link Name | TE Link ID | TE Link ID |
+----------------+--------------------+-------------------+The composite identifiers look like this:
- Data Link ID:
<Local Interface ID; Remote Interface ID> - TE Link ID:
<Local Link ID; Remote Link ID>
Composite Identifiers are defined in the RFC 4204 [LMP]. LMP discovers data links and identifies them by the pair of local and remote interface IDs 🧚. TE links are made up of data links or component TE links. Similarly, TE links are identified by the pair of local and remote link ID 💜.
4.2.1. TE Link Definition and Scope
In the table, TE link/resource is equated with the concepts of SNP, SNP LC, SNPP, and SNPP link. The TE link definition is super broad in scope, so it's worth repeating here 🌸. The original definition shows up in [GMPLS-RTG]:
"A TE link is a logical construct that represents a way to group/map the information about certain physical resources (and their properties) that interconnects LSRs into the information that is used by Constrained SPF for GMPLS path computation, and GMPLS signaling".
Concise, yes, but it's probably worth pointing out a few of the implications 💅.
A component of the TE link may follow different paths between the pair of LSRs. For example, a TE link made up of multiple STS-3cs means the individual STS-3cs component links may take identical or different physical (OC-3 and/or OC-48) paths between LSRs 🫶.
The TE link construct is a logical construction covering many layers in networks [RFC3471]. A TE link can represent either unallocated potential or allocated actual resources. Further allocation gets represented by bandwidth reservation, and the resources may be real or, in the case of packets, virtual to allow for overbooking or other forms of statistical multiplexing schemes ✨.
Since TE links may represent large numbers of parallel resources, they can be bundled for efficient summarization of resource capacity. Typically, bundling represents a logical TE link resource at a particular Interface Switching Capability. Once TE link resources are allocated, the actual capacity may be represented as LSP hierarchical (tunneled) TE link capability in another logical TE link [HIER] 🔥.
TE links also bring in the notion of a Forwarding Adjacency (FA) and Interface Switching Capability [RFC3945]. The FA lets transport resources be represented as TE links. The Interface Switching Capability specifies the type of transport capability, such as Packet Switch Capable (PSC), Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM), Lambda Switch Capable (LSC), and Fiber-Switch Capable (FSC) 👑.
A TE link between GMPLS-controlled optical nodes may consist of a bundled TE link, which itself consists of a mix of point-to-point component links [BUNDLE]. A TE link is identified by the tuple (link Identifier (32-bit number), Component link Identifier (32-bit number), and generalized label (media specific)) 🌈.
4.3. LMP and G.8080 Discovery Relationship
LMP currently consists of four primary procedures. The first two are mandatory and the last two are optional:
- Control channel management
- Link property correlation
- Link verification
- Fault management
The LMP procedures relevant to G.8080 control plane discovery are control channel management, link property correlation, and link verification 🦋. The key to understanding G.8080 discovery aspects in relation to [LMP] is that LMP procedures are specific to an IP-based control plane abstraction of the transport plane.
LMP control channel management is used to establish and maintain control channel connectivity between LMP adjacent nodes. In GMPLS, the control channels between two adjacent nodes don't have to use the same physical medium as the TE links between those nodes 😭. The control channels that exchange the GMPLS control plane information exist independently of the TE links they manage (so control channels may be in-band or out-of-band, as long as the associated control points terminate the LMP packets). The Link Management Protocol [LMP] was designed to manage TE links independently of the physical medium capabilities of the data links 💖.
Link property correlation is used to aggregate multiple data links into a single TE link and to synchronize the link properties 🎀.
Link verification is used to verify the physical connectivity of the data links and to verify the mapping of the Interface-ID to Link-ID (CP to SNP). The local-to-remote associations can be obtained using a priori knowledge or using the link verification procedure 🧠.
Fault management is primarily used to suppress alarms and to localize failures. It's an optional LMP procedure, and whether you use it depends on the specific technology's capabilities 🍓.
[LMP] supports distinct transport and control plane name spaces with the (out-of-band) TRACE object (see [LMP-TEST]). The LMP TRACE object allows transport plane names to be associated with interface identifiers [LMP-TEST] 🌸.
Aspects of LMP link verification look similar to G.7714.1 discovery, but the two procedures are different, bestie 🙈. G.7714.1 provides discovery of transport plane layer adjacencies. It offers a generic procedure to discover the connectivity of two endpoints in the transport plane. The LMP link verification procedure, on the other hand, is a control-plane-driven procedure. It assumes either (1) a priori knowledge of the associated data plane's local and remote endpoint connectivity and Interface_IDs (for example, via management plane or use of G.7714.1), or (2) support from the remote node for associating the data interface being verified with the content of the TRACE object (inferred mapping). For SONET/SDH transport networks, LMP verification uses the SONET/SDH Trail Trace identifier (see [G.783]) 💅.
G.7714.1 supports the use of transport plane discovery independent of the platform using the capability. It also specifies the use of a Discovery Agent that could be located in an external system, plus the need to support text-oriented man-machine language for the interface. Therefore, G.7714.1 limits discovery messages to printable characters defined by [T.50] and requires Base64 encoding for the TCP-ID and DA ID. External name servers may be used to resolve the G.7714.1 TCP name, which lets the TCP have an IP, Network Service Access Protocol (NSAP), or any other address format 🌈. On the other hand, LMP is based on an IP-based control plane, and the LMP interface ID uses IPv4, IPv6, or unnumbered interface IDs ⭐.
4.4. Comparing LMP and G.8080 💅
okay so bestie, LMP exists to support GMPLS TE resource and TE link discovery 🦋 we went deep on the TE link definition back in section 4.2.1, and LMP is the thing that lets those TE link aspects get discovered and reported up to the control plane, or more specifically, the routing plane 🗺️ G.8080 and G.7714 are totally agnostic about which control plane and discovery protocol you pick, no drama 🫶 and LMP is a valid realization of a control plane discovery process under a G.8080 model. it fits right in ✨
G.7714 covers transport plane discovery, and it does it with respect to the transport layer CTPs or TCPs 💜 it uses ASON conventions and naming for the elements of the ASON control plane and the ASON management plane, which is very organized of it 🍓 this discovery supports a centralized management model of configuration AND a distributed control plane model. in other words, the discovered items can be reported to the management plane or the control plane, your choice bestie 👑 G.7714.1 gives you one realization of a transport plane discovery process 🧚
now the tea ☕ LMP and G.7714, G7714.1 are currently defined in different standards organizations 😭 they grew out of different naming schemes and architectural concepts, so they don't always match up at first glance. the difference is that G.7714.1 supports a transport plane layer adjacency connectivity verification that can be used by a control plane OR a management plane 🌈 LMP, on the other hand, is a control plane procedure for managing GMPLS TE links, which are GMPLS's control plane representation of the transport plane connections 💖
5. Security Considerations 🔐
okay this part is giving serious 🙈 since this document is purely descriptive in nature, it does not introduce any security issues. phew 😮💨
G.8080 and G.7714/G.7714.1 provide security as associated with the Data Communications Network on which they are implemented. so the security lives on that network underneath them 🔒
LMP is specified using IP, which provides security mechanisms associated with the IP network on which it is implemented. so LMP leans on IP security for its own protection, which is a whole vibe 💜
6. Informative References 📚
these are the receipts, bestie, and every single one is here 🧾
[LMP] Lang, J., "Link Management Protocol (LMP)", RFC 4204,
October 2005.
[LMP-TEST] Lang, J. and D. Papadimitriou, "Synchronous Optical
Network (SONET)/Synchronous Digital Hierarchy (SDH)
Encoding for Link Management Protocol (LMP) Test
Messages", RFC 4207, October 2005.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[GMPLS-RTG] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October
2005.
[BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[LEXICO] Bryskin, I. and A. Farrel, "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", Work in Progress, January 2006.for the ITU-T documents, check out http://www.itu.int for availability info 🌐
[G.783] ITU-T G.783 (2004), Characteristics of synchronous
digital hierarchy (SDH) equipment functional blocks.
[G.805] ITU-T G.805 (2000), Generic functional architecture of
transport networks.
[G.7714] ITU-T G.7714/Y.1705 (2001), Generalized automatic
discovery techniques.
[G.7714.1] ITU-T G.7714.1/Y.1705.1 (2003), Protocol for automatic
discovery in SDH and OTN networks.
[G.8080] ITU-T G.8080/Y.1304 (2001), Architecture for the
automatically switched optical network (ASON).
[M.3100] ITU-T M.3100 (1995), Generic Network Information Model.
[T.50] ITU-T T.50 (1992), International Reference Alphabet.7. Acknowledgements 🫶
the authors want to thank Astrid Lozano, John Drake, Adrian Farrel and Stephen Shew for their valuable comments 💖
the authors also want to thank ITU-T Study Group 15 Question 14 for their careful review and comments 🎀
Authors' Addresses 🧑💻
Don Fedyk
Nortel Networks
600 Technology Park Drive
Billerica, MA, 01821
Phone: +1 978 288-3041
EMail: dwfedyk@nortel.com
Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station 'C'
Ottawa, Ontario, Canada
K1Y-4H7
Phone: +1 613 763-5827
EMail: osama@nortel.com
Deborah Brungard
AT&T
Rm. D1-3C22
200 S. Laurel Ave.
Middletown, NJ 07748, USA
EMail: dbrungard@att.com
Jonathan P. Lang
Sonos, Inc.
223 E. De La Guerra
Santa Barbara, CA 93101
EMail: jplang@ieee.org
Dimitri Papadimitriou
Alcatel
Francis Wellesplein, 1
B-2018 Antwerpen, Belgium
Phone: +32 3 240-84-91
EMail: dimitri.papadimitriou@alcatel.beFull Copyright Statement ©️
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 🪪
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🌸
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 💜
📦 where this page comes from
- ietf: rfc4394 2006-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms