Skip to main content

A Transport Network View of the Link Management Protocol (LMP)
draft-ietf-ccamp-transport-lmp-02

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4394.
Authors Jonathan Lang , Dimitri Papadimitriou , Deborah Brungard , Don Fedyk , Osama Aboul-Magd
Last updated 2013-03-02 (Latest revision 2005-05-06)
Replaces draft-aboulmagd-ccamp-transport-lmp
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4394 (Informational)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Alex D. Zinin
Send notices to kireeti@juniper.net, adrian@olddog.co.uk
draft-ietf-ccamp-transport-lmp-02
Network Working Group                      Don Fedyk  (Nortel Networks) 
Internet Draft                      Osama Aboul-Magd  (Nortel Networks) 
Category: Informational                        Deborah Brungard  (AT&T) 
Expires October 2005                       Jonathan Lang  (Sonos, Inc.) 
                                       Dimitri Papadimitriou  (Alcatel) 
                                                                        
                                                               May 2005 
 
 
        A Transport Network View of the Link Management Protocol 
                  <draft-ietf-ccamp-transport-lmp-02.txt> 
 
 
Status of this Memo 
 
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79.  
    
   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. 
    
   Abstract 
    
   The 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 on-going 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. 
    
    
    
    

  
D. Fedyk, Editor            Informational                           1 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
   Table of Contents 
 
   1. ASON Terminology and Abbreviations related to Discovery.........2 
   1.1 Terminology....................................................2 
   1.2  Abbreviations.................................................3 
   2. Introduction....................................................3 
   3. Transport Network Architecture..................................4 
   3.1 G.8080 Discovery Framework.....................................6 
   4. Discovery Technologies..........................................8 
   4.1 Generalized automatic discovery techniques G.7714..............8 
   4.2 LMP and G.8080 Terminology Mapping.............................9 
   4.2.1 TE Link Definition and Scope................................10 
   4.3 LMP and G.8080 Discovery Relationship.........................12 
   4.4 Comparing LMP and G.8080......................................13 
   5. Security Considerations........................................13 
   6. IANA Considerations............................................14 
   7. Intellectual Property Considerations...........................14 
   8. References.....................................................15 
   8.1 Normative References..........................................15 
   8.2 Informational References......................................15 
   9. Acknowledgements...............................................16 
   10. Author's Addresses............................................16 
   11. Disclaimer of Validity........................................17 
   12. Full Copyright Statement......................................17 
 
 
1. ASON Terminology and Abbreviations related to Discovery 
    
1.1 Terminology 
    
   The reader is assumed to be familiar with the terminology in [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 
   (CTP) 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 
   which 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. 
  
D. Fedyk, Editor            Informational                           2 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
 
   Network Connection (NC): A concatenation of link and subnetwork 
   connections. 
    
   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. 
    
   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 SNP 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" which 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" which 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". 
    
    
1.2  Abbreviations 
 
   LMP: Link Management Protocol 
    
   OTN: Optical transport network  
     
   PDH: Plesiosynchronous digital hierarchy  
     
   SDH: Synchronous digital hierarchy. 
2. Introduction 
    
    
   The GMPLS control plane consists of several building blocks as 
   described in [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 traffic engineering (TE) link for the purposes of path 
   computation and GMPLS control plane signaling.  
  
D. Fedyk, Editor            Informational                           3 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
    
   As manual provisioning and management of these links is 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 end point 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'. 
    
3. Transport Network Architecture 
    
    
   A generic functional architecture for transport networks is defined 
   in the International Telecommunications Union (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. 
   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 
  
D. Fedyk, Editor            Informational                           4 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
   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. 
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  
D. Fedyk, Editor            Informational                           5 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
                |<-------Network Connection---------->| 
                |                                     | 
                | (++++++++)              (++++++++)  | 
                |(   SNC    )   LC       (   SNC    ) | 
                (o)--------(o)----------(o)--------(o)| 
              TCP(          )| CP    CP |(          )TCP 
                  (++++++++) |          | (++++++++) 
                             |          | 
                             |  Trail   | 
                             |<-------->| 
                             |          | 
                            ---        --- 
                            \ /        \ / 
                             -          - 
                          AP 0          0 AP 
                             |          | 
                            (oo)------(oo) 
                              
    
           
   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 (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 purposes of the 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 an SNP link 
   connection) or it can be dynamic and flexible (this is referred to 
   as a SNP subnetwork connection). 
    
    
3.1 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 
  
D. Fedyk, Editor            Informational                           6 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
   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 functional 
   separation between the control and the transport plane discovery 
   processes and name spaces. From G.8080: "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". Thus, it is possible to 
   assign link connections to the control plane without the link 
   connection being physically connected. 
      
   Discovery encompasses 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], 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 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 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. 
    
    
    
    
    
    
    
    
    
    
    
    
  
D. Fedyk, Editor            Informational                           7 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
          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                     
          |    \                         /   |     
          |  +-----+                +-----+  | 
          |  | DA  |                |  DA |  | 
          |  |     |                |     |  | 
          |  +-----+                +-----+  | 
          | /                              \ | 
          V/                                \V 
          O  CP (Transport Name)             O   CP (Transport Name)            
    
      Figure 3: Discovery in the Control and the Transport Planes 
    
    
4. Discovery Technologies 
    
    
4.1 Generalized automatic discovery techniques G.7714 
    
   Generalized automatic discovery techniques are described in G.7714 
   to aid resource management and routing for G.8080. The term routing 
   here is described in the transport context of routing connections in 
   an optical network as opposed to the routing context typically 
   associated in 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 reduction in configuration and the 
   detection of miswired equipment.  
    
  
D. Fedyk, Editor            Informational                           8 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
   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 it specifies a 
   discovery mechanism for optical networks but not necessarily how the 
   information will be used. It is 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 
    
   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 
   and without any restriction on the control plane implementation. 
   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'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]. 
    
    
  
D. Fedyk, Editor            Informational                           9 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
   +----------------+--------------------+-------------------+ 
   | 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 LMP draft [LMP]. LMP 
   discovers Data Links and identifies them by the pair of local and 
   remote interface Ids. TE Links are comprised of Data Links or 
   component TE links. TE links are similarly identified by pair of 
   local and remote Link ID.   
    
    
    
    
4.2.1 TE Link Definition and Scope 
 

  
D. Fedyk, Editor            Informational                          10 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
   In the table, TE link/resource is equated with the concept of SNP, 
   SNP LC, SNPP and SNPP link. The definition of the TE link is broad in 
   scope and it is useful to repeat it here. The original definition 
   appears 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." 
    
   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 path 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 [RFC 3471]. 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 over 
   booking 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)).  
    
     
 
    
    
    
  
