Tagged by CORD Jenkins version-tag job: 7044, for Gerrit patchset: 27207
VOL-4337: Code upgrade for 3/2020 G.988 support and remaining Extended Message Set support

Change-Id: I6c5e1a167216ad9b51e9da89460e9909465ae1bc
273 files changed
tree: fc79464533498eb2973f3e25754898eab198ef9a
  1. .gitignore
  2. .gitreview
  3. LICENSE
  4. Makefile
  5. README.md
  6. VERSION
  7. alarms.go
  8. alarms_test.go
  9. avc.go
  10. avc_test.go
  11. create.go
  12. create_test.go
  13. delete.go
  14. delete_test.go
  15. generated/
  16. get.go
  17. get_test.go
  18. getcurrent.go
  19. getcurrent_test.go
  20. getnext.go
  21. getnext_test.go
  22. go.mod
  23. go.sum
  24. layers.go
  25. layers_test.go
  26. mebase.go
  27. mebase_test.go
  28. meframe/
  29. messagetypes.go
  30. messagetypes_test.go
  31. mibreset.go
  32. mibreset_test.go
  33. mibupload.go
  34. mibupload_test.go
  35. omci.go
  36. omci_test.go
  37. reboot.go
  38. reboot_test.go
  39. set.go
  40. set_test.go
  41. settable.go
  42. settable_test.go
  43. software.go
  44. software_test.go
  45. synctime.go
  46. synctime_test.go
  47. test.go
  48. test_test.go
  49. vendor/
README.md

OMCI

OMCI gopacket library supports the encoding and decoding of ITU G.988 OMCI messages. Support for the Baseline and Extended Message Set has been completed for basic serialization and decode and some support for the MEFrame library.

Future work is to focus on getting unit test coverage >= 75% for the basic serialization and decode objects before work for additional extended message set support in the MEFrame library.

Recent Changes

In v2.0.0, the directory/package structure was reorganized (no API changes otherwise) in order to separate message type functionality on a filename basis. This will allow for future features and bug fixes to be better localized and to allow for better unit test coverage reporting.

Bug fixes will typically result in an increment of the third number in the version string and additional feature support will typically result in incrementing the second number.

Current user-test coverage

The make test command can be used to create code coverage support for the library. The current coverage for version 2.0.0 (as of 9/08/2021) is:

Entire Project: 97.3% of files and 70.2% of statements Generated Subdirectory: 98.5% of files and 51.9% of statements meframe Subdirectory: 80% of files and 55.4% of statements

Main Message Directory (below):

FileCoverage< 75%
alarms.go74.3%Y
avc.go86%
create.go82.5%
delete.go85.5%
get.go78.4%
getcurrent.go69.4%
getnext.go79.3%
layers.go100%
mebase.go93.3%
messagetypes.go100%
mibreset.go76.6%
mibupload.go77%
omci.go90.6%
reboot.go81.2%
set.go77.3%
settable.go81.5%
software.go75.2%
synctime.go79.3%
test.go79.9%

Other outstanding items

A few additional features have been requested and are listed below for future inclusion in the package:

  • Constraint checking (these are not yet fully parsed/provided by the OMCI code generated structs). This feature will hopefully be available in the near future.
  • Add AVC flag for appropriate attributes
  • Review other gopacket libraries for logging support and add some type of logging support if it is standard. If not, recommend design patterns users of this library can use to detect issues in decode or serialization.
  • For several of the software image message types, multiple instances can be supported. Unit test and source implementation to verify correct implementation is needed.

Also searching through the code for TODO statements will also yield additional areas of work to be performed.

What is not provided by this library

This library is not a full OMCI stack for either an OLT or an ONU. It is focused primarily on packet decode/serialization and a variety of structs and functions that are useful for handling the creation of OMCI frames and handling decoded frames from the PON.

For an OLT-side OMCI stack, you would still need to write:

  • OMCI CC sender & receiver (stop & wait protocol) with appropriate timeout support
  • OLT State machines to support
    • MIB Uploads/Audits/Resynchronization (and a MIB database implemention),
    • More sophisticated get & get-next support to make handle of MEs with lots of attributes or table attributes easy to handle and code,
    • Alarm Table support,
    • OMCI ME/Msg-Type capabilities inquiry,
    • Performance Monitoring collection (and initial time synchronization),
    • Service implementation

For an ONU-side OMCI stack, you would still need to write:

  • OMCC implementation,
  • MIB Database,
  • Get-Next cache for table attributes,
  • MIB upload next cache for MIB uploads,
  • Generation of any alarms/AVC notifications,
  • Actually acting on the create/delete/get/set/... requests from an OLT