[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-aboulmagd-ccamp-transport-lmp) 00 01 02 RFC 4394

Network Working Group                                         Don Fedyk
                                                       Osama Aboul-Magd
Internet Draft                                          Nortel Networks
Document: draft-ietf-ccamp-transport-lmp-00.txt
Category: Informational                                Deborah Brungard
Expires March 2005
                                                                   AT&T

                                                          Jonathan Lang
                                                            Sonos, Inc.

                                                  Dimitri Papadimitriou
                                                                Alcatel

                                                              Sept 2004



                    A Transport Network View of LMP
                  <draft-ietf-ccamp-transport-lmp-00.txt>


Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance
   with RFC3668 [RFC3668].

   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) links. The GMPLS control plane (routing and
   signaling) uses TE links for establishing Label Switched Paths


D. Fedyk, Editor            Informational                           1


Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004


   (LSPs). This memo describes the relationship of the LMP procedures
   to 'discovery' as defined in the International Telecommunication
   Union (ITU), 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.

   Table of Contents

   1. Terminology.....................................................2
   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.............................8
   4.2.1 TE Link Definition and Scope................................10
   4.3 LMP and G.8080 Discovery Relationship.........................11
   4.4 Comparing LMP and G.8080......................................12
   5. Security Considerations........................................13
   6. Intellectual Property Considerations...........................13
   7. References.....................................................13
   7.1 Normative References..........................................13
   7.2 Informational References......................................14
   8. Acknowledgements...............................................15
   9. Author's Addresses.............................................15
   Copyright Notice..................................................16


1. 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:

   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.

   OTN: Optical transport network

   PDH: Plesiosynchronous digital hierarchy

   SDH: Synchronous digital hierarchy.


D. Fedyk, Editor            Informational                           2

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004


   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
   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.

2. 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 and GMPLS control plane signaling.

   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.

   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.

D. Fedyk, Editor            Informational                           3

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004


   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) 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
   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.










D. Fedyk, Editor            Informational                           4

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004


                  (++++++++)              (++++++++)
                 (   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   |
                             |<-------->|
                             |          |
                            ---        ---
                            \ /        \ /
                             -          -
                          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
   recommendation M.3100 [M.3100]. Connection termination points (CTP)
   and trail termination points (TTP) are the management plane objects
   for CP and TCP respectively.


D. Fedyk, Editor            Informational                           5

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004


   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
   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. The separation between the two processes
   and corresponding two name spaces has the advantage that the
   discovery of the transport plane can be performed independent from
   that of the control plane (and vice-versa), 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: (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

D. Fedyk, Editor            Informational                           6

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004


   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.

          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: Discover in the Control and the Transport Planes







D. Fedyk, Editor            Informational                           7

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004


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.

   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 are 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

D. Fedyk, Editor            Informational                           8

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004


   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
   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:
   +----------------+--------------------+-------------------+
   | ASON Terms     | GMPLS/LMP Terms    | GMPLS/LMP Terms   |
   |                | Port               | Component Link    |
   +----------------+--------------------+-------------------+
   | CP             | 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       | 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)     |
   +----------------+--------------------+-------------------+
   | 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: <Local Interface ID; Remote Interface ID>
   - TE Link ID: <Local Link ID; Remote Link ID>

D. Fedyk, Editor            Informational                           9

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004



4.2.1 TE Link Definition and Scope

   In the table TE link is equated the concept of SNP, SNP LC, SNPP and
   SNPP link. The definition of the TE link is broad in scope and is
   useful repeating 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 the purpose of path computation, and by
   GMPLS signaling."

   While this definition is concise it is probably worth pointing some
   of the implications of the definition.

   A component of the TE link may follow different path between the
   pair of LSRs. A 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 form of statistical multiplexing schemes.

   Since TE links may represent large number 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 [GMPLS-ARCH]. 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 typical TE link between GMPLS controlled optical nodes would
   consist of a bundled (TE link) which itself consists
   of a mix of point-to-point links and FAs [BUNDLE] . A TE link is
   identified by the tuple: (Bundled link Identifier(32 bit number),
   Component link Identifier(32 bit number) and generalized label(media
   specific)).


D. Fedyk, Editor            Informational                          10

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004




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.
   This is done using a Config message exchange followed by a
   lightweight keep-alive message exchange.

   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

D. Fedyk, Editor            Informational                          11

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004


   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 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 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 link discovery. In section 5.2.1 we
   elaborated on the definition of the TE link. LMP enables the aspects
   of TE links to be discovered, and delivered 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 TEs (GMPLSÆs control plane
   representation of the transport plane connections).





D. Fedyk, Editor            Informational                          12

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004




5. Security Considerations

   Since this draft 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.

   LMP is specified using IP which provides security mechanisms
   associated with the IP network on which it is implemented.

6. 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.


7. References

7.1 Normative References


   [RFC3668]    S. Bradner, "Intellectual Property Rights in IETF
                Technology", BCP 79, RFC 3668, February 2004.









D. Fedyk, Editor            Informational                          13

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004


7.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.

   [GMPLS-ARCH] Eric Mannie (Editor), "Generalized Multi-protocol Label
                Switching Architecture," draft-ietf-ccamp-gmpls-
                architecture-07.txt, May 2003.

   [RFC 3471]  Lou Berger (Editor), "Generalized Multi-Protocol Label
                Switching (GMPLS)Signaling Functional Description,"
                draft-ietf-ccamp-gmpls-architecture-07.txt, 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-04.txt,
                July 2002


   "For information on the availability of ITU 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

D. Fedyk, Editor            Informational                          14

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004




   [T.50]      ITU-T T.50 (1992), International Reference Alphabet

8. Acknowledgements

   The authors would like to thank Astrid Lozano, John Drake, Adrian
   Farrel and Stephen Shew for their valuable comments.

9. Author's Addresses

   Don Fedyk
   Nortel Networks
   600 Technology Park Drive
   Billerica, MA, 01821
   Phone: +1 978 288-3041
   Email: dwfedyk@nortelnetworks.com

   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
   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









D. Fedyk, Editor            Informational                          15

Internet Draft  draft-ietf-ccamp-transport-lmp-00.txt       Sept 2004


Copyright Notice


   "Copyright (C) The Internet Society (2004).  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."







































D. Fedyk, Editor            Informational                          16


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/