D. Fedyk, Editor            Informational                          11 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
4.3 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 management, link property correlation and Link 
   Verification. 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.  
      
   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 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 
  
D. Fedyk, Editor            Informational                          12 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
   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, NSAP or any other address format. 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.  
     
    
4.4 Comparing LMP and G.8080 
    
   LMP exists to support GMPLS TE resource and TE link discovery. In 
   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 which 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).  
 
5. Security Considerations 
 
   Since this document is purely descriptive in nature it does not 
   introduce any security issues. 
    
   G.8080 and G.7714/G.7714.1 provide security as associated with the 
   Data Communications Network on which they are implemented. 
    
  
D. Fedyk, Editor            Informational                          13 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
   LMP is specified using IP which provides security mechanisms 
   associated with the IP network on which it is implemented. 
    
6. IANA Considerations 
 
   This informational document makes no requests for IANA action. 
    
7. Intellectual Property Considerations 
    
   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. 
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  
D. Fedyk, Editor            Informational                          14 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
8. References 
    
8.1 Normative References 
    
    
   [BCP 78]    S. Bradner, "Intellectual Property Rights in IETF 
               Technology", BCP 79, RFC 3667, February 2004. 
    
   [BCP 79]    S. Bradner, "IETF Rights in Contributions", BCP 79,   
               RFC 3668, February 2004. 
    
    
    
    
8.2 Informational References  
    
   [LMP]       J.P.Lang (Editor), "Link Management Protocol," draft-
               ietf-ccamp-lmp-10.txt, October 2003. 
     
   [LMP-TEST]  J.P.Lang et al., "SONET/SDH Encoding for Link     
               Management Protocol (LMP) Test messages," draft-ietf-
               draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt, December 
               2004. 
    
   [RFC3945]   Eric Mannie (Editor), "Generalized Multi-protocol Label 
               Switching Architecture," RFC3945, October 2004. 
    
   [RFC3471]   Lou Berger (Editor), "Generalized Multi-Protocol Label 
               Switching (GMPLS)Signaling Functional Description," 
               RFC3471, January 2003. 
    
   [GMPLS-RTG] K. Kompella & Y. Rekhter (editors) "Routing Extensions 
               in Support of Generalized Multi-Protocol Label 
               Switching", draft-ietf-ccamp-gmpls-routing-09.txt, 
               December 2003. 
    
   [HIER]      K. Kompella & Y. Rekhter "LSP Hierarchy with Generalized 
               MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, 
               September 2002. 
    
   [BUNDLE]    K. Kompella, Y. Rekhter, Lou Berger "Link Bundling in 
               MPLS Traffic Engineering", draft-ietf-mpls-bundle-
               06.txt, December 2004. 
    
   [LEXICO]    A. Farrel & I Bryskin "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", draft-bryskin-ccamp-gmpls-ason-
               lexicography-02.txt, April 2005. 
    
   "For information on the availability of ITU-T Documents, please see 
   http://www.itu.int" 
  
D. Fedyk, Editor            Informational                          15 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
    
    
   [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. 
 
9. Acknowledgements 
    
   The authors would like to thank Astrid Lozano, John Drake, Adrian 
   Farrel and Stephen Shew for their valuable comments.  
    
   The authors would like to thank ITU-T Study Group 15 Question 14 for 
   their careful review and comments.  
    
    
10. Author's 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 
    
    
    
    
    
    
  
D. Fedyk, Editor            Informational                          16 


Internet Draft  draft-ietf-ccamp-transport-lmp-02.txt        May 2005 
 
 
   Deborah Brungard  
   AT&T 
   Rm. D1-3C22 
   200 S. Laurel Ave. 
   Middletown, NJ 07748, USA 
   Email: dbrungard@att.com 
    
   Jonathan P. Lang  
   Sonos, Inc. 
   506 Chapala Street 
   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.be 
    
    
11. Disclaimer of Validity 
 
   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. 
 
12. Full Copyright Statement 
    
   Copyright (C) The Internet Society (2005).  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. 
 
  
 

  
D. Fedyk, Editor            Informational                          17