Network Working Group Osama Aboul-Magd Internet Draft Nortel Networks Document: draft-aboulmagd-ccamp-transport-lmp- 01.txt Category: Informational Deborah Brungard AT&T Jonathan Lang Rincon Networks Dimitri Papadimitriou Alcatel June, 2003 A Transport Network View to LMP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) 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), i.e. G.8080, G.7714, and G.7714.1, and on-going ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) [G.8080] and transport network [G.805] terminology and relates it to the ITU- Aboul-Magd Expires Dec. 2003 1 Draft-aboulmagd-transport-lmp-01.txt June 2003 T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Terminology The reader is assumed to be familiar with the terminology in [LMP] and [LMP-TEST]. The following ITU terminology/abbreviations are used in this document: 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. OTN: Optical transport network PDH: Plesiosynchronous digital hierarchy SDH: Synchronous digital hierarchy. Subnetwork: a set of ports which are available for the purpose of routingÆ characteristic informationÆ. Subnetwork Connection (SNC): a flexible connection that is setup and released using management or control plane procedures. Link Connection (LC): a transport entity that transfers information between ports across a link. Network Connection (NC): A concatenation of link and subnetwork connections. Connection Termination Point (CTP): A Connection Termination Point (CTP) represents the state of a Connection Point (CP) (M.3100). The CP is a reference point representing the end point of a link connection and represents the North input port of an Adaptation function. 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. Subnetwork Point (SNP): SNP is an abstraction that represents an actual or potential underlying connection point (CP) or termination Aboul-Magd Expires Dec. 2003 2 Draft-aboulmagd-transport-lmp-01.txt June 2003 connection point (TCP) for the purpose of control plane representation. Subnetwork Point Pool (SNPP): A set of SNP that are grouped together for the purpose of routing. 4. Introduction The GMPLS control plane consists of several building blocks as described in [GMPLS-ARCH]. 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 traffic engineering (TE) link for the purposes of path computation by Constrained SPF and by GMPLS control plane signaling. As manual provisioning and management of these links is impractical, 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 [LMP] defines the messages and procedures for GMPLS TE link management. [LMP-TEST] defines SONET/SDH specific messages and procedures for link verification. G.8080 Amendment 1 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Æ 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 [G.7714]. ITU-T Recommendation G.7714.1 æProtocol for automatic discovery in SDH and OTN networksÆ defines a protocol and procedure for transport plane layer adjacency discovery (e.g. discovering the transport plane layer end point relationships and verifying their connectivity). The ITU-T is currently working to extend discovery to control plane aspects including defining a Recommendation on framework architecture for discovery and a Recommendation on ÆControl plane initial establishment, reconfiguration. 5. Transport Network Architecture A generic functional architecture for transport networks is defined in the ITU-T Recommendation 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. Aboul-Magd Expires Dec. 2003 3 Draft-aboulmagd-transport-lmp-01.txt June 2003 There are two basic building blocks defined in G.805: Æsubnetworksæ and ÆlinksÆ. A subnetwork is defined as a set of ports which 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 setup 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 plane. These identifiers are NOT required to be the same. A link connection or a subnetwork connection is delimited by connection points (CP). 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 (AP). 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 | |<-------->| Aboul-Magd Expires Dec. 2003 4 Draft-aboulmagd-transport-lmp-01.txt June 2003 | | --- --- \ / \ / - - AP 0 0 AP | | (oo)------(oo) Figure 2: Network Connection and Reference Points For management plane purpose, the G.805 reference points are represented by a set of management objects described in ITU recommendation M.3100. Connection termination points (CTP) and trail termination points (TTP) 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 purpose of control plane by entities suitable for connection control. G.8080 introduces the reference architecture for the control plane of the automatic switched optical networks (ASON). 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 SNP link connection) or it can be dynamic and flexible (this is referred to as SNP subnetwork connection). 6. G.8080 Discovery Framework G.8080 provides a reference control plane architecture based on the descriptive use of functional components representing abstract entities and abstract component interfaces. The description is generic and no particular physical partitioning of functions is implied. The input/output information flows associated with the functional components serve for defining the functions of the components and are considered to be 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 by using three components: Discovery Agent (DA), Termination and adaptation performer (TAP), and Link Resource Manager (LRM). The objective of the discovery framework in G.8080 is to establish the relationship between CP-CP link connections (transport plane) and SNP-SNP link connections (control plane). The fundamental characteristics of G.8080 discovery framework is the separation between the control and the transport plane name spaces. The separation between the two name spaces has the advantage that the Aboul-Magd Expires Dec. 2003 5 Draft-aboulmagd-transport-lmp-01.txt June 2003 discovery of the transport plane can be performed independent from that of the control plane (and vise-versa) of the other, and independent of the method used in each name space. This allows assigning link connections in the control plane without the link connection being physically connected. Discovery encompasses two separate processes: 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-to-SNPP links. G.8080 Amendment 1 defines the discovery agent (DA) as the entity responsible for the discovery in the transport plane. The DA operates in the transport name space only and provides the separation between that space and the control plane names. A local DA is only aware of the CPs and TCPs that are assigned to it. The DA holds the CP-CP link connection in the transport plane to enable SNP-SNP link connections to be bound to them at a later time. The CP-CP relationship may be discovered (e.g. per G.7714.1) or provided by a management system. Control plane discovery takes place entirely within the control plane name space (SNPs). The Link Resource Manager (LRM) holds the SNP-SNP binding information necessary 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 | SNPÆs in SNPP | o | | | | | | o | | o | | | | | | o | | o | +-----+ +-----+ | | v v Control Plane +-----+ +-----+ Discovery | | Termination and | | ---|-----|-------------------------|-----|--------- | | Adaptation Performer | | +-----+ (TAP) +-----+ Transport Plane Discovery Figure 3: Discover in the Control and the Transport Planes Aboul-Magd Expires Dec. 2003 6 Draft-aboulmagd-transport-lmp-01.txt June 2003 A discovery process may then validate the resulting SNP link connections. The degree of validation required is dependent on the integrity of the relationships initially provided by the transport plane (or management plane), and the integrity of the process used to map CTPs to SNPs. Specific information that needs to be exchanged, and specific protocol procedures for SNP and SNPP link association and validation have not been specified yet in ITU-T. 7. LMP and G8080 Discovery 7.1 LMP and G.8080 Terminology Mapping GMPLS is a set of IP-based protocols, including LMP, providing a control plane for multiple data plane technologies, including optical/transport networks and their resources (i.e. wavelengths, timeslots, etc.) and without assuming any restriction on the control plane architecture (see [GMPLS-ARCH]). Whereas, G.8080 defines a control plane reference architecture for optical/ transport networks. Being developed in separate standards forums, and with different scope, 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 refers to a component link as a variable adaptation function 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 handlers by the control plane to the actual CP Name and CP-to-CP Name, respectively. The terminology mapping is summarized in the following table: +----------------+------------------+----------------+ | ASON Terms | GMPLS/LMP Terms | GMPLS/LMP Terms| | | Port | Component Link | +----------------+------------------+----------------+ | CP | Interface (Port) | Interface. | | | |(Comp. link) | +----------------+------------------+----------------+ | CP Name | Interface ID | Interface ID | | | = Label | | +----------------+------------------+----------------+ | CP-to-CP | Data Link | Data Link | +----------------+------------------+----------------+ | CP-to-CP Name | Data Link ID | Data Link ID | +----------------+------------------+----------------+ | SNP | TE Link (Port) | TE Link (Comp) | | | (single link) | (single link) | Aboul-Magd Expires Dec. 2003 7 Draft-aboulmagd-transport-lmp-01.txt June 2003 +----------------+------------------+----------------+ | SNP Name | Link ID | Link ID | +----------------+------------------+----------------+ | SNP LC | TE Link | TE Link | +----------------+------------------+----------------+ | SNP LC Name | TE Link ID | TE Link ID | +----------------+------------------+----------------+ | SNPP | TE Link (Port) | TE Link (Comp) | +----------------+------------------+----------------+ | SNPP Name | Link ID | Link ID | +----------------+------------------+----------------+ | SNPP Link | TE Link | TE Link | +----------------+------------------+----------------+ | SNPP Link Name | TE Link ID | TE Link ID | +----------------+------------------+----------------+ where: - Data Link ID: - TE Link ID: .2 LMP and G.8080 Discovery Relationship LMP currently consists of four primary procedures, of which, the first two are mandatory and the last two are optional: 1. Control channel management 2. Link property correlation 3. Link verification 4. Fault management LMP procedures that are relevant to G.8080 control plane discovery are control channel maintenance and link property correlation. Key to understanding G.8080 discovery aspects in relation to 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. This is done using a Config message exchange followed by a lightweight keep-alive message exchange. Aboul-Magd Expires Dec. 2003 8 Draft-aboulmagd-transport-lmp-01.txt June 2003 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, itÆs 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 end points in the transport plane. Whereas, 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 end point 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 SONET/SDH Trail Trace identifier (see G.783). As G.7714.1 supports the use of transport plane discovery independent of the platform providing the capability. Furthermore G.7714.1 it supports use of a Discovery Agent located in an external system and 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. Whereas, LMP is based on the use of an IP-based control plane, and the LMP interface ID uses IPv4, IPv6, or unnumbered interface IDs (no encoding restrictions). In summary, comparing the LMP link verification with G.8080, LMP link verification process is in the G.8080 control plane discovery space, e.g. SNP link validation as described in 6.3/G.8080. And analogous to the description in G.8080, it is optional, dependent on the degree of validation required for an operatorÆs use scenario. 8. Security Considerations Aboul-Magd Expires Dec. 2003 9 Draft-aboulmagd-transport-lmp-01.txt June 2003 This draft doesnÆt introduce any security issues. 9. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 [LMP] J.P.Lang (Editor), "Link Management Protocol," draft-ietf- ccamp-lmp-09.txt, June 2003. 4 [LMP-TEST] J.P.Lang et al., "SONET/SDH Encoding for Link Management Protocol (LMP) Test messages," draft-ietf-ccamp-lmp- test-sonet-sdh-03.txt, May 2003. 5 [GMPLS-ARCH] Eric Mannie (Editor), Generalized Multi-protocol Label Switching Architecture,draft-ietf-ccamp-gmpls- architecture-07.txt, May 2003. 6 [G.7714] ITU-T G.7714/Y.1705 (2001), Generalized automatic discovery techniques. 7 [G.7714.1] ITU-T G.7714.1/Y.1705.1 (2003), Protocol for automatic discovery in SDH and OTN networks. 8 [G.8080] ITU-T G.8080/Y.1304 (2001), Architecture for the automatically switched optical network (ASON). 9 [G.805] ITU-T G.805 (2000), Generic functional architecture of transport netowrks. 0. Acknowledgement The authors would like to thank Astrid Luzano, Don Fedyk, and John Drake for their valuable comments. 1. Author's Addresses Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station ÆCÆ Ottawa, Ontario, Canada K1Y-4H7 Phone: +1 613 763-5827 Email: osama@nortelnetworks.com Deborah Brungard Aboul-Magd Expires Dec. 2003 10 Draft-aboulmagd-transport-lmp-01.txt June 2003 AT&T Rm. D1-3C22 200 S. Laurel Ave. Middletown, NJ 07748, USA Email: dbrungard@att.com Jonathan P. Lang Rincon Networks Santa Barbara, CA Email : jplang@ieee.org Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: +32 3 240-84-91 Email: dimitri.papadimitriou@alcatel.be Aboul-Magd Expires Dec. 2003 11 Draft-aboulmagd-transport-lmp-01.txt June 2003 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. Aboul-Magd Expires Dec. 2003 12