Child pages
  • Contributions

Some notes on TAPI LLDP model design

Andrea  Mazzini

12 February 2019


Reading 802.1AB-2016 and MEF 45.1, together with the minutes of last ONF face to face ( Santa Clara minutes ) plus OTCC 2019 01 15 TAPI Meeting Notes , please find below a list of items for discussion.

In general, it seems necessary to agree the Use Case that TAPI is required to fulfil, whether it is “full LLDP management feature” or any subset like e.g. “LLDP snooping”, whether the purpose is “topology discovery” or “topology consistency check”.

In a second step, it is necessary to agree to which extent the existing TAPI (mainly OAM related) modeling items can be augmented and/or reused for LLDP related management, e.g. reuse OamJob, MEP/MIP, CurrentData, etc.


1)      I have not found any IEEE/IETF spec describing LLDP snooping feature. Assuming it is a passive monitoring of LLDPDUs, note that it may coincide with a standard “receive only” LLDP Agent. Note also that LLDP is one-way only, so it is not foreseen any “expected” station(s) at “nearest bridge” or “nearest customer bridge”, for topology consistency check. 

2)      Reuse MEG/MEP paradigm? Consider that OamJob refers to OamServicePoint(s). Below two possible solutions:

  1. The IEEE LLDP “Port” class can extend both OamServicePoint (config) and MEP (state), or
  2. Define new e.g. ProtocolServicePoint (config) and ProtocolPoint (State) , to be augmented with LLDP specific attributes. ProtocolPoint can be an optional package of (Ethernet) CEP.

Below is used “LLDP-MEP” term to refer to the IEEE LLDP Port/Agent.



3)      LldpCfg may extend OamJob.

4)      LocalSystemData should be writable – as it is what sent by LLDP Job re local LLDP “MEP”. Otherwise it is assumed that the selection of an LLDP “port” implies fixed mapping to related/supporting equipment (and its parameters). TAPI models logical and physical (future equipment model) resources separately.

5)      More LLDP-MEPs can share same LocalSystemData object. Likely there is one LocalSystemData object per Ethernet UNI/ENNI/INNI. Care with LAG.

6)      There shall be zero, one or more RemoteSystemsData objects per each LLDP-MEP, as more remote LLDP-MEPs may send their info. (Agreed during 12/2 call)

7)      LLDP protocol is one-way only, i.e. LLDP-MEP sends local info which can be intercepted by any listening LLDP-MEP, without expecting any response (in “nearest bridge” or “nearest customer bridge” reachability spaces). RemoteSystemsData object can be modeled as

  1. a “job result” (Current Data paradigm), or
  2. a “discovered” LLDP-MEP (hence the model could be made more symmetric, e.g. using a single class for both ManagementAddressTxPort and ManagementAddress), building a sort of LLDP topology. This may recall (G)MPLS routing paradigm.

8)      Tx/Rx and Remote Statistics are “job results” / Current Data. Do we need these metrics in TAPI?

9)      Where the use of more than one MAC address is supported on a given Port, a separate instance of the LLDP agent is responsible for the operation of the protocol for each MAC address that is supported. Hence the “port” of IEEE model is actually an “LLDP agent” as it has only one MAC address.
NOTE: a consequence of the support of multiple MAC addresses on a Port is that there are multiple copies of the LLDP local system MIB and remote system MIB, one copy for each address supported.

10)             LLDP allows implementations that support three different operating modes: transmit only, receive only, or both transmit and receive . I have not seen these modes in the IEEE model.