Network Working Group D. Fedyk Request for Comments: 4394 O. Aboul-Magd Category: Informational Nortel Networks D. Brungard AT&T J. Lang Sonos, Inc. D. Papadimitriou Alcatel February 2006 A Transport Network View of the Link Management Protocol (LMP) 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).
AbstractThe Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T.
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 ...............................................16 RFC3945]. The building blocks include signaling, routing, and link management for establishing LSPs. For scalability purposes, multiple physical resources can be combined to form a single TE link for the purposes of path computation and GMPLS control plane signaling. As manual provisioning and management of these links are impractical in large networks, LMP was specified to manage TE links. Two mandatory management capabilities of LMP are control channel management and TE link property correlation. Additional optional capabilities include verifying physical connectivity and fault management. [LMP] defines the messages and procedures for GMPLS TE link management. [LMP-TEST] defines SONET/SDH-specific messages and procedures for link verification. ITU-T Recommendation G.8080 Amendment 1 [G.8080] defines control plane discovery as two separate processes; one process occurs within the transport plane space and the other process occurs within the control plane space. The ITU-T has developed Recommendation G.7714, "Generalized automatic discovery techniques" [G.7714], defining the functional processes and information exchange related to transport plane discovery aspects, i.e., layer adjacency discovery and physical media adjacency discovery. Specific methods and protocols are not defined in Recommendation G.7714. ITU-T Recommendation G.7714.1, "Protocol for automatic discovery in SDH and OTN networks" [G.7714.1], defines a
protocol and procedure for transport plane layer adjacency discovery (e.g., discovering the transport plane layer endpoint relationships and verifying their connectivity). The ITU-T is currently working to extend discovery to control plane aspects providing detail on a discovery framework architecture in G.8080 and a new Recommendation on "Control plane initial establishment, reconfiguration". G.8080] and ITU-T Recommendation G.7714 [G.7714] provide definitions and mechanisms related to transport plane discovery. Note that in the context of this work, "Transport" relates to the data plane (sometimes called the transport plane or the user plane) and does not refer to the transport layer (layer 4) of the OSI seven layer model, nor to the concept of transport intended by protocols such as the Transmission Control Protocol (TCP). Special care must be taken with the acronym "TCP", which within the context of the rest of this document means "Termination Connection Point" and does not indicate the Transmission Control Protocol. LMP] and [LMP-TEST]. The following ITU-T terminology/abbreviations are used in this document: Connection Point (CP): A "reference point" that consists of a pair of co-located "unidirectional connection points" and therefore 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: Signal with a specific format, which is transferred on "network connections". The specific formats will be 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 that are associated with a corresponding 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 that are available for the purpose of routing 'characteristic information'. Subnetwork Connection (SNC): A flexible connection that is set up and released using management or control plane procedures. Subnetwork Point (SNP): SNP is an abstraction that represents an actual or potential underlying connection point (CP) or termination connection point (TCP) for the purpose of control plane representation. Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together for the purpose of routing. Termination Connection Point (TCP): A reference point that represents the output of a Trail Termination source function or the input to a Trail Termination sink function. A network connection represents a transport entity between TCPs. Trail Termination source/sink function: A "transport processing function" that accepts the characteristic information of the layer network at its input, removes the information related to "trail" monitoring, and presents the remaining information 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".
G.805]. This recommendation describes the functional architecture of transport networks in a technology-independent way. This architecture forms the basis for a set of technology-specific architectural recommendations for transport networks (e.g., SDH, PDH, OTN, etc.). The architecture defined in G.805 is designed using a layered model with a client-server relationship between layers. The architecture is recursive in nature; a network layer is both a server to the client layer above it and a client to the server layer below it. There are two basic building blocks defined in G.805: "subnetworks" and "links". A subnetwork is defined as a set of ports that are available for the purpose of routing "characteristic information". A link consists of a subset of ports at the edge of one subnetwork (or "access group") and is associated with a corresponding subset of ports at the edge of another subnetwork or access group. Two types of connections are defined in G.805: link connection (LC) and subnetwork connection (SNC). A link connection is a fixed and inflexible connection, while a subnetwork connection is flexible and is set up and released using management or control plane procedures. A network connection is defined as 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 Connections G.805 defines a set of reference points for the purpose of identification in both the management and the control planes. These identifiers are NOT required to be the same. A link connection or a subnetwork connection is delimited by connection points (CPs). A network connection is delimited by a termination connection point (TCP). A link connection in the client layer is represented by a pair of adaptation functions and a trail in the server layer network. A trail represents 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 of the trail. Figure 2 shows a network connection and its relationship with link and subnetwork connections. Figure 2 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 Connections For 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 the Automatically Switched Optical Networks (ASONs). G.8080 introduces a set of reference points relevant to the ASON control plane and their relationship to the corresponding 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 that are grouped together for the purpose of routing is called SNP pool (SNPP). Similar to LC and SNC, the SNP-SNP relationship may be static and inflexible (this is referred to as an SNP link connection), or it can be dynamic and flexible (this is referred to as an SNP subnetwork connection).
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 Planes
RFC3945]). On the other hand, G.8080 defines a control plane reference architecture for optical/transport networks without any restriction on the control plane implementation. Being developed in separate standards forums, and with different scopes, they use different terms and definitions.
Terminology mapping between LMP and ASON (G.805/G.8080) is an important step towards the understanding of the two architectures and allows for potential cooperation in areas where cooperation is possible. To facilitate this mapping, we differentiate between the two types of data links in LMP. According to LMP, a data link may be considered by each node that it terminates on as either a 'port' or a 'component link'. 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, i.e., a single server-layer trail dynamically supporting different multiplexing structures. Note that 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 following table: Note that the table maps ASON terms to GMPLS terms that refer to equivalent objects, but in many cases there is not a one-to-one mapping. Additional information 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 | +----------------+--------------------+-------------------+ where composite identifiers are: - 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 composed of data links or component TE links. TE links are similarly identified by pair of local and remote link ID.
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". While this definition is concise, it is probably worth pointing out some of the implications of the definition. A component of the TE link may follow different paths between the pair of LSRs. For example, a TE link comprising multiple STS-3cs, 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 encompassing many layers in networks [RFC3471]. A TE link can represent either unallocated potential or allocated actual resources. Further allocation is 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 incorporate the notion of a Forwarding Adjacency (FA) and Interface Switching Capability [RFC3945]. The FA allows transport resources to 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)).
LMP] is that LMP procedures are specific for 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 are not required to use the same physical medium as the TE links between those nodes. The control channels that are used to exchange the GMPLS control plane information exist independently of the TE links they manage (i.e., control channels may be in-band or out-of-band, provided 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 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 is an optional LMP procedure; its use will depend 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 appear similar to G.7714.1 discovery; however, the two procedures are different. G.7714.1 provides discovery of the transport plane layer adjacencies. It provides a generic procedure to discover the connectivity of two
endpoints in the transport plane. On the other hand, the LMP link verification procedure is a control-plane-driven procedure and assumes either (1) a priori knowledge of the associated data plane's local and remote endpoint connectivity and Interface_IDs (e.g., via management plane or use of G.7714.1), or (2) support of 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. Furthermore, G.7714.1 specifies the use of a Discovery Agent that could be located in an external system and the need to support the use of text-oriented man-machine language to provide the interface. Therefore, G.7714.1 limits the 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, allowing the TCP to have an IP, Network Service Access Protocol (NSAP), or any other address format. On the other hand, LMP is based on the use of an IP-based control plane, and the LMP interface ID uses IPv4, IPv6, or unnumbered interface IDs. section 4.2.1, we elaborated on the definition of the TE link. LMP enables the aspects of TE links to be discovered and reported to the control plane, more specifically, the routing plane. G.8080 and G.7714 are agnostic to the type of control plane and discovery protocol used. LMP is a valid realization of a control plane discovery process under a G.8080 model. G.7714 specifies transport plane discovery with respect to the transport layer CTPs or TCPs using ASON conventions and naming for the elements of the ASON control plane and the ASON management plane. This discovery supports a centralized management model of configuration as well as a distributed control plane model; in other words, discovered items can be reported to the management plane or the control plane. G.7714.1 provides one realization of a transport plane discovery process. Today, LMP and G.7714, G7714.1 are defined in different standards organizations. They have evolved out of different naming schemes and architectural concepts. Whereas G.7714.1 supports a transport plane layer adjacency connectivity verification that can be used by a
control plane or a management plane, LMP is a control plane procedure for managing GMPLS TE links (GMPLS's control plane representation of the transport plane connections). [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 information on the availability of the ITU-T documents, please see http://www.itu.int. [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.
Full 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 email@example.com. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).