Beruflich Dokumente
Kultur Dokumente
ITU-T G.988
TELECOMMUNICATION Amendment 1
STANDARDIZATION SECTOR
OF ITU (11/2018)
Amendment 1
Summary
Recommendation ITU-T G.988 specifies the optical network unit (ONU) management and control
interface (OMCI) for optical access networks.
Recommendation ITU-T G.988 specifies the managed entities (MEs) of a protocol-independent
management information base (MIB) that models the exchange of information between an optical line
termination (OLT) and an ONU. In addition, it covers the ONU management and control channel,
protocol and detailed messages.
Amendment 1 contains various updates to ITU-T G.988 (2017). This amendment contains editorial
corrections and clarifications along with the following substantive changes and extensions to PON
OMCI related to bonded ONUs, filtering on DHCP for admission control purposes, synchronization
alarm support, ONU timezone offset and ONU manufacturing data.
History
Edition Recommendation Approval Study Group Unique ID*
1.0 ITU-T G.988 2010-10-07 15 11.1002/1000/10891
1.1 ITU-T G.988 (2010) Amd. 1 2011-04-13 15 11.1002/1000/11126
1.2 ITU-T G.988 (2010) Amd. 2 2012-04-22 15 11.1002/1000/11501
1.3 ITU-T G.988 (2010) Cor. 1 2012-06-13 15 11.1002/1000/11641
2.0 ITU-T G.988 2012-10-29 15 11.1002/1000/11784
2.1 ITU-T G.988 (2012) Amd. 1 2014-05-14 15 11.1002/1000/12185
2.2 ITU-T G.988 (2012) Amd. 2 2016-06-22 15 11.1002/1000/12795
3.0 ITU-T G.988 2017-11-06 15 11.1002/1000/13291
3.1 ITU-T G.988 (2017) Amd. 1 2018-11-29 15 11.1002/1000/13744
Keywords
G-PON, OMCI, PON, XG-PON.
____________________
* To access the Recommendation, type the URL http://handle.itu.int/ in the address field of your web
browser, followed by the Recommendation's unique ID. For example, http://handle.itu.int/11.1002/1000/11
830-en.
NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some other
obligatory language such as "must" and the negative equivalents are used to express requirements. The use of
such words does not suggest that compliance with the Recommendation is required of any party.
ITU 2019
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior
written permission of ITU.
1 Scope............................................................................................................................. 1
2 References..................................................................................................................... 1
3 Definitions .................................................................................................................... 6
3.1 Terms defined elsewhere ................................................................................ 6
3.2 Terms defined in this Recommendation ......................................................... 6
4 Abbreviations and acronyms ........................................................................................ 6
5 Conventions .................................................................................................................. 15
6 Reference model and terms .......................................................................................... 15
6.1 OMCI in the access network .......................................................................... 15
6.2 ONU functions................................................................................................ 15
6.3 Support of multicast connection ..................................................................... 16
6.4 Voice over Internet protocol management ..................................................... 16
7 Requirements of the management interface specification ............................................ 17
7.1 Configuration management ............................................................................ 17
7.2 Fault management .......................................................................................... 18
7.3 Performance management .............................................................................. 18
7.4 Security management ..................................................................................... 18
8 Protocol-independent MIB for the OMCI .................................................................... 19
8.1 Managed entities ............................................................................................. 19
8.2 Managed entity relation diagrams .................................................................. 30
9 MIB description ............................................................................................................ 52
9.1 Equipment management ................................................................................. 56
9.2 ANI management, traffic management .......................................................... 96
9.3 Layer 2 data services ...................................................................................... 133
9.4 Layer 3 data services ...................................................................................... 211
9.5 Ethernet services ............................................................................................. 221
9.6 This clause is intentionally left blank ............................................................. 233
9.7 xDSL services ................................................................................................. 233
9.8 Time division multiplex services.................................................................... 340
9.9 Voice services ................................................................................................. 367
9.10 Premises networks .......................................................................................... 401
9.11 This clause is intentionally left blank ............................................................. 407
9.12 General purpose managed entities .................................................................. 407
9.13 Miscellaneous services ................................................................................... 427
9.14 Mid-span passive optical network reach extender.......................................... 444
9.15 RS232/RS485 interface service ...................................................................... 459
1 Scope
This Recommendation specifies the optical network unit (ONU) management and control interface
(OMCI) for optical access networks.
The OMCI specification addresses ONU configuration, fault management and performance
management for optical access system operation, and for several services including:
• gigabit-capable passive optical network encapsulation method (GEM) adaptation layers;
• Ethernet services, including media access control (MAC) bridged local area networks
(LANs);
• circuit emulation service (CES);
• voice services.
This Recommendation defines a protocol necessary to support the capabilities identified for these
ONUs. It also allows optional components and future extensions.
Amendment 1 continues the maintenance and evolution of OMCI as defined in Recommendation
ITU-T G.988 (2017) as amended.
The amendment contains editorial corrections and clarifications along with the following substantive
changes and extensions to PON OMCI:
• support of bonded ONUs;
• ability to filter on higher layer protocols (e.g., DHCP) for admission control purposes;
• support of reporting discarded upstream GEM frames;
• support of PON and G.fast cardholder codepoints;
• cardholder ME updates and clarifications to IEEE 802.3 codepoints;
• synchronization alarm support over OMCI;
• clarifications to ITU-T G.988 enhanced security control ME on OMCI authentication and the
actions on ONU activation;
• corrections to ITU-T G.988 entity class table;
• clarifications on the software download negotiation of extended versus baseline message set;
• support of ONU timezone offset;
• support of ONU manufacturing data.
2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the currently
valid ITU-T Recommendations is regularly published. The reference to a document within this
Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
3 Definitions
5 Conventions
In bit vectors indicated in this Recommendation, the rightmost bit is bit 1. This represents the least
significant bit (LSB), while bit 8 represents the most significant bit (MSB) within a byte. If the bit
vector is made up of more than one byte, then bit numbering starts from the least significant byte
onwards.
In attribute descriptions that refer to the Boolean values true and false, true is coded as 0x01 in
hexadecimal and false is coded as 0x00. A Boolean attribute is always one byte.
In attribute descriptions that refer to spaces, the American standard code for information interchange
(ASCII) space character (value 0x20) must be used for the entire size of the attribute.
An ASCII string is a sequence of ASCII encoded characters, terminated by the null character (0x00).
If a string occupies the entire allocated size of an attribute, the terminating null is not required.
This Recommendation frequently states that the OLT makes certain decisions or takes certain actions.
While the OMCI commands may emanate from the OLT, there is no implication that the actual
decision or action impetus comes from logic internal to the OLT, rather than from a separate
management system or a human operator.
ONU
OLT ODN U
ONU
V S/R PON R/S PON
interface interface U
G.988(12)_F6.1-1
Physical link.
OMCC of each ONU
ONU
UNI LT UNI
ANI AN LT
Managed
entity B Entity created by OLT
9.xx.xx
Managed Managed
entity A entity B Entity A has explicit pointer to entity B
9.xx.xx 9.xx.xx
Managed Managed
Entity A has implicit ID relationship to
entity A entity B
entity B (ME IDs are equal)
9.xx.xx 9.xx.xx
Managed Managed
entity A 1 entity B There can be 0..X instances of A related to B
0..X
9.xx.xx 9.xx.xx
Managed Managed
entity A 1 entity B There is a 1 to 1 relationship of A to B
1
9.xx.xx 9.xx.xx
Software
1 1
image
9.1.4
ONU data 1
1
9.1.3 1 2
Cardholder ONU-G Cardholder
1 1..127 1..127 1
1
1 9.1.2
9.1.6 1 9.1.6
1..255 GEM port 1..255
network CTP
9.2.3
1 Protected 1
ANI-G traffic Protection ANI-G
data
9.2.1 9.1.10 9.2.1
G.988(12)_F8.2.1-2
9.1.6 1 1 9.1.6
1..255 GEM port GEM port 1..255
network CTP network CTP
9.2.3 9.2.3
1 Protected Extra 1
ANI-G traffic Protection traffic ANI-G
data
9.2.1 9.1.10 9.2.1
G.988(12)_F8.2.1-3
PPTP 1 1 0..1
1 xx UNI 0..1 MB port
1
1 1 ICMPv6 proc
MB port pre-assign table
UNI-G Enet frame designation 9.3.33
PM, up/dn data
9.3.5
9.12.1 9.3.30-31 1 MB port
PM
1
9.3.9
G.988(12)_F8.2.2-1
NOTE – A bridge port may be associated with any IEEE 802.3 UNI, such as Ethernet or xDSL, or another
IEEE 802.3 function such as an IP host config data ME.
GEM GAL
1 interworking 0..1 1 Ethernet
TP PM
9.2.4 9.2.8
0..1 1 GAL
0..n Ethernet
8 profile
9.2.7
802.1p
0..8 0..1
mapper svc
profile
9.3.10 1
Dot1 rate
limiter
9.3.18
UNI-G 1 1 PPTP
xx UNI
9.12.1 G.988(12)_F8.2.2-2
NOTE – A mapper service profile may be associated with any IEEE 802.3 UNI, such as Ethernet or xDSL, or
another IEEE 802.3 function such as an IP host config data ME.
The two basic layer 2 services can be used in various combinations to achieve different overall
connectivities. There are three major functional styles of layer 2 connectivity, illustrated in
Figures 8.2.2-3 to 8.2.2-5:
– N:1 bridging, where a bridge is used to serve multiple UNI ports from a single access network
interface (ANI) service;
– 1:M mapping, where a mapper is used to serve a single UNI with multiple ANI connections,
based on IEEE 802.1p priorities;
– 1:P filtering, where a bridge with filters is used to serve a single UNI with multiple ANI
connections, based on some VLAN information other than IEEE 802.1p priorities.
Given these three basic possibilities, there are also four more complex combinations as well,
illustrated in Figures 8.2.2-6 to 8.2.2-9. It is strongly encouraged that these applications be utilized
before other, more exotic styles of usage.
MAC bridge 1
port config
data
9.3.4
1
1 1
Dot1 rate 1 0..1 MAC bridge
limiter service
profile
9.3.18 9.3.1
(Extended) 1 1 1 1 (Extended)
VLAN tag 1 VLAN tag
op 1 op
9.3.12-13 1 1 9.3.12-13
PPTP PPTP
xx xx
UNI UNI
G.988(12)_F8.2.2-3
M
Dot1 rate 1 802.1p 1 (Extended)
limiter mapper service VLAN tag
1 0..1 profile 1 1 op
9.3.18 9.3.10 9.3.12-13
1
1
PPTP
xx
UNI
G.988(12)_F8.2.2-4
(Extended) 1 1 VLAN
VLAN tag tagging filter
op 1 1 data
9.3.12-13 9.3.11
PPTP
xx
UNI
G.988(12)_F8.2.2-5
1 1
MAC bridge MAC bridge
port config 1 port config
data data
9.3.4 9.3.4
(Extended) 1 1 1 1 (Extended)
VLAN tag VLAN tag
op 1 1 op
9.3.12-13
1 1 9.3.12-13
PPTP PPTP
xx xx
UNI UNI
G.988(12)_F8.2.2-6
1 1
GEM 1 1 GEM
interworking interworking
TP GEM GEM TP
9.2.4 interworking interworking 9.2.4
1 1 TP TP 1 1 1
1 9.2.4 9.2.4
1 1
1 M M 1
802.1p 802.1p
mapper service 1 1 mapper service
profile 1 1 profile
9.3.10 9.3.10
(Extended) 1 VLAN
1
VLAN tag tagging filter
op 1 1 data
9.3.12-13 9.3.11
PPTP
xx
UNI
G.988(12)_F8.2.2-7
PPTP PPTP
xx xx
UNI UNI
G.988(12)_F8.2.2-8
1 1
GEM 1 1 GEM
interworking interworking
TP GEM GEM TP
9.2.4 interworking interworking 9.2.4
1 1 TP TP 1 1
1 9.2.4 9.2.4 1
1 1
1 M M 1
802.1p 802.1p
mapper service 1 1 mapper service
profile 1 1 profile
9.3.10 9.3.10
PPTP PPTP
xx xx
UNI UNI
G.988(12)_F8.2.2-9
Figure 8.2.2-10 illustrates the use of the multicast IW TP. A bridge is used to multiplex the multiple
ANI-side ports into the single (in this case) UNI-side port. It is essential to have a unicast path in
parallel to the multicast path because the unicast path carries the upstream signalling that is required
for control of multicast transmissions. In most scenarios, a unicast path already exists for other user
communications.
Figure 8.2.2-11 illustrates the downstream broadcast configuration. Figure 8.2.2-12 illustrates [IEEE
802.1ag] in a MAC bridge model. Figure 8.2.2-13 illustrates [IEEE 802.1ag] in an IEEE 802.1p
mapper model.
Extended 1..n 1 1
VLAN tag op
(optional)
1 1
MAC bridge MAC bridge
port config 1 1 port config
data 1 data
9.3.4 2 9.3.4
MAC bridge
service
profile
9.3.1
1 (Extended)
VLAN tag
op
1 9.3.12-13
MC MAC bridge 1
subscriber port config 1
config data
9.3.28 9.3.4
1 MC 1
subscriber
n monitor
9.3.29 1
MC PPTP
operations xx
profile UNI
9.3.27 G.988(12)_F8.2.2-10
1..n
1 1
MAC bridge MAC bridge
port config port config
data data
9.3.4 9.3.4
VLAN 1 1 VLAN
tagging filter tagging filter
data M M data
9.3.11 9.3.11
Dot1ag
MEP 1
9.3.22 0..p
Dot1ag Dot1ag Dot1ag
1 M
MEP CCM maintenance maintenance
database assoc domain
9.3.24 9.3.20 9.3.19
G.988(12)_F8.2.2-12
Dot1ag Dot1ag
MEP CFM stack
9.3.22 9.3.25
Dot1ag Dot1ag
maintenance 1 M maintenance
assoc domain
9.3.20 9.3.19 G.988(12)_F8.2.2-13
NOTE – If a mapper is associated with the ports of a bridge, the 802.1ag entities should be associated with the bridge and its ports,
rather than with the mapper.
xTU-R PM xTU-C
history channel
PM
9.7.22 9.7.23
Interworking
1 VCC TP
0..n 9.13.4
VP network AAL5 PM
CTP 1 history data
9.13.9 0..4 9.13.6
NOTE – Individual bearer channels accessible via two MSBs of PPTP ME ID.
MoCA UNI-G
Ethernet
PM
9.10.2 9.12.1
G.988(12)_F8.2.6-1
NOTE – MEs that require long character strings point to large string MEs. MEs that require a network address point to network
address MEs.
NOTE – MEs that require long character strings point to large string MEs. MEs that require a network address point to network
address MEs.
SIP agent
PM history
data
9.9.14
NOTE – MEs that require long character strings point to large string MEs. MEs that require a network address point to network
address MEs.
MGC PM TCP/UDP
history data config data
9.9.17 9.4.3 G.988(12)_F8.2.8-4
NOTE – MEs that require long character strings point to large string MEs. MEs that require a network address point to network
address MEs.
0..1
Network IP or IPv6
1 address host config
1 data
9.12.3 9.4.1, 9.4.5
Authentication TCP/UDP
security config data
method
9.12.4 9.4.3 G.988(12)_F8.2.8-5
GEM 0..1
1 interworking
TP
9.2.4 1
0..1 VoIP voice
1 CTP
1 1 0..1 9.9.4
CES phy
Structured Unstructured PM 1, 2, 3
OR
1 1 9.8.4, -.12-13
1
PW ATM PW ATM 1 1..n ITU-T G.983.2
PM history config data traffic descriptor
data
9.8.16 9.8.15 [ITU-T G.983.2], 7.5.2
1
1..n
ITU-T G.983.2 ITU-T G.983.2
PPTP ATM UNI UNI B-PON
[ITU-T G.983.2], 7.3.1 [ITU-T G.983.2], 7.3.5
G.988(12)_F8.2.9-2
(Extended) 1
VLAN tag
op
9.3.12-13
PW Ethernet Ethernet
config data pseudowire
parms
9.8.17 9.8.18
MAC bridge
OR port config
1..n data
9.3.4
1..n
UNI-G PPTP
xx
UNI
9.12.1 G.988(12)_F8.2.9-3
PPTP 1 0..255 RE
RE UNI ANI-G
9.14.2 9.14.1
G.988(12)_F8.2.10-1
NOTE – In many cases, the RE ANI-G and PPTP RE UNI are implemented on the same circuit pack. If so, the port-mapping
package can be used to create the hybrid line card.
RE common RE common
amplifier amplifier
parms parms
9.14.6 9.14.6
RE upstream RE downstream
1 0..255
amplifier amplifier
9.14.3 9.14.4 G.988(12)_F8.2.10-2
NOTE – In many cases, the RE upstream amplifier and RE downstream amplifier are implemented on the same circuit pack. If so,
the port-mapping package can be used to create the hybrid line card.
RE upstream
amplifier
9.14.3
PPTP 1 0..255 RE
RE UNI ANI-G
9.14.2 9.14.1
G.988(12)_F8.2.10-3
RE common
amplifier
parms
9.14.6
RE downstream
amplifier
9.14.4
PPTP 1 0..255 RE
RE UNI ANI-G
9.14.2 9.14.1
G.988(12)_F8.2.10-4
1
To MAC bridge service per TCP/UDP 0..1 1 RE config
existing in-band management config data portal
protocol server 9.4.3 9.14.5
G.988(12)_F8.2.10-5
Figure 8.2.10-5 – In-band management for the mid-span PON reach extender
8.2.11 Point-to-point gigabit Ethernet fed ONU
See Figure 8.2.11-1.
PPTP 1 M ONU-E
Ethernet UNI
9.5.1 9.1.13
1
1
ONU data
9.1.3
G.988(12)_F8.2.11-1
9 MIB description
This clause defines all ONU MEs of interest to the Recommendations that subscribe to it.
Recognizing the heritage of the OMCI through [ITU-T G.983.2], code points for a number of MEs
are permanently reserved for legacy implementations. In a few cases, MEs defined in earlier
Recommendations have proven to be of little interest. As reserved code points, such MEs remain
available for use in new applications, if needed, but their definitions appear only in the original
Recommendations.
ME descriptions include:
a) The purpose of the entity.
b) The relationships of the ME with other MEs.
c) The attributes of the entity, an ordered list that specifies both syntax and semantics.
AVCs are reported via AVC messages. An ME cannot encompass more than 16 attributes, in addition
to its ME ID, and the AVC message contains a bit map of 16 bits that match the attributes in order,
starting with 1. If an ME can generate AVCs, its definition includes an AVC table that matches
attributes with their corresponding bit numbers for easy reference. Attributes that do not trigger AVC
notifications are shown as N/A, while bit positions for non-existent attributes are shown as reserved.
Test results are reported:
a) via an expected test result message if the test is invoked by a test command from the OLT;
or
b) via an autonomous test result message if a test failure is detected autonomously by the ONU;
or
c) via an alarm message in the case of autonomous self-test failure in the start-up phase.
Details of these messages and their coding appear in Annex A.
IPv6 address representation
The OMCI management information model was developed in the context of IPv4, which uses 4 byte
addresses. IPv6 requires 16 bytes to fully represent an address. It is undesirable to define completely
new MEs for IPv6, and both versions are likely to coexist for some time.
It is observed that 0.0.x.y is not a valid IPv4 address, although 0.0.0.0 may appear occasionally, for
example in Internet group management protocol (IGMP) messages.
This Recommendation specifies that, for any 4 byte attribute defined as an IP address, mask or
gateway, if the value is 0.0.x.y, where x and y are not both 0, then x.y is to be interpreted as a pointer
to a large string ME that represents an IPv6 address. The syntax of the representation is described in
[b-IETF RFC 4291]. When explicitly allowed for an individual attribute, the large string may also
contain a URI.
Usually, large strings are created and deleted by the OLT. For IPv6 address representation, the ONU
may also need to create and delete a large string. To avoid numbering conflicts, it is recommended
that the OLT number large strings from 1 upwards, while the ONU number auto-created large strings
from 65 534 downwards.
MEs whose IP addresses are treated in accordance with this clause include:
• Dot 1X configuration profile;
• Multicast operations profile, querier IP address attribute. In this attribute, 0.0.0.0 is legal in
IPv4;
• SIP agent config data, SIP domain name server (DNS) address attributes;
• SNMP configuration data.
Alarm
Alarm
Alarm Description
number
0 Equipment alarm Functional failure on an internal interface
1 Powering alarm Loss of external power to battery backup unit. This alarm is
typically derived through an external interface to a battery backup
unit, and indicates that AC is no longer available to maintain
battery charge.
2 Battery missing Battery is provisioned but missing
3 Battery failure Battery is provisioned and present but cannot recharge
4 Battery low Battery is provisioned and present but its voltage is too low
5 Physical intrusion Applies if the ONU supports detection such as door or box open
6 ONU self-test failure ONU has failed autonomous self-test
7 Dying gasp ONU is powering off imminently due to loss of power to the ONU
itself. This alarm may be sent in conjunction with the powering
alarm if the backup unit cannot supply power and the ONU is
shutting down.
8 Temperature yellow No service shutdown at present, but the circuit pack is operating
beyond its recommended range.
9 Temperature red Some services have been shut down to avoid equipment damage.
The operational state of the affected PPTPs indicates the affected
services.
10 Voltage yellow No service shutdown at present, but the line power voltage is
below its recommended minimum. Service restrictions may be in
effect, such as permitting no more than N lines off-hook or ringing
at one time.
11 Voltage red Some services have been shut down to avoid power collapse. The
operational state of the affected PPTPs indicates the affected
services.
12 ONU manual power off The ONU is shutting down because the subscriber has turned off
its power switch.
13 Inv-Image Software image is invalid (Note)
14 PSE overload yellow Indicates that the ONU is nearing its maximum ability to supply
the known PoE demand of the attached PDs. The thresholds for
declaring and clearing this alarm are vendor-specific.
9.1.2 ONU2-G
This ME contains additional attributes associated with a PON ONU. The ONU automatically creates
an instance of this ME. Its attributes are populated according to data within the ONU itself.
This ME is the same as the ONT2-G of [ITU-T G.984.4], with extensions.
Relationships
This ME is paired with the ONU-G entity.
Attributes
Managed entity ID: This attribute uniquely identifies each instance of this ME. There is only
one instance, number 0. (R) (mandatory) (2 bytes)
Equipment ID: This attribute may be used to identify the specific type of ONU. In some
environments, this attribute may include the common language equipment
identification (CLEI) code. (R) (optional) (20 bytes)
Optical network unit management and control channel (OMCC) version: This attribute
identifies the version of the OMCC protocol being used by the ONU. This
allows the OLT to manage a network with ONUs that support different OMCC
versions. Release levels of [ITU-T G.984.4] are supported with code points of
the form 0x8y and 0x9y, where y is a hexadecimal digit in the range 0..F.
Support for continuing revisions of this Recommendation is defined in the
0xAy and OxBy range.
NOTE 1 – The complete list of managed entities supported by an ONU cannot
be derived from the OMCC version attribute. Refer to other ITU-T G.988
OMCI mechanisms for deriving this information (clause I.1.1.1 which
describes the use of clauses 9.12.9 Managed entity and 9.12.10 Attribute ME
for retrieval of ITU-T G.988 supported ME, and clause I.1.2 for discovering
the ONU hardware and service configuration of the ONU through MIB
uploads.)
NOTE 2 – 0xBz values greater than B5 are reserved to report new
ITU-T G.988 Annex A message versions (relative to ITU-T G.988 (2014)
Amd1).
Bit Model
1 (LSB) N:1 bridging, Figure 8.2.2-3
2 1:M mapping, Figure 8.2.2-4
3 1:P filtering, Figure 8.2.2-5
4 N:M bridge-mapping, Figure 8.2.2-6
5 1:MP map-filtering, Figure 8.2.2-7
6 N:P bridge-filtering, Figure 8.2.2-8
7 N:MP bridge-map-filtering, Figure 8.2.2-9
8…16 Reserved
NOTE 1 – It is not implied that an ONU may not support other connectivity models.
(R) (optional) (2 bytes)
Current connectivity mode: This attribute specifies the Ethernet connectivity model that the
OLT wishes to use. The following code points are defined.
Discussion:
To allow for the possibility that the OLT does not support flexible
configuration, the ONU vendor must assure that the priority queues and traffic
schedulers are configured in a meaningful and useful way by factory default,
and that this default configuration is restored upon ONU initialization and MIB
reset. The specifics of such a configuration are beyond the scope of this
Recommendation.
The ME ID of both the T-CONT and traffic scheduler contains a slot number.
Even when attributes in the above list are RW, it is never permitted to change
the slot number in a reference. That is, configuration flexibility never extends
across slots. It is also not permitted to change the directionality of an upstream
queue to downstream or vice versa.
Priority queue scale factor: If this optional attribute is implemented, it specifies the scale
factor of several attributes of the priority queue ME of clause 9.2.10. The
default value of this attribute is 1. (R, W) (optional) (2 bytes)
NOTE 3 – Some legacy implementations may take the queue scale factor from the
GEM block length attribute of the ANI-G ME. That option is discouraged in new
implementations.
Actions
Get, set
Notifications
Attribute value change
Number Attribute value change Description
1 N/A
2 OMCC version OMCC version supported in the ONU
3..11 N/A
12..16 Reserved
Vendor-specific usage
In this application, the software image ME is flexible, in keeping with the needs of particular vendors
and applications. The distinction between fundamental and vendor-specific usage is that the ME ID
must not be a value that could be used in the fundamental usage application. That is, the second byte
of the ME ID must be neither 0x00 nor 0x01.
The ONU automatically instantiates as many instances as it is prepared to support.
• In its vendor-specific usage, the attributes of the software image ME are optional.
• The actions are optional.
• Files may or may not exist in versioned pairs (previous revision, next revision).
Relationships
A vendor-specific instance of the software image ME represents an externally visible file on
the ONU. The content and use of the file are not specified.
Attributes
Managed entity ID: This attribute uniquely identifies each instance of this ME. The first byte
indicates the physical location of the equipment hosting the software image,
either the ONU (0) or a cardholder (1..254). The second byte distinguishes
between software image ME instances, and in vendor-specific usage is
required to have neither the value 0x00 nor the value 0x01. To facilitate
discovery by the OLT, it is suggested that the first byte of the ME ID be 0, and
that the second byte be numbered consecutively from 2. (R) (mandatory) (2
bytes)
Version: If this attribute is supported, its meaning is the same as that of the fundamental
usage application. (R) (optional) (14 bytes)
Is committed: This attribute indicates whether the associated file is committed (1) or
uncommitted (0). Vendor-specific instances may or may not exist in pairs, and
may or may not support the concept of a commit. (R) (optional) (1 byte)
Is active: This attribute indicates whether the associated file is active (1) or inactive (0).
Vendor-specific instances may or may not support the concept of an active
state. (R) (optional) (1 byte)
Is valid: This attribute indicates whether the associated file is valid (1) or invalid (0).
Vendor-specific instances may or may not include a way to determine their
validity. (R) (optional) (1 byte)
Product code: This attribute provides a way for a vendor to indicate product code information
on a file. It is a character string, padded with trailing nulls if it is shorter than
25 bytes. (R) (optional) (25 bytes)
Image hash: This attribute is an MD5 hash of the software image. It is computed at
completion of the end download action. (R) (optional) (16 bytes)
Actions
Get
9.1.5 Cardholder
The cardholder represents the fixed equipment slot configuration of the ONU. Each cardholder can
contain 0 or 1 circuit packs; the circuit pack models equipment information that can change over the
lifetime of the ONU, e.g., through replacement.
One instance of this ME exists for each physical slot in an ONU that has pluggable circuit packs. One
or more instances of this ME may also exist in an integrated ONU, to represent virtual slots. Instances
of this ME are created automatically by the ONU, and the status attributes are populated according to
data within the ONU itself.
Slot 0 is intended to be used only in an integrated ONU. If an integrated ONU is modelled with a
universal slot 0, it is recommended that it does not contain additional (non-zero) virtual slots. A
cardholder for virtual slot 0 is recommended.
There is potential for conflict in the semantics of the expected plug-in unit type, the expected port
count and the expected equipment ID, both when the slot is not populated and when a new circuit
pack is inserted. The expected plug-in unit type and the plug-in type mismatch alarm are mandatory,
state S8 state S9
Cardholder Cardholder
actual type: X actual type: Y
expected type: plug-and-play expected type: plug-and-play
create circuit pack X
create: circuit pack
auto-create: UNI, PPTP, PQs
G.988(12)_F9.1.5-1
Some of the following circuit pack types are obsolete in current applications. Their code points and
definitions are reserved for backward compatibility, but in the interest of brevity, they are not listed.
Alarm
Alarm Alarm Description
number
0 Equipment alarm A failure on an internal interface or failed self-test
1 Powering alarm Fuse failure or failure of DC/DC converter
2 Self-test failure Failure of circuit pack autonomous self-test
3 Laser end of life Failure of transmit laser imminent
4 Temperature yellow No service shutdown at present, but the circuit pack is
operating beyond its recommended range.
5 Temperature red Service has been shut down to avoid equipment damage.
The operational state of the affected PPTPs indicates the
affected services.
6..207 Reserved
208..223 Vendor-specific alarms Not to be standardized
Relationships
One instance of this ME is associated with the ONU ME.
Attributes
Managed entity ID: This attribute uniquely identifies each instance of this ME. There is only
one instance, number 0. (R) (mandatory) (2 bytes)
Size,
Field name Description
bytes
Physical port 1 Duplicates are allowed.
The corresponding physical port in the port list
attribute should be 0.
Equipment type 1 2 ME type 1, from Table 11.2.4-1. The first
equipment type in the list is understood to be the
master (in the first row of the table, in the case
of duplicate physical ports). The administrative
state, operational state and ARC attributes of the
master override the corresponding attributes of
secondary MEs.
… 2 … secondary MEs that share the physical port
Equipment type 12 2 Secondary ME type 12
As many as 12 ME types can be associated with a given physical port, and
even more by duplicating the physical port field. (R) (optional) (N rows
* 25 bytes)
Actions
Get, get next
Notifications
None.
9.1.9 Equipment extension package
This ME supports optional extensions to circuit pack MEs. If the circuit pack supports these features,
the ONU creates and deletes this ME along with its associated real or virtual circuit pack.
Relationships
An equipment extension package may be contained by an ONU-G or cardholder.
Attributes
Managed entity ID: This attribute uniquely identifies each instance of this ME. Through an
identical ID, this ME is implicitly linked to an instance of the ONU-G or
cardholder. (R) (mandatory) (2 bytes)
Environmental sense: This attribute provisions an ONU that supports external sense points,
e.g., physical security detectors at an enclosure. Each pair of bits is defined as
follows.
00 Sense point disabled (default)
01 Report contact closure
10 Report contact open
11 Sense point disabled (same as 00)
Each bit corresponds to bit 1-3 of the EPON capability extension and the
OLT may enable each bit if the capability is supported or true. If the
capability is not supported, the bit has no effect.
If the OLT does not designate configurations by the EPON setup extension,
the ONU uses the following default values unless they are not supported.
ackEnable configuration = enable,
Sleep indication configuration = disable,
Early wake-up configuration = enable
(R, W) (optional) (1 byte)
Missing consecutive bursts threshold: The Clobi attribute specifies the maximum number
of missing consecutive scheduled bursts from the ONU that the OLT is willing
to tolerate without raising an alarm. The value of this attribute defaults to 4.
(R, W) (mandatory) (4 bytes)
Actions
Get, set
Notifications
None.
9.1.15 ONU3-G
This ME contains additional attributes and alarms associated with a PON ONU. The ONU
automatically creates an instance of this ME. Its attributes are populated according to data within the
ONU itself.
Upon instantiation of this ME, the Total number of status snapshots S, the Number of valid status
snapshots M, and Next status snapshot index K are populated from the non-volatile memory. If the
non-volatile memory values are not available (e.g., at the initialization of an off-the-shelf ONU), the
Total number of status snapshots attribute is set to the maximum size of status snapshot record table
the ONU can maintain, which is a static capability parameter, while both the Number of valid status
snapshots and the Next status snapshot index attributes are set to zero.
The Status snapshot record table is implemented as a circular buffer containing up to S record of size
N. The size and format of the snapshot record are vendor-specific. Each time the ONU takes and
stores a status snapshot, it increments the Number of valid status snapshots M, saturating at S, and
increments Next status snapshot index K in modulo S:
Alarm
Alarm
Alarm Description
number
0 Flash memory
performance yellow
1 Flash memory
performance red
2 Loss of redundant In an ONU with redundant power supplies, an indication of the
power supply loss of one of the two redundant power supplies.
3 Loss of redundant In an ONU with dual -48DC power feeds, an indication of the
power feed loss of one of the two power feeds.
4 Ground Fault Ground fault; ONU has detected a loss of grounding or a
degradation in the ground connection.
Time qualification block: This attribute describes the time-qualification to be applied to the
ONU RTC local time. The following fields are supported:
Bits
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
Time Timezone Reserved RFC RFC 3339 minutes offset (from UTC
qualification offset 339 time)
time
offset
sign
where
Time This attribution qualifies the OLT time. Valid values are:
qualification
0 The OLT is locally timed
(1-bit)
1 The OLT timestamps are UTC timestamped
Timezone This attribute governs the time offset behaviour of the ONU RTC:
information
0 No timezone offset information
(1-bit)
1 Timezone offset provided in the RFC 3339 time offset
RFC 3339 RFC 3339 Timesone offset sign. A value of 0 indicates a positive offset and a
Time offset 1 indicates a negative offset
sign (from
UTC time)
(1-bit)
RFC 3339 Describes the RFC 3339 minutes offset
minutes
offset (from
UTC time)
(11-bits)
(R, W) (mandatory) (2 bytes)
Actions
Get, set
Alarm
Alarm Alarm Description
number
0 Low received optical Received downstream optical power below threshold.
power
1 High received optical Received downstream optical power above threshold.
power
2 SF Bit error-based signal fail. Industry practice normally
expects the BER to improve by at least an order of
magnitude before clearing the alarm.
3 SD Bit error-based signal degrade. Industry practice normally
expects the BER to improve by at least an order of
magnitude before clearing the alarm.
4 Low transmit optical Transmit optical power below lower threshold
power
5 High transmit optical Transmit optical power above upper threshold
power
6 Laser bias current Laser bias current above threshold determined by vendor;
laser end of life pending
7..207 Reserved
208..223 Vendor-specific alarms Not to be standardized
Test result: The ONU may report a test result autonomously if it performs self-test
functions autonomously.
9.2.2 T-CONT
An instance of the traffic container ME T-CONT represents a logical connection group associated
with a G-PON PLOAM layer alloc-ID. A T-CONT can accommodate GEM packets in priority queues
or traffic schedulers that exist in the GEM layer.
The ONU autonomously creates instances of this ME. The OLT can discover the number of T-CONT
instances via the ANI-G ME. When the ONU's MIB is reset or created for the first time, all supported
T-CONTs are created. The OLT provisions alloc-IDs to the ONU via the PLOAM channel. Via the
OMCI, the OLT must then set the alloc-ID attributes in the T-CONTs that it wants to activate for user
traffic, to create the appropriate association with the allocation ID in the PLOAM channel. There
Actions
Create, delete, get, set
Get current data (optional)
Notifications
Threshold crossing alert
Alarm Threshold value attribute No. (Note)
Threshold crossing alert
number
1 PSBd HEC error count 1
2 XGTC HEC error count 2
3 Unknown profile count 3
4 XGEM HEC loss count 4
5 XGEM key errors 5
6 XGEM HEC error count 6
NOTE – This number associates the TCA with the specified threshold value attribute of the
threshold data 1 managed entity.
9.2.19 ANI-E
This ME organizes data associated with each access network interface supported by an EPON ONU.
The ONU automatically creates one instance of this ME for each PON physical port.
Relationships
An instance of this ME is associated with each instance of a physical PON interface.
Attributes
Managed entity ID: This attribute uniquely identifies each instance of this ME. Its value
indicates the physical position of the PON interface. The first byte is the slot
ID, defined in clause 9.1.5. The second byte is the port ID. (R) (mandatory) (2
bytes)
Encryption and FEC capability: This attribute is used by the OLT to read the encryption
and FEC capabilities. The most significant 4 bits denote the encryption
capability and the least significant 4 bits denote the FEC capability. It is noted
that downstream encryption is mandatory.
The coding for the most significant field is specified as follows:
0x0: upstream encryption is not supported (1G-EPON ONU)
0x1: upstream encryption is supported (1G-EPON ONU)
0x2: encryption is activated as part of [IEEE 802.1X] authentication/key
establishment (10G/10G-EPON ONU or 10G/1G-EPON ONU)
The coding for the least significant field is specified as follows:
0x0: FEC is not supported for 1G link (1G-EPON ONU or
10G/1G-EPON ONU)
0x1: FEC is supported for 1G link (1G-EPON ONU or 10G/1G-EPON
ONU)
0x2: mandatory FEC capability (10G/10G-EPON ONU)
(R) (optional) (1 byte)
Points to:
MAC bridge service profile or
802.1p mapper service profile
9.3.18: Dot1 rate 3x traffic descriptors
limiter
Linked to:
MAC bridge service profile or
9.3.26: Dot1ag 9.3.19: Dot1ag 9.3.21: Dot1ag 802.1p mapper service profile
chassis-mgt info maintenance default MD level
domain
N
Linked to:
MAC bridge service profile or
9.3.24: Dot1ag MEP 9.3.20: Dot1ag 9.3.25: Dot1ag CFM 802.1p mapper service profile
CCM database maintenance stack
association
N
Points to:
9.3.23: Dot1ag MEP 9.3.22: Dot1ag MEP MAC bridge port config data
status or
802.1p mapper service profile
Linked to:
MAC bridge port config data or
9.3.29: multicast 802.1p mapper service profile
subscriber
monitor
9.3.28: multicast N 9.3.27: Multicast
Linked to: subscriber operations
MAC bridge port config data or config info profile
802.1p mapper service profile
G.988(12)_F9.3-1
2 0: MAC DAs
1: MAC source addresses
3..6 Reserved 0
ANI Tag operation Tag filtering Bridging Tag filtering Tag operation UNI
G.988(12)_F9.3.11-1
Figure 9.3.11-1
Attributes
Managed entity ID: This attribute uniquely identifies each instance of this ME. Through an
identical ID, this ME is implicitly linked to an instance of the MAC bridge port
configuration data ME. (R, set-by-create) (mandatory) (2 bytes)
VLAN filter list: This attribute is a list of provisioned tag control information (TCI) values
for the bridge port. A TCI, comprising user priority, canonical format indicator
(CFI) and virtual local area network identifier (VID), is represented by 2 bytes.
This attribute supports up to 12 VLAN entries. The first N are valid, where N
is given by the number of entries attribute. (R, W, set-by-create) (mandatory)
(24 bytes)
Forward operation: When a frame passes through the MAC bridge port, it is processed
according to the operation specified by this attribute, in accordance with
Table 9.3.11-1. Figure 9.3.11-3 illustrates the treatment of frames according to
the provisioned action possibilities. Tagged and untagged frames are treated
separately, but both in accordance with Figure 9.3.11-3. While all forwarding
operations are plausible, only actions 0x10 and 0x12 are necessary to construct
a VLAN mapper and an 802.1p mapper, respectively. (R, W, set-by-create)
(mandatory) (1 byte)
Length/
DA SA type MAC SDU
TPID TCI
User priority
802.1p CFI VID (802.1Q) – VLAN ID (tag)
(3 bits) (1 bit) (12 bits)
G.988(12)_F9.3.11-2
TCI: Tag control information
Functionality of
(extended) VLAN Only frames whose TCI does not match
tagging operation Action g:
DA match or flood P3
configuration data discard on TCI
MEs, if any
Only frames whose TCI matches
Action h:
Only frames whose TCI matches and accept on TCI, P4
else discard
(DA match or flooding)
G.988(12)_F9.3.11-3
31 30 29 28 27 26 25 24 15 14 13 12 11 10 9 8 7 6 5 4
23 22 21 20 19 18 17 16 3 2 1 0
Treatment Treatment
Pad (reserved) Treatment outer
Word 3 10 bits outer priority outer VID TPID/DEI
Treatment Treatment
Pad (reserved) Treatment inner
Word 4 12 bits inner priority inner VID TPID/DEI
G.988(12)_F9.3.13-1
Tags to remove
Action type
Ethertype
Priority
Priority
Priority
Priority
VID
VID
VID
VID
Untagged frames
Insert 1 full tag (X): 15 409 15 4096 0 0 15 N/A Px X
F X-F 6
Default case, do nothing 15 409 15 4096 0 0 15 N/A 15 N/A
6
Insert 2 tags (X,Y): 15 409 15 4096 0 0 Py Y Px X
F Y-X-F 6
Single tagged frames
Insert 1 full tag (X): 15 409 8 C 0 0 15 N/A Px X
C-F X-C-F 6
Insert 1 tag (X), copy priority: 15 409 8 C 0 0 15 N/A 8 X
C-F X-C-F 6
Insert 2 tags (X,Y): 15 409 8 C 0 0 Py Y Px X
C-F Y-X-C-F 6
Modify tag: 15 409 8 C 0 1 15 N/A Px X
C-F X-F 6
Modify tag, 15 409 8 C 0 1 15 N/A 8 X
keep original priority: 6
C-F X-F
Modify and insert tag: 15 409 8 C 0 1 Py Y Px X
C-F Y-X-F 6
Remove tag: 15 409 8 C 0 1 15 N/A 15 N/A
C-F F 6
Insert two tags: 15 409 8 C 0 0 Py Y Px X
C-F Y-X-C-F 6
Default case, do nothing 15 409 14 4096 0 0 15 N/A 15 N/A
6
Double tagged frames
Insert 1 tag (X): 8 S 8 C 0 0 15 N/A Px X
S-C-F X-S-C-F
Tags to remove
Action type
Ethertype
Priority
Priority
Priority
Priority
VID
VID
VID
VID
Insert 1 tag (X), 8 S 8 C 0 0 15 N/A 9 X
copy external priority:
S-C-F X-S-C-F
Insert 2 tags (X,Y): 8 S 8 C 0 0 Py Y Px X
S-C-F Y-X-S-C-F
Insert 2 tags (X,Y), copy 8 S 8 C 0 0 9 Y 8 X
external and internal priority:
S-C-F Y-X-S-C-F
Modify external tag: 8 S 8 C 0 1 15 N/A Px X
S-C-F X-C-F
Modify external tag, 8 S 8 C 0 1 15 N/A 9 X
keep original priority:
S-C-F X-C-F
Modify both tags: 8 S 8 C 0 2 Py Y Px X
S-C-F Y-X-F
Modify both tags, 8 S 8 C 0 2 9 Y 8 X
keep original priorities:
S-C-F Y-X-F
Swap both tags: 8 S 8 C 0 2 8 409 9 4097
S-C-F C-S-F 6
Remove outer tag: 8 S 8 C 0 1 15 N/A 15 N/A
S-C-F C-F
Remove both tags: 8 S 8 C 0 2 15 N/A 15 N/A
S-C-F F
Default case, do nothing 14 409 14 4096 0 0 15 N/A 15 N/A
S-C-F S-C-F 6
Table 9.3.13-2 illustrates the downstream behaviour for common deployment scenarios based on the
downstream mode code point and the upstream rule. For brevity, Table 9.3.13-2 omits a column for
P-bit only, but the downstream action can be inferred from the VID only column.
If the inner packet tag information is not available (i.e., in cases with more than one VID or
VID+PBIT value in "VID-only" and "Both P and VID," such as "X and C" and "Px and Py and X and
Y"), only outer tag information is used in the downstream filtering rule.
Tags to remove
Upstream action
Ethertype
type Priority
Priority
Priority
Priority
VID
VID
VID
VID
Consider Both P
VID only Action Notes
only and VID
Untagged frames
Insert 1 full tag (X): 15 4096 15 4096 0 0 15 N/A Px X Single X Px and X Strip tag
F X-F tagged
Default case, do 15 4096 15 4096 0 0 15 N/A 15 N/A Untagged – – Pass unmodified
nothing
Insert 2 tags (X,Y): F 15 4096 15 4096 0 0 Py Y Px X Double X and Y Px and Py Strip two tags
Y-X-F tagged and X
and Y
Single tagged
frames
Insert 1 full tag (X): 15 4096 8 C 0 0 15 N/A Px X Double X and C X and Px Strip outer tag
C-F X-C-F tagged and C
Insert 1 tag (X), copy 15 4096 8 C 0 0 15 N/A 8 X Double X and C X and C Strip outer tag,
priority: C-F X-C- tagged copy priority on
F to remaining tag
Insert 2 tags (X,Y): 15 4096 8 C 0 0 Py Y Px X Triple X and Y Px and Py Strip two outer
C-F Y-X-C-F tagged and C and X tags
and Y
and C
Modify tag: C-F 15 4096 8 C 0 1 15 N/A Px X Single X Px and X Replace X with Use treatment specified
X-F tagged C, retain Px in downstream mode
definition for the set {C}
if ambiguous
Tags to remove
Upstream action
Ethertype
type
Priority
Priority
Priority
Priority
VID
VID
VID
VID
Consider Both P
VID only Action Notes
only and VID
Modify tag, keep 15 4096 8 C 0 1 15 N/A 8 X Single X Px and X Replace X with Use treatment specified
original priority: C-F tagged C, retain Px in downstream mode
X-F definition for the set {C}
if ambiguous
Modify and insert 15 4096 8 C 0 1 Py Y Px X Double X and C X and Px Strip outer tag
tag: C-F Y-X-F tagged and C
Remove tag: C-F 15 4096 8 C 0 1 15 N/A 15 N/A Untagged C C Add tag, VID =
F C, P = 0
Insert two tags: C-F 15 4096 8 C 0 0 Py Y Px X Triple X and Y Px and Py Strip two outer
Y-X-C-F tagged and C and X tags
and Y
and C
Default case, do 15 4096 14 4096 0 0 15 N/A 15 N/A Single – – Pass unmodified
nothing tagged
Double tagged
frames
Insert 1 tag (X): S-C- 8 S 8 C 0 0 15 N/A Px X Triple X and S X and Px Strip outer tag
F X-S-C-F tagged and C and S and
C
Insert 1 tag (X), copy 8 S 8 C 0 0 15 N/A 9 X Triple X and S X and S Strip outer tag,
external priority: S- tagged and C and C copy priority on
C-F X-S-C-F to resulting
outer tag
Tags to remove
Upstream action
Ethertype
type
Priority
Priority
Priority
Priority
VID
VID
VID
VID
Consider Both P
VID only Action Notes
only and VID
Modify both tags: S- 8 S 8 C 0 2 Py Y Px X ≥2 tags X and Y Px and Py Modify tags Use treatment specified
C-F Y-X-F and X with S, C, retain in downstream mode
and Y priority definition for the sets
{S} {C} if ambiguous
Modify both tags, 8 S 8 C 0 2 9 Y 8 X ≥2 tags X and Y X and Y Modify tags Use treatment specified
keep original with Y, X, in downstream mode
priorities: S-C-F retain priority definition for the sets
Y-X-F {S} {C} if ambiguous
Swap both tags: S-C- 8 S 8 C 0 2 8 4096 9 4097 ≥2 tags S and C S and C Swap tags
F C-S-F
Tags to remove
Upstream action
Ethertype
type
Priority
Priority
Priority
Priority
VID
VID
VID
VID
Consider Both P
VID only Action Notes
only and VID
Remove outer tag: S- 8 S 8 C 0 1 15 N/A 15 N/A ≥2 tags S and C S and C Strip outer tag
C-F C-F
Remove both tags: S- 8 S 8 C 0 2 15 N/A 15 N/A ≥2 tags S and C S and C Strip both tags
C-F F
Default case, do 14 4096 14 4096 0 0 15 N/A 15 N/A ≥2 tags – – Pass unmodified
nothing S-C-F S-
C-F
Bit Interpretation
1 (LSB) Transmission period
0: once per second
1: once per minute
2..4 P-bit priority of transmitted ETH AIS frames
5..7 The maintenance level at which the client MEP exists
8 Reserved
[IEEE 802.1ag] defines the data structure for the linktrace database in detail,
but the definition is essentially the same as the LTR protocol data unit (PDU)
itself. The OMCI simply records the messages for parsing and analysis at the
OLT or the element management system (EMS).
If the ONU cannot allocate enough memory for the entire list, it keeps the most
recent responses and discards the older LTRs as necessary (first discarding
LTR1, then LTR2, etc.).
Notifications
Alarm
Alarm
Alarm Description
number
0 RDI CCM RDI received in CCM from peer MEP
1 MAC status Port or interface status failure at peer MEP
2 Remote CCM Loss of continuity with peer MEP
3 Error CCM Invalid CCMs received
4 Xcon CCM CCMs received from other MAs or a lower MD level
5 Unexpected period Unexpected period
6 AIS Ethernet AIS received
7..207 Reserved
208..223 Vendor-specific alarms Not to be standardized
The first 2 bytes of each row part is the table control field, which comprises a
key into the row, the row part identifier, and fields to define the result of a set
operation and to test whether the ONU supports the extended table format.
It is the responsibility of the OLT to assign and track row keys and content.
The ONU should deny set operations that create range overlaps.
Set ctrl
The two MSBs of this field determine the meaning of a set operation. These
bits are returned as 00 during get next operations.
Bits 16..15 Meaning
00 Reserved
01 Write this entry into the table. Overwrite any
existing entry with the same row part ID and row
key.
10 Delete this entry from the table, including all row
parts. The remaining fields are not meaningful.
Row part ID
The row part ID field distinguishes the row part associated with the current set
or get operation.
Row part 0 is backward compatible with earlier versions of this ME definition.
Row parts 1-2 are optional on a row by row basis. They can be set by using
values 001-010 as the row part ID. Row parts 3-7 are reserved.
Test
This bit allows the OLT to determine whether an ONU supports the extended
format access control list. If the ONU does not support the extended format, it
should be possible to set the test bit to 1 and read it back with a get and get
next operation. If the ONU does support the extended format, this bit should
always return the value 0 under a get next operation.
Row key
The row key distinguishes rows in the table.
Row part definition
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
Set ctrl Row part Rsv Row key
Row part
The row part field allows the table to contain logical rows that exceed the
maximum length of a single row. Table entries with the same row key and
different row parts are understood to comprise a single extended row. In this
ME, an extended row always contains two row parts.
The meaning of extended rows is defined as follows.
Rsv
This bit is reserved.
Row key
The row key identifies rows in the table. Row keys may be either densely or
sparsely populated.
Row part format definition
TCA disable: (2 bytes). Also clarified in Table 9.3.32-1, this field permits
TCAs to be inhibited, either individually or for the complete ME instance. As
with the accumulation disable field, the default value 0 enables TCAs, and
setting the global disable bit overrides the settings of the individual thresholds.
Unlike the accumulation disable field, the bits are mapped to the thresholds
While the IP stack is disabled, there is no IP connectivity to the external world from this ME instance.
While DHCP is disabled, the current values are always the same as the manual settings. While DHCP
is enabled, the current values are those assigned by DHCP, or undefined (0) if DHCP has never
assigned values.
IP address: The address used for IP host services; this attribute has the default value 0.
(R, W) (mandatory) (4 bytes)
Mask: The subnet mask for IP host services; this attribute has the default value 0.
(R, W) (mandatory) (4 bytes)
Gateway: The default gateway address used for IP host services; this attribute has the
default value 0. (R, W) (mandatory) (4 bytes)
Primary DNS: The address of the primary DNS server; this attribute has the default value 0.
(R, W) (mandatory) (4 bytes)
Secondary DNS: The address of the secondary DNS server; this attribute has the default value
0. (R, W) (mandatory) (4 bytes)
Current address: Current address of the IP host service. (R) (optional) (4 bytes)
Current mask: Current subnet mask for the IP host service. (R) (optional) (4 bytes)
Current gateway: Current default gateway address for the IP host service. (R) (optional)
(4 bytes)
Current primary DNS: Current primary DNS server address. (R) (optional) (4 bytes)
Current secondary DNS: Current secondary DNS server address. (R) (optional) (4 bytes)
Domain name: If DHCP indicates a domain name, it is presented here. If no domain name is
indicated, this attribute is set to a null string. If the string is shorter than
25 bytes, it must be null terminated. The default value is 25 null bytes. (R)
(mandatory) (25 bytes)
Host name: If DHCP indicates a host name, it is presented here. If no host name is
indicated, this attribute is set to a null string. If the string is shorter than
25 bytes, it must be null terminated. The default value is 25 null bytes. (R)
(mandatory) (25 bytes)
Relay agent options: This attribute is a pointer to a large string ME whose content specifies
one or more DHCP relay agent options. (R, W) (optional) (2 bytes)
While this ME instance is administratively locked, it provides no IPv6 connectivity to the external
world. Especially if manual provisioning is to be used, it is important that the ME remain locked until
provisioning is complete.
While autoconfiguration is disabled, the current values are the same as the manual settings. While
autoconfiguration is enabled, the current values are those autoconfigured on the basis of RAs,
assigned by DHCPv6, or undefined (empty tables) if no values have (yet) been assigned.
IPv6 link local address: The address used for on-link IP host services, such as RS and
DHCPv6. [b-IETF RFC 4862] specifies how to automatically establish a link-
local address. (R) (mandatory) (16 bytes)
IPv6 address: The manually provisioned IPv6 address used for routed IPv6 host services.
The address remains valid until reprovisioned, i.e., the preferred and valid
lifetimes of this address are infinite. The default value of this attribute is the
undefined address 0. (R, W) (mandatory) (16 bytes)
Default router: The manually provisioned IPv6 address of the default router. The default
value of this attribute is the undefined address 0. (R, W) (mandatory)
(16 bytes)
Primary DNS: The manually provisioned IPv6 address of the primary DNS server. The
default value of this attribute is the undefined address 0. (R, W) (mandatory)
(16 bytes)
Secondary DNS: The manually provisioned IPv6 address of the secondary DNS server. The
default value of this attribute is the undefined address 0. (R, W) (mandatory)
(16 bytes)
Current address table: This attribute is a list of the current IPv6 addresses of the IP host
service. The link-local address does not appear in this table. Each row of the
table is structured as follows.
IP address (16 bytes)
Preferred lifetime remaining, seconds (4 bytes)
Valid lifetime remaining, seconds (4 bytes)
If the manually provisioned IPv6 address attribute appears as the (only, by
necessity) entry of the table, its preferred and valid lifetimes are infinite
(0xFFFF FFFF).
(R) (mandatory) (24N bytes)
Current default router table: This attribute lists the IPv6 addresses of the current default
routers. (R) (mandatory) (16N bytes)
Current DNS table: This attribute lists the IPv6 addresses of the current DNS servers. (R)
(mandatory) (16N bytes)
ONU
PON
PHY
Ethernet UNI
transceiver
Loopback 3
G.988(12)_F9.5.1-1
Alarm
Alarm
Alarm Description
number
0 LAN-LOS No carrier at the Ethernet UNI
1..207 Reserved
208..223 Vendor-specific alarms Not to be standardized
Alarm
Alarm Alarm Description
number
0 Connecting function fail Indicates a failure of the connecting function. May be used to
signal faults from the non-OMCI management domain into
the OMCI.
1..207 Reserved
208..223 Vendor-specific alarms Not to be standardized
9.7.3: xDSL line config 9.7.12: xDSL line 9.7.21: xDSL xTU-C
profile part 1 inventory and PM history data
9.7.4: Part 2 N status data part 1
9.7.5: Part 3 9.7.13: Part 2
9.7.6: VDSL2 line config 9.7.14: Part 3
9.7.22: xDSL xTU-R
extensions 9.7.15: Part 4
9.7.16: VDSL2 line PM history data
9.7.26: VDSL2 line config
extensions 2 inventory and
status data part 1
9.7.17: Part 2 u 9.7.23: xDSL xTU-C
9.7.18: Part 3 channel PM
9.7.10: xDSL PSD mask N history data
profile
____________________
1 The xDSL MEs include the ITU-T G.992 family as well as ITU-T G.993.2 VDSL2, but not ITU-T G.993.1 VDSL.
Alarm
Alarm
Alarm Description
number
0 NE LOF Near-end loss of frame
1 NE LOS Near-end loss of signal
2 NE LOL Near-end loss of link
3 NE LPR Near-end loss of power
4 Card alm Card in alarm
5 FE LOF Far-end loss of frame
6 FE LOS Far-end loss of signal
7 FE LOL Far-end loss of link
8 FE LPR Far-end loss of power
998ADE
998 998-M2x 997-M1x 997-M1c 997-M2x HPE-M1 998-B 998-CO
Bit
Annex A Annex B -M2x Annex B Annex B Annex B Annex B Annex C Annex C
Annex B
Octet 1, profile class 8
1 D-32 M2x-A M2x-A M1c-A-7 POTS- POTS-
138b 138co
2 D-48 M2x-B M2x-B TCM- POTS-
ISDN 276co
3 M2x-M M2x-M M1x-M POTS-
276b
4 M2x- M2x-
NUS0 NUS0
5
6
7
8
Octet 2, profile class 8
1 D-64
2 D-128
3
4
5
6
7
8
Octet 3, profile class 12
1 D-32 M2x-A M2x-A POTS- POTS-
138b 138co
2 D-48 M2x-B M2x-B TCM- POTS-
ISDN 276co
3 M2x-M M2x-M M1x-M POTS-
276b
4 M2x- M2x-
NUS0 NUS0
5
6
7
8
Octet 4, profile class 12
1 D-64
2 D-128
3
4
5
6
7
8
Octet 5, profile class 17
998ADE
998 998-M2x 997-M1x 997-M1c 997-M2x HPE-M1 998-B 998-CO
Bit
Annex A Annex B -M2x Annex B Annex B Annex B Annex B Annex C Annex C
Annex B
1 D-32 E17- ADE17- E17- 17-M1- POTS-
M2x- M2x-A M2x- NUS0 138b
NUS0 NUS0
2 D-48 E17- ADE17- TCM-
M2x- M2x-B ISDN
NUS0-M
3 E17- ADE17- POTS-
M2x-A M2x- 276b
NUS0-M
4 ADE17-
M2x-M
5
6
7
8
Octet 6, profile class 17
1 D-64
2 D-128
3
4
5
6
7
8
Octet 7, profile class 30
1 D-32 E30- ADE30- E30- 30-M1- POTS-
M2x- M2x- M2x- NUS0 138b
NUS0 NUS0-A NUS0
2 D-48 E30- ADE30- 1230-M1- TCM-
M2x- M2x- NUS0 ISDN
NUS0-M NUS0-M
3 HPEADE 1730-M1- POTS-
1230- NUS0 276b
NUS0
4 HPEADE
1730-
NUS0
5
6
7
8
998ADE
998 998-M2x 997-M1x 997-M1c 997-M2x HPE-M1 998-B 998-CO
Bit
Annex A Annex B -M2x Annex B Annex B Annex B Annex B Annex C Annex C
Annex B
Octet 8, profile class 30
1 D-64
2 D-128
3
4
5
6
7
8
NOTE – All unassigned bits are reserved.
NOTE – Some entries in this table have been modified relative to earlier versions of this Recommendation.
See [ITU-T G.997.1] for details.
Year 2 bytes
Month 1 byte (1..12)
Day 1 byte (1..31)
Hour 1 byte (0..23)
Minute 1 byte (0..59)
Second 1 byte (0..59)
(R) (optional) (7 bytes)
Date/time-stamping of far-end test parameters (STAMP-TEST-FE): This parameter
indicates the date/time when the far-end test parameters that can change during
showtime were last updated. See clause 7.5.1.36.4 of [ITU-T G.997.1]. The
format of this parameter is the same as STAMP-TEST-NE. (R) (optional)
(7 bytes)
Date/time-stamping of last successful downstream OLR operation (STAMP-OLR-ds):
This parameter indicates the date/time of the last successful OLR execution in
the downstream direction that has modified the bits or gains. See
clause 7.5.1.37.1 of [ITU-T G.997.1]. The format of this parameter is the same
as STAMP-TEST-NE. (R) (optional) (7 bytes)
Date/time-stamping of last successful upstream OLR operation (STAMP-OLR-us): This
parameter indicates the date/time of the last successful OLR execution in the
upstream direction that has modified the bits or gains. See clause 7.5.1.37.2 of
[ITU-T G.997.1]. The format of this parameter is the same as STAMP-TEST-
NE. (R) (optional) (7 bytes)
Actions
Get, get next
Notifications
None.
9.7.38 VDSL2 line inventory and status data part 4
This ME extends the other xDSL line inventory and status data MEs with attributes specific to
VDSL2.
ONU
PON
PHY PON
CES UNI
framer interface
Loopback 2 Loopback 1
Loopback 3 G.988(12)_F9.8.1-1
In the event of conflicting values between this attribute and the (also optional)
line length attribute, the line length attribute is taken to be valid. This permits
the separation of line build-out (LBO) and power settings from smart jack and
Alarms should be declared and cleared according to criteria defined separately in existing
TDM standards.
Alarm
Alarm Alarm Description
number
0 TF Transmitter failure
1 LOS Loss of signal
2 LOF Loss of frame
3 OOF Out of frame
4 RAI Remote alarm indication
5 1.5 M BAIS 1.544 Mbit/s back alarm indication signal
Bit
Byte 8 (MSB) 7 6 5 4 3 2 1
1 TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7
2 TS 8 TS 9 TS 10 TS 11 TS 12 TS 13 TS 14 TS 15
...
12 TS 88 TS 89 TS 90 TS 91 TS 92 TS 93 TS 94 TS 95
Actions
Create, delete, get, set
Get current data (optional)
Notifications
Threshold crossing alert
Alarm
Threshold crossing alert Threshold value attribute No. (Note)
number
0 ES 1
1 SES 2
2 BES 3
3 UAS 4
4 CSS 5
5 LOSS-L 6
6 AISS-P 7
7 ES-P 8
Alarm criteria may be customized through reference to a pseudowire maintenance profile managed
object, or defined by the ONU's internal defaults.
Actions
Create, delete, get, set
Get current data (optional)
Notifications
Threshold crossing alert
Alarm
Threshold crossing alert Threshold value attribute No. (Note)
number
0 ES-LFE 1
1 CV-PFE 2
2 ES-PFE 3
3 ESA-PFE 4
4 ESB-PFE 5
5 SES-PFE 6
6 SEFS-PFE 7
7 UAS-PFE 8
8 CSS-PFE 9
NOTE – This number associates the TCA with the specified threshold value attribute of the
threshold data 1/2 managed entities.
Actions
Create, delete, get, set
Get current data (optional)
Notifications
Threshold crossing alert
Alarm
Threshold crossing alert Threshold value attribute No. (Note)
number
0 AISSCI-P 1
1 ES-NP 2
2 SES-NP 3
3 UAS-NP 4
4 ES-NPFE 5
5 SES-NPFE 6
6 UAS-NPFE 7
NOTE – This number associates the TCA with the specified threshold value attribute of the
threshold data 1 managed entity.
Points to:
VoIP voice SIP user Authentication security
CTP data method
9.9.4 9.9.2
Large string (AoR)
Network address
N N N
MGC
configuration G.988(12)_F9.9-1
portal
9.9.20
Transmission path: This attribute allows setting the POTS UNI either to full-time on-hook
transmission (0) or part-time on-hook transmission (1). Upon ME instantiation,
the ONU sets this attribute to 0. (R, W) (optional) (1 byte)
Rx gain: This attribute specifies a gain value for the received signal in the form of a 2s
complement number. Valid values are –120 (12.0 dB) to 60 (+6.0 dB). The
direction of the affected signal is in the D to A direction, towards the telephone
set. Upon ME instantiation, the ONU sets this attribute to 0. (R, W) (optional)
(1 byte)
Tx gain: This attribute specifies a gain value for the transmit signal in the form of a 2s
complement number. Valid values are –120 (12.0 dB) to 60 (+6.0 dB). The
direction of the affected signal is in the A to D direction, away from the
telephone set. Upon ME instantiation, the ONU sets this attribute to 0. (R, W)
(optional) (1 byte)
Operational state: This attribute indicates whether the ME is capable of performing its
function. Valid values are enabled (0) and disabled (1). (R) (optional) (1 byte)
Hook state: This attribute indicates the current state of the subscriber line: 0 = on hook, 1 =
off hook (R) (optional) (1 byte)
POTS holdover time: This attribute determines the time during which the POTS loop voltage
is held up when a LOS or softswitch connectivity is detected (please refer to
the following table for description of behaviours).. After the specified time
elapses, the ONU drops the loop voltage, and may thereby cause premises
intrusion alarm or fire panel circuits to go active. When the ONU ranges
successfully on the PON or softswitch connectivity is restored, it restores the
POTS loop voltage immediately and resets the timer to zero. The attribute is
expressed in seconds. The default value 0 selects the vendor's factory policy.
(R, W) (optional) (2 bytes)
Alarm
Alarm Alarm Description
number
0 SIP UA register name Failed to resolve the registration server name
1 SIP UA register reach Cannot reach a registration server (the port cannot be
reached, ICMP errors)
2 SIP UA register connect Cannot connect to a registration server (due to bad
credentials or other faults after the port has responded)
3 SIP UA register validate Cannot validate a registration server
4 (Note) SIP UA register auth Cannot authenticate a registration session (e.g., missing
credentials)
5 (Note) SIP UA register timeout Timeout waiting for response from a registration server
6 (Note) SIP UA register fail Failure response received from a registration server
7..207 Reserved
208..223 Vendor-specific alarms Not to be standardized
NOTE – These alarms are deprecated, and retained for backward compatibility. It is recommended
that the SIP agent config data not declare these alarms, but that they be declared by the SIP user
data ME instead. In any event, only one ME should declare the alarm, not both.
Clock
Value Encoding name
rate (Hz)
0 PCMU 8000
1 reserved
2 reserved
3 GSM 8000
4 ITU-T G.723 8000
5 DVI4 8000
6 DVI4 16000
7 LPC 8000
8 PCMA 8000
9 ITU-T G.722 8000
10 L16, 2 channels 44100
11 L16, 1 channel 44100
12 QCELP 8000
13 CN 8000
14 MPA 90000
15 ITU-T G.728 8000
16 DVI4 11025
17 DVI4 22050
18 ITU-T G.729 8000
(R, W, set-by-create) (mandatory) (1 byte)
Packet period selection (1st order): This attribute specifies the packet period selection
interval in milliseconds. The recommended default value is 10 ms. Valid
values are 10..30 ms. (R, W, set-by-create) (mandatory) (1 byte)
Silence suppression (1st order): This attribute specifies whether silence suppression is on or
off. Valid values are 0 = off and 1 = on. (R, W, set-by-create) (mandatory)
(1 byte)
Three more groups of three attributes are defined, with definitions identical to the preceding three:
Codec selection (2nd order): (R, W, set-by-create) (mandatory) (1 byte)
Packet period selection (2nd order): (R, W, set-by-create) (mandatory) (1 byte)
Silence suppression (2nd order): (R, W, set-by-create) (mandatory) (1 byte)
Codec selection (3rd order): (R, W, set-by-create) (mandatory) (1 byte)
Packet period selection (3rd order): (R, W, set-by-create) (mandatory) (1 byte)
Silence suppression (3rd order): (R, W, set-by-create) (mandatory) (1 byte)
OOB DTMF: This attribute specifies out-of-band DMTF carriage. When enabled (1), DTMF
signals are carried out of band via RTP or the associated signalling protocol.
When disabled (0), DTMF tones are carried in the PCM stream. (R, W,
set-by-create) (mandatory) (1 byte)
RTP profile pointer: This attribute points to the associated RTP profile data ME. (R, W,
set-by-create) (mandatory) (2 bytes)
Actions
Create, delete, get, set
Notifications
None.
9.9.6 Voice service profile
This ME organizes data that describe the voice service functions of the ONU. Instances of this ME
are created and deleted by the OLT.
Relationships
An instance of this ME may be associated with zero or more instances of a VoIP voice CTP
by way of a VoIP media profile.
Attributes
Managed entity ID: This attribute uniquely identifies each instance of this ME. (R,
set-by-create) (mandatory) (2 bytes)
Announcement type: This attribute specifies the treatment when a subscriber goes off hook
but does not attempt a call within the dial-tone timeout interval. Valid values
include the following.
0x01 Silence
0x02 Reorder tone
0x03 Fast busy
0x04 Voice announcement
0xFF Not specified; ONU is free to make its own choice.
(R, W, set-by-create) (mandatory) (1 byte)
Jitter target: This attribute specifies the target value of the jitter buffer in milliseconds. The
system tries to maintain the jitter buffer at the target value. The value 0
specifies dynamic jitter buffer sizing. (R, W, set-by-create) (optional) (2 bytes)
Jitter buffer max: This attribute specifies the maximum depth of the jitter buffer associated
with this service in milliseconds. The value 0 specifies that the ONU uses its
internal default. (R, W, set-by-create) (optional) (2 bytes)
Echo cancel ind: The Boolean value true specifies that echo cancellation is on; false specifies
off. (R, W, set-by-create) (mandatory) (1 byte)
PSTN protocol variant: This attribute controls which variant of POTS signalling is used on
the associated UNIs. Its value is equal to the [ITU-T E.164] country code. The
Alarm
Alarm
Alarm Description
number
0 VCD config server name Failed to resolve the configuration server name.
1 VCD config server reach Cannot reach configuration server (the port cannot be
reached, ICMP errors)
2 VCD config server connect Cannot connect to the configuration server (due to bad
credentials or other faults after the port has responded)
3 VCD config server validate Cannot validate the configuration server
4 VCD config server auth Cannot authenticate the configuration session (e.g.,
missing credentials)
G.988(12)_F9.10-1
ONU
PON
PHY
MoCA UNI
transceiver
Loopback 3
G.988(12)_F9.10.1-1
Alarm
Alarm number Alarm Description
0 MoCA LOL Loss of link at the MoCA interface
1 MoCA limited link (LL) Bandwidth of link between two nodes on the
MoCA network is less than the specified value
2..207 Reserved
208..223 Vendor-specific alarms Not to be standardized
Number of parts 3
Part 1 sftp://myusername:mypassw
Part 2 ord@config.telecom.com:12
Or
Number of parts 3
Part 1 sftp://myusername:mypassw
Part 2 ord@config.telecom.com:12
Part 3 34/path/to/longfilename<null>
Instances of this ME are created and deleted by the OLT. Under some circumstances, they may also
be created by the ONU. To use this ME, the OLT or ONU instantiates the large string ME and then
points to the created ME from other ME instances. Systems that maintain the large string should
ensure that the large string ME is not deleted while it is still linked.
Relationships
An instance of this ME may be cited by any ME that requires a text string longer than 25 bytes.
Attributes
Managed entity ID: This attribute uniquely identifies each instance of this ME. The value
0xFFFF is reserved. When the large string is to be used as an IPv6 address, the
value 0 is also reserved. The OLT should create large string MEs starting at 1
(or 0), and numbering upwards. The ONU should create large string MEs
starting at 65534 (0xFFFE) and numbering downwards. (R, set-by-create)
(mandatory) (2 bytes)
Number of parts: This attribute specifies the number of non-empty parts that form the large
string. This attribute defaults to 0 to indicate no large string content is
defined.(R, W) (mandatory) (1 byte)
Fifteen additional attributes are defined in the following; they are identical. The large string is simply
divided into as many parts as necessary, starting at part 1. If the end of the string does not lie at a part
boundary, it is marked with a null byte.
Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, Part 9,
Part 10, Part 11, Part 12, Part 13, Part 14, Part 15: (R, W) (mandatory)
(25 bytes * 15 attributes)
Actions
Create, delete, get, set
Notifications
Attribute value change
Number Attribute value change Description
1 Number of parts
2 Part 1
3 Part 2
4 Part 3
5 Part 4
6 Part 5
7 Part 6
8 Part 7
9 Part 8
Bits Usage
1 (LSB) Leap61
2 Leap59
3 currentUtcOffsetValid
4 PTP timescale
5 Time traceable
6 Frequency traceable
7 Reserved
8 (MSB) Reserved
currentUtcOffset: Provides the UTC offset value between the TAI and UTC timescales
(UTC Offset = TAI – UTC), as specified in clause 7.2.3 of [IEEE 1588].
(R, W) (mandatory) (2 bytes)
Priority1: As specified in clause 7.6.2.2 of [IEEE 1588]. (R, W) (mandatory) (1 byte)
clockClass: Provides the clockClass information denoting the traceability of the time
distributed by the grandmaster clock, as specified in clause 7.6.2.4 of
[IEEE 1588]. (R, W) (mandatory) (1 byte)
Accuracy: Indicates the expected accuracy of a clock when it is the grandmaster, as
specified in clause 7.6.2.5 of [IEEE 1588]. (R, W) (mandatory) (1 byte)
offsetScaledLogVariance: Provides the estimate of the time variance, as specified in
clause 7.6.3 of [IEEE 1588]. (R, W) (mandatory) (2 bytes)
Priority2: As specified in clause 7.6.2.3 of [IEEE 1588]. (R, W) (mandatory) (1 byte)
Alarm
Alarm Alarm Description
number
0 Video-LOS No signal at the video UNI
1 Video-OOR-low RF output below rated value
2 Video-OOR-high RF output above rated value
3..207 Reserved Reserved for vendor-specific alarms
208..223 Vendor-specific alarms Not to be standardized
ONU
PON
ATM Ethernet over GEM
xDSL UNI interworking
Alarm
Alarm
Alarm Description
number
0 End-to-end VC AIS layer End-to-end VC-AIS receiving indication (optional)
management indication
receiving (LMIR)
1 End-to-end VC RDI LMIR End-to-end VC-RDI receiving indication (optional)
2 End-to-end VC AIS layer End-to-end VC-AIS generation indication (optional)
management indication
generation (LMIG)
3 End-to-end VC RDI LMIG End-to-end VC-RDI generation indication (optional)
4 Segment loss of continuity Loss of continuity detected when the interworking
VCC termination point is a segment end point
(optional)
5 End-to-end loss of continuity Loss of continuity detected at the interworking VCC
termination point (optional)
6 CSA Cell starvation alarm
7..207 Reserved
208..223 Vendor-specific alarms Not to be standardized
Supplementary information
This ME contains the facilities to perform a conventional three step hash-based authentication
sequence found in [ISO/IEC 9798-4] (used in DSL systems that employ MS-CHAPv2 and elsewhere)
using get and set messages.
The logical structure of the conventional three step sequence is as follows. In the present situation,
peer 1 is the OLT and peer 2 is the ONU.
Message 1: (Peer 1 peer 2) my_cryptographic_capabilities | random_challenge_1
Get_response [ ]
G.988(10)_F9.13.11-1
S0 - complete
OLT sets OLT crypto
capabilities and/or OLT
random challenge table
OLT sets OLT
result status
S1 - OLT
challenge
pending
G.988(12)_F9.13.11-2
ONU
UNI R/S
ODN: optical OTL: optical
Mid-span
distribution trunk line OLT
network extender
S'/R' R'/S' S/R SNI
ONU
G.988(12)_F9.14-1
UNI R/S
[ITU-T G.984.6] defines a mid-span PON RE. An RE may extend more than one PON, using optical
amplification (OA) or optical-electrical-optical (OEO) regeneration technology. For easy reference,
Figure 9.14-1 illustrates the interface designations.
The RE model includes one built-in ONU, which serves for management of the RE itself, as well as
for optional subscriber or craft UNIs. The ONU embedded within the RE is therefore able to use any
of the MEs defined elsewhere in this Recommendation, including the ANI-G and T-CONT MEs,
which represent the built-in ONU's individual uplink.
NOTE 1 – Although the built-in management ONU is physically contained within physical RE equipment, the
management model perspective is that the ONU software controls the entire equipment. In terms of the model,
therefore, the management ONU contains the RE equipment and functionality.
This clause defines additional MEs that pertain to the RE function separately.
The current scope of the RE model includes the use of either OEO regeneration or OA in the upstream
and downstream directions, independently. Split ratio enhancement (more than one RE UNI for every
RE ANI) is also included. This results in eight possible arrangements, are listed in the following
tables.
NOTE 2 – Each amplifier ME is associated with an RE common amplifier parameters ME.
Internal
Downstream Upstream
optical Model
technology technology
split
OEO OEO 1:1 One PPTP RE UNI pointing to one RE ANI-G, all
attributes active
OEO OEO 1:N N PPTP RE UNIs pointing to one RE ANI-G, all
attributes active
OA OA 1:1 One RE upstream amplifier pointing to one RE
downstream amplifier
OA OA 1:N N RE upstream amplifiers pointing to one RE
downstream amplifier
9.14.1 RE ANI-G
This ME organizes data associated with each R'/S' physical interface of an RE if the RE supports
OEO regeneration in either direction. The management ONU automatically creates one instance of
this ME for each R'/S' physical port (uni- or bidirectional) as follows.
• When the RE has mid-span PON RE ANI interface ports built into its factory
configuration.
• When a cardholder is provisioned to expect a circuit pack of the mid-span PON RE ANI type.
• When a cardholder provisioned for plug-and-play is equipped with a circuit pack of the
mid-span PON RE ANI type. Note that the installation of a plug-and-play card may indicate
the presence of a mid-span PON RE ANI port via equipment ID as well as its type attribute,
and indeed may cause the management ONU to instantiate a port-mapping package to specify
the ports precisely.
The management ONU automatically deletes instances of this ME when a cardholder is neither
provisioned to expect a mid-span PON RE ANI circuit pack, nor is it equipped with a mid-span PON
RE ANI circuit pack.
As illustrated in Figure 8.2.10-4, an RE ANI-G may share the physical port with an RE downstream
amplifier. The ONU declares a shared configuration through the port-mapping package combined
port table, whose structure defines one ME as the master. It is recommended that the RE ANI-G be
the master, with the RE downstream amplifier as a secondary ME.
The administrative state, operational state and ARC attributes of the master ME override similar
attributes in secondary MEs associated with the same port. In the secondary ME, these attributes are
present, but cause no action when written and have undefined values when read. The RE downstream
amplifier should use its provisionable downstream alarm thresholds and should declare downstream
alarms as necessary; other isomorphic alarms should be declared by the RE ANI-G. The test action
should be addressed to the master ME.
Relationships
An instance of this ME is associated with each R'/S' physical interface of an RE that includes
OEO regeneration in either direction, and with one or more instances of the PPTP RE UNI. It
may also be associated with an RE downstream amplifier.
Alarm
Alarm
Alarm Description
number
0 Low received optical power Received downstream optical power below threshold
1 High received optical power Received downstream optical power above threshold
2 Low transmit optical power Transmitted upstream optical power below lower threshold
3 High transmit optical power Transmitted upstream optical power above upper threshold
4 High laser bias current Laser bias current above threshold determined by vendor;
laser end of life pending
5..207 Reserved
208..223 Vendor-specific alarms Not to be standardized
Test result: The RE may report a test result autonomously if it performs self-test
functions autonomously.
9.14.2 Physical path termination point RE UNI
This ME represents an S'/R' interface in a mid-span PON RE that supports OEO regeneration in at
least one direction, where physical paths terminate and physical path level functions are performed
(transmit or receive).
Such an RE automatically creates an instance of this ME for each S'/R' interface port as follows.
• When the RE has mid-span PON RE UNI interface ports built into its factory configuration.
• When a cardholder is provisioned to expect a circuit pack of the mid-span PON RE UNI type.
• When a cardholder provisioned for plug-and-play is equipped with a circuit pack of the
mid-span PON RE UNI type. Note that the installation of a plug-and-play card may indicate
the presence of a mid-span PON RE UNI port via equipment ID as well as its type attribute,
and indeed may cause the management ONU to instantiate a port-mapping package to specify
the ports precisely.
The management ONU automatically deletes instances of this ME when a cardholder is neither
provisioned to expect a mid-span PON RE UNI circuit pack, nor is it equipped with a mid-span PON
RE UNI circuit pack.
As illustrated in Figure 8.2.10-3, a PPTP RE UNI may share the physical port with an RE upstream
amplifier. The ONU declares a shared configuration through the port-mapping package combined
port table, whose structure defines one ME as the master. It is recommended that the PPTP RE UNI
be the master, with the RE upstream amplifier as a secondary ME.
The administrative state, operational state and ARC attributes of the master ME override similar
attributes in secondary MEs associated with the same port. In the secondary ME, these attributes are
present, but cause no action when written and have undefined values when read. The RE upstream
amplifier should use its provisionable upstream alarm thresholds and should declare upstream alarms
Alarm
Alarm
Alarm Description
number
0 Low received optical power Received upstream optical power of one or more
ONUs below threshold
1 High received optical power Received upstream optical power of one or more
ONUs above threshold
2 Low transmit optical power Transmit downstream optical power below lower
threshold
3 High transmit optical power Transmit downstream optical power above upper
threshold
4 High laser bias current Laser bias current above threshold determined by
vendor; laser end of life pending
5 S'/R' LOS S'/R' LOS detected. No optical signal received at
the S'/R' upstream interface in 500 µs
6..207 Reserved
208..223 Vendor-specific alarms Not to be standardized
Alarm
Alarm
Alarm Description
number
0 Low received optical power Received downstream optical power below threshold
1 High received optical power Received downstream optical power above threshold
2 Low transmit optical power Transmit downstream optical power below lower threshold
3 High transmit optical power Transmit downstream optical power above upper threshold
4 High laser bias current Laser bias current above threshold determined by vendor;
laser end of life pending
5..207 Reserved
208..223 Vendor-specific alarms Not to be standardized
Test result: The RE may report a test result autonomously if it performs self-test
functions autonomously.
9.14.5 RE config portal
The RE config portal ME provides a way for the OLT to discover the configuration delivered to an
RE by a non-OMCI configuration method (SNMP, etc.). Text retrieved from this ME is not required
to be understood by the OLT or EMS, but it may be useful for human or vendor-specific analysis
tools.
An instance of this ME may be created by an RE that supports non-OMCI RE configuration. It is not
reported during an MIB upload.
NOTE – This number associates the TCA with the specified threshold value attribute of the threshold data
64 bit managed entity.
Notifications
Threshold crossing alert
Alarm Threshold value
Threshold crossing alert
number attribute No. (Note)
0 Unsatisfied Adjust_Tx_Wavelength requests 1
NOTE – This number associates the TCA with the specified threshold value attribute of the threshold data
1/2 managed entities.
G.988(12)_F11.1-1
If a G-PON OLT has a priori knowledge that the ONU supports the extended message set, it may
choose to omit the query step. However, a G-PON ONU may not transmit extended messages,
including autonomous notifications, until it has received at least one extended message from the OLT
during the current session (since initialization or re-activation on the PON).
Table 11.2-2 shows the extended message format. The packet has variable length N, up to 1980 bytes.
Bit
8 7 6 5 1
0 AR AK MT
Extended messages are limited by the total size of the PDU, and there is no possibility that a get or
set or create message, even with a maximum number (16) of maximum length (25 byte) attributes,
can exceed the message size limit. For backward compatibility, attribute definitions remain within
the size limits of baseline messages, but a single extended message may contain more attributes than
a baseline message.
A.1 General
A.1.1 Result and reason
Responses to commands can indicate the result of the command. A zero value indicates that the
command was processed successfully. Non-zero values indicate the reason for the failure. If the result
was failure, the rest of the message contents may provide details of the failure, may be filled with all
0, or in the extended message set, may simply be omitted. The definition of each result and reason
appears in Table A.1.1-1.
NOTE –The number of get next commands, k + 1,is derived by the OLT to retrieve the complete table. For baseline OMCI
messages, each get next response contains 29 bytes; for extended OMCI messages, up to 1966 bytes (1980 maximum PDU
size – 14 bytes of OMCI header) are returned in a full-length response.
The OLT issues as many get next requests as are needed to accommodate the size of the table attribute.
As illustrated in Figure A.1.2-2, the ONU returns a parameter error response if the OLT overruns the
size of the table attribute copy.
OLT ONU
Get (ME (table attribute))
Get response (table attribute size)
Get next (ME (table attribute, sequence = 0))
Get next response (first N bytes of table)
Get next (ME (table attribute, sequence = k))
Get next response (final M bytes of table)
G.988(12)_FA.1.2-2
Bit
Byte
8 7 6 5 4 3 2 1
1 Attribute 1 Attribute 2 Attribute 3 Attribute 4 Attribute 5 Attribute 6 Attribute 7 Attribute 8
2 Attribute 9 Attribute 10 Attribute 11 Attribute 12 Attribute 13 Attribute 14 Attribute 15 Attribute 16
Attribute numbers correspond to the ordering of the attributes in clause 9. The ME identifier, which
is an attribute of each ME, has no corresponding bit in the attribute mask. Thus, attributes are counted
starting from the first attribute after the ME identifier.
A.1.4 Alarm notifications
The ONU sends this notification each time an alarm status changes for the entity indicated in the ME
identifier message field. The message shows the status of all alarms of this entity. It is up to the OLT
to determine which alarm status has changed. The alarm message also reports declarations and
cancellations of PM TCAs.
The maximum number of alarms supported by the OMCI for a given ME instance is 224, because of
the available message field of the baseline get all alarm next message. The bit map is composed as
follows.
Bit
Byte
8 7 6 5 4 3 2 1
1 Alarm 0 Alarm 1 Alarm 2 Alarm 3 Alarm 4 Alarm 5 Alarm 6 Alarm 7
2 Alarm 8 Alarm 9 Alarm 10 Alarm 11 Alarm 12 Alarm 13 Alarm 14 Alarm 15
…
28 Alarm 216 Alarm 217 Alarm 218 Alarm 219 Alarm 220 Alarm 221 Alarm 222 Alarm 223
Alarm numbers correspond to the alarm coding or threshold coding in clause 9 (no ME class declares
both alarms and TCAs). Bits in the alarm bit map that correspond to non-existing alarms are always
set to 0. Bits that correspond to defined alarms are set to 0 to indicate that the corresponding alarm is
cleared or to 1 to indicate that the alarm is currently active.
OLT ONU
Figure A.1.4.1-1 – Increment of alarm sequence number at the ONU and OLT
OLT ONU
When alarms are suppressed by ARC (clause A.1.4.3), the alarm is recorded by the ONU, but no
alarm message is sent. Therefore, the alarm sequence number is not incremented.
G.988(12)_FA.1.4.1-3
Figure A.1.4.1-3 – No increment of alarm sequence number at the ONU and OLT under ARC
A.1.4.2 Alarm audit and resynchronization
At initialization, periodically or when the OLT detects a gap in the alarm sequence number, it
reconciles its view of the ONU's alarm status by sending a get all alarms command targeted at the
ONU data ME, as shown in Figure A.1.4.2-1.
When it receives the get all alarms request, the ONU resets the alarm sequence number to zero.
If the OLT sets the alarm retrieval mode indicator in the get all alarms command to 1, the ONU only
returns alarms that are not currently under ARC. Otherwise, the ONU returns all alarms regardless of
ARC status. In accordance with this request option, the ONU creates a copy of its current alarm status
table. ME instances with no reportable alarms are not represented in this copy.
The ONU responds to the OLT with the number of get all alarms next commands required to retrieve
the alarm status table copy (baseline message set) or the number of ME instances to be retrieved
(extended message set). These are in fact the same value because each baseline message returns the
alarm mask from one ME instance. The OLT then uploads the copy via a sequence of get all alarms
next commands targeted at the ONU data ME.
During the upload, the ONU is permitted to issue alarm notifications, both to declare and to clear
alarms.
When the upload is complete, the OLT compares the received alarm statuses with its own alarm table
entries for that ONU, along with any alarm notifications received during the upload process, and
notifies the network manager of any changes.
Get all alarms next response (ONU data (partial alarms snapshot, 0))
...
Get all alarms next response (ONU data (partial alarms snapshot, N-1))
The OLT reconciles the newly uploaded snapshot One minute after the last get all alarms next
with its previous alarm state information command, the ONU discards alarms snapshot.
and with any newly received alarm notifications.
G.988(12)_FA.1.4.2-1
The ONU allows 1 min between two get all alarms next requests. If the OLT does not send a get all
alarms next request within this time after the previous get all alarms next request or after the get all
alarms request, the ONU assumes the alarm upload to be terminated. It then discards the copy of the
alarm table and considers any further get all alarms next requests to be out of range.
A.1.4.3 Alarm-reporting control
ARC allows for the suppression of alarms from PPTPs and cardholders, under the control of the
management system. ARC suppresses alarm-reporting on the parent ME and all dependent entities,
but does not suppress alarm conditions themselves. Therefore, if an alarm condition develops during
an ARC interval, the ONU should maintain the internal indication of the alarm, and if the OLT gets
all alarms regardless of ARC, it should be reported.
[ITU-T M.3100] completely describes ARC from a generic viewpoint. The OMCI provides for ARC
functions using two attributes of the parent ME: ARC and ARC interval. These two attributes are
described below.
Alarm-reporting control
This attribute allows the activation of ARC for this PPTP or cardholder. The attribute works in concert
with the ARC interval attribute. The value 0 disables ARC, while the value 1 enables ARC. The
default value is disabled. When the ARC attribute is set to disabled, the PPTP or cardholder is in the
ITU-T M.3100 ALM state, in which alarms are reported normally. When the ARC attribute is set to
G.988(12)_FA.1.5-1
If the test was requested by the OLT, the test result notification contains the transaction identifier of
the original test command. An ONU may also run continuing diagnostic or monitoring routines, and
report failures either through alarms or through autonomous test result messages or both. A test result
message from a self-initiated test contains the transaction identifier zero.
A.1.6 Administrative state considerations
The administrative state attribute has two values: 0 (unlock) and 1 (lock).
In the state model of [ITU-T X.731], administrative state represents the intention of management to
allow (unlock) or deny (lock) the functionality of an ME. Administrative lock must not inhibit
management access to the ME. Though specified by neither [ITU-T X.731] nor [ITU-T X.733], a
common side effect of administrative lock is to suppress notifications from the locked entity and any
dependent entities. This avoids unnecessary alarms during maintenance and repair, or when a resource
is not in use. The OMCI conforms to this convention.
The need for continuing management access implies that, regardless of the administrative state, an
ONU must maintain its presence on the PON, and it may also have to provide local craft access, e.g.,
to enter registration information.
Subject to continuing management access, it is suggested that the ONU itself, any separable circuit
packs and all ports should power down as much as possible when the administrative state is locked.
It is further suggested that the default value for administrative state be locked. This reduces power
consumption in cases such as pre-installation of ONUs and unsubscribed or unused ports.
Operators may have additional requirements that override power-down or that override the suggested
lock default.
NOTE – When an ITU-T G.987 ONU enters initial state, as defined in [ITU-T G.987.3], it may set
administrative lock on the ONU-G ME, thereby preventing all user traffic from flowing until the OLT unlocks
the ONU-G. Although this is optional behaviour on the part of the ONU, the OLT is advised to check the state
of this attribute when bringing an ONU into service.
A.2.3 Delete
Field Byte 8 7 6 5 4 3 2 1 Comments
Transaction 1-2
correlation identifier
Message type 3 0 1 0 DB = 0, AR = 1, AK = 0
bits 5-1: action = delete
Device identifier 4 0 0 0 0 1 0 1 1 Extended OMCI = 0x0B
Managed entity 5-6 Entity class
identifier 7-8 Entity instance
Message contents 9-10 Size of message contents field = 0
length
MIC 11-14 Message integrity check
A.2.5 Set
As well as simple attributes, the set command may be used to set rows of tables. If it is used for this
purpose, however, one set command must set exactly one row of the table, because there is no way
to enumerate or separate multiple table entries. The set table command is available to set more than
one row with a single command.
A.2.7 Get
Field Byte 8 7 6 5 4 3 2 1 Comments
Transaction 1-2
correlation identifier
Message type 3 0 1 0 DB = 0, AR = 1, AK = 0
bits 5-1: action = get
Device identifier 4 0 0 0 0 1 0 1 1 Extended OMCI = 0x0B
Managed entity 5-6 Entity class
identifier 7-8 Entity instance
Message contents 9-10 Size of message contents field =
length 2 bytes
Message contents 11-12 Attribute mask
MIC 13-16 Message integrity check
A.2.19 Alarm
Field Byte 8 7 6 5 4 3 2 1 Comments
Transaction 1-2
correlation identifier
Message type 3 0 0 0 DB = 0, AR = 0, AK = 0
bits 5-1: action = alarm
Device identifier 4 0 0 0 0 1 0 1 1 Extended OMCI = 0x0B
Managed entity 5-6 Entity class
identifier 7-8 Entity instance
Message contents 9-10 Size of message contents field =
length 29 bytes
Message contents 11-38 Alarm bit map
39 Alarm sequence number
MIC 40-43 Message integrity check
A.2.21.2 Format for IP host config data and IPv6 host config data entity classes
A.2.35 Reboot
Field Byte 8 7 6 5 4 3 2 1 Comments
Transaction 1-2
correlation identifier
Message type 3 0 1 0 DB = 0, AR = 1, AK = 0
bits 5-1: action = reboot
Device identifier 4 0 0 0 0 1 0 1 1 Extended OMCI = 0x0B
Managed entity 5-6 Entity class
identifier 7-8 Entity instance
Message contents 9-10 Size of message contents field
length
A.2.39.2 Format for vendor-specific test actions invoked against ONU-G and circuit pack
entity classes
This format is also used for vendor-specific test actions invoked against the PPTP POTS UNI entity
class when no general purpose buffer is needed.
A.2.39.4 Format for test action invoked against IP host config data and IPv6 host config data
entity classes
If xxx = 010 (time exceeded – traceroute), the remainder of the message contains the following
content. In PON applications, it is not expected that a route trace will exceed the available space in
the message, but if it does, the more distant responses should be dropped.
If xxx = 011 (unexpected ICMP response), the remainder of the message contains the following
content:
A.2.39.5 Format for optical line supervision test action invoked against ANI-G, RE ANI-G,
PPTP RE UNI, RE upstream amplifier or RE downstream amplifier entity class
A.2.39.6 Format for test action invoked against dot1ag MEP entity class, loopback test
A.2.39.7 Format for test action invoked against dot1ag MEP entity class, linktrace test
A.3.3 Delete
A.3.5 Set
A.3.7 Get
Based on the size of the message contents field, the aggregate size of the attributes requested by a
single get command should not exceed 25 bytes.
A.3.21.2 Format for IP host config data and IPv6 host config entity classes
Test class 1:
A.3.35 Reboot
A.3.39.2 Format for vendor-specific test actions invoked against ONU-G and circuit pack
entity classes
This format is also used for vendor-specific test actions invoked against the PPTP POTS UNI entity
class when no general purpose buffer is needed.
A.3.39.4 Format for test action invoked against IP host config data and IPv6 host config data
entity classes
11 Type
12 Code
13-14 Checksum
15-18 Bytes 5-8 of ICMP message
(meaning depends on type/code)
19-40 Internet header + 64 bits of original
datagram (truncated)
OMCI trailer 41-48
A.3.39.5 Format for optical line supervision test action invoked against ANI-G, RE ANI-G,
PPTP RE UNI, RE upstream amplifier or RE downstream amplifier entity class
A.3.39.6 Format for test action invoked against dot1ag MEP entity class, loopback test
A.3.39.7 Format for test action invoked against dot1ag MEP entity class, linktrace test
OLT ONU
G.988(12)_FB.1-1
Execute
Start T 0 Message 1/Priority 0/AR = 1/AK = 0/TID = 1234 message 1
Execute
Start T 1 Message 2/Priority 1/AR = 1/AK = 0/TID = 8123 message 2
Message 1 reply/Priority 0/AR = 0/AK = 1/TID = 1234
Stop T0
(< Tmax0)
Message 2 reply/Priority 1/AR = 0/AK = 1/TID = 8123
T1 expires
(³ Tmax1)
Re-send message 2
Increment R 1 Discard message 2
Start T 1 Message 2/Priority 1/AR = 1/AK = 0/TID = 8123 (do not re-execute)
T0 expires
(³ Tmax0)
Re-send message 3
Increment R 0 Execute
Start T 0 Message 3/Priority 0/AR = 1/AK = 0/TID = 1235 message 3
A case where the OMCC link is effectively broken (link down) is shown in Figure B.2.1-2.
High priority
MIC generation queue
Event notification
Low priority protocol entity
queue
GATE1
DA = MAC control
SA = OLT MAC address
Content = Grant + Sync time + Discovery information
Grant start
1
REGISTER_REQ Random
Discovery DA = MAC control delay
window
SA = ONU MAC address
Content = Pending grants + Discovery information + Laser on
time + Laser off time
1
REGISTER
DA = ONU MAC address
SA = OLT MAC address
Content = LLID + Sync time + Echo of pending grants +
Target laser on time + Target laser off time
2
GATE
DA = MAC control
SA = OLT MAC address
Content = Grant
2
REGISTER_ACK
DA = MAC control
SA = ONU MAC address
Content = Echo of LLID + Echo of sync time
OMCC established
OMCC established
1
Messages sent on broadcast channel G.988(12)_FC.1-1
2
Messages sent on unicast channel
The extended OAM frame format and fields for the OMCI are defined in Table C.2-1.
Table C.2-1 Extended OAM frame format and fields for EPON OMCI
Field Length Definition Value
Preamble and 8 bytes Defined in clause 4.2 and LLID is assigned during
LLID/SFD clause 76 of [IEEE 802.3] ONU discovery process
Destination MAC 6 bytes Destination MAC address 0x0180C2000002
address
Source MAC address 6 bytes Source MAC address MAC address of source
equipment
Ethertype 2 bytes Clause 57 of [IEEE 802] 0x8809 (Slow protocol)
Subtype 1 byte Clause 57 of [IEEE 802] 0x03 (OAM)
Flags 2 bytes Clause 57 of [IEEE 802]
Code 1 byte Clause 57 of [IEEE 802] 0xFE
OUI 3 bytes ITU-T OUI 0x0019A7
OMCI message up to Defined in clauses 11 and A.2.
1493 bytes Extended OMCI message
Excludes MIC (4 bytes)
Frame check sequence 4 bytes Defined in [IEEE 802.3]
FCS
Table C.3-1 Relationship between clause 57 of [IEEE 802.3] OAM and OMCI
No. Items in clause 57 of [IEEE Corresponding OMCI functionalities
802.3]
1 Information This item is the OAM channel set-up procedure. It is provided
by the OMCC initial set-up procedures.
2 Event notification This item is alarm notification. It is provided by the alarm
notification function defined in the OMCI.
3 Variable request/response This item can be interpreted as MIB get/set. The OMCI
supports the same functions.
4 Loopback control This item is provided by OMCI loopback control.
Downstream
... GEM port
UNI PPTP
Extracting L2 flow
from GEM port
Mapping L2 flow
MEs on the UNI side
(eg.. L2 data service) to GEM port PQs, upstream
T-CONT ANI
GEM ports ...
Upstream
By introducing the concept of a virtual GEM port into the OMCI, the MEs in this Recommendation
can be re-used for EPON. In G-PON, a GEM port is defined to convey each layer 2 flow. The GEM
port network CTP connects the MAC bridge port and upstream/downstream priority queues in the
ONU for an Ethernet service. EPON requires the same configuration of connectivity between the
MAC bridge port and upstream/downstream priority queues. By configuring the GEM ports virtually,
G-PON and EPON are compatible in the OMCI. A virtual GEM port exists for the purpose of
connecting the MAC bridge port and priority queue. GEM port network CTP and GEM IW TP MEs
are created for the ME pointer relationship.
What this means is that the GEM port network CTP is re-used in EPON, but the value of the GEM
port attribute is not used. It is suggested that it be set to 0 by the OLT, and it must be ignored by the
ONU.
L2 flows
... GEM port
UNI PPTP
Upstream
VLAN operation, filtering, cross connection,
priority mapping, rate limiting, etc. G.988(10)_FC.4.1-2
Actions
No change required.
Notifications
End-to-end loss of continuity (optional) is not used in EPON.
C.4.2.2 Clause 9.2.4: GEM interworking termination point
An instance of this ME represents a point in the ONU where the IW of a bearer service (usually
Ethernet) to the GEM layer takes place. In an EPON system, the GEM port exists virtually, only for
keeping pointer relationships. IW option attribute values are limited because there is no actual IW
function. The value of the GAL profile pointer is null because there is no GAL profile in EPON.
Likewise, the value of GAL loopback configuration is always 0 (no loopback).
Relationships
No change required.
Attributes
Table C.4.2.2-1 summarizes the attributes of the GEM IW TP for EPON.
Actions
No change required.
Notifications
No change required.
OLT ONU
G.988(12)_FI.1.2.2-1
Figure I.1.2.2-1 – Increment of MIB data sync at the ONU and OLT under OLT command
In contrast, the MIB data sync counter is not incremented for autonomous creation and deletion of
ME instances by the ONU itself, nor is the MIB data sync counter incremented for autonomous
changes to attributes of MEs within the ONU (Figure I.1.2.2-2).
Figure I.1.2.2-2 – No increment of MIB data sync at the ONU and OLT
If the ONU is offline when the OS sends a command (create/delete/set), the OLT updates its MIB
locally and increments its MIB data sync, but it cannot send the command to the ONU. The
incremented OLT MIB data sync value guarantees that when the ONU comes online, the MIB audit
will fail. This mechanism also forces audit and reconciliation when an ONU is replaced.
The order in which the OLT and the ONU update their MIBs and increment the MIB data sync
attribute is not specified. Regardless of the order chosen, both the OLT and the ONU must locally
update their MIBs and increment their MIB data syncs as atomic actions. It is considered good
practice for the OLT not to increment its MIB data sync counter until it has received a positive AK
to the command that it sent to the ONU.
When incremented, the sequence number that follows 255 is 1. Zero is reserved for the following
cases:
1) default MIB with which the ONU left the factory;
2) an ONU which after initialization cannot restore its MIB.
In other words, a sequence number of 0 indicates that the ONU's MIB is not well defined or that it
does not contain service provisioning and therefore requires configuration or reconfiguration.
I.1.2.3 Loss of MIB synchronization
In the process of an OLT modifying the MIB in an ONU, the MIB at the OLT could fall out of
synchronization with the MIB at the ONU. Figure I.1.2.3-1 shows one possible scenario for this.
OLT ONU
Figure I.1.2.3-1 – Mismatch of MIBs at the ONU and OLT under OLT command
Figure I.1.2.3-2 illustrates an autonomous change at the ONU, whose AVC is not received by the
OLT. Normally, this information is transient and is not part of the MIB as strictly defined, but it must
be recognized that the OLT no longer has a correct view of the ONU's current state. Periodic scans
of ONU information are therefore encouraged.
AVC [lost]
OLT ONU
G.988(12)_FI.1.3.1-1
MIB upload
The ONU makes a copy of its MIB and
responds with an indication of the number
of MIB upload next commands required.
Get response
MIB upload next
MIB upload next response
G.988(12)_FI.1.3.2-1
The OLT must issue as many MIB upload next requests as the number of commands given in the
MIB upload response. The maximum time between two MIB upload next requests is 1 min. If the
OLT does not send an MIB upload next request within this time after the previous MIB upload next
request or after the MIB upload start request, the ONU assumes the MIB upload to be terminated.
The ONU can drop its copy of the MIB, and consider any further MIB upload next requests to be
invalid.
MIB upload returns all attributes of most MEs, including those that reflect transient information. MIB
upload is therefore a valid way for the OLT to synchronize much transient information, as well as
data of long-term interest. However, certain MEs are excluded from the MIB upload. In particular,
instances of some general purpose MEs, such as theME and the attribute ME, are not included in an
MIB upload. Table attributes are never included in an MIB upload. If the OLT requires this
information, it obtains it on a per table basis through the use of the get/get next mechanism. And
finally, the measurement attributes of PM MEs are not included in MIB uploads.
As the final step of MIB resynchronization, the OLT sets the MIB data sync attribute of the ONU
data ME to some suitable value of its own choice. It then sets its own record of the same attribute to
the same value, incremented by 1, as explained in clause I.1.2.2.
I.1.4 Bringing up ONUs
ONU bring-up may be separated into two classes: new ONU bring-up and old ONU bring-up. The
definition of new versus old ONU is based on the status of the ONU as viewed by the OLT.
New ONU: The ONU has never completed MIB synchronization with the OLT. Some examples
follow.
Upstream_overhead PLOAM
Activation
...
Ranging_time PLOAM
...
setup
Acknowledge PLOAM
MIB reset
Command response
Set response
Reset timer Ts
AC on
AC off
Reset timer Tr
Shed power
AC on
Power Shed
G.988(12)_FI.2.7-1
OLT ONU
...
G.988(12)_FI.2.8-1
Reboot
End download (1),
incorrect CRC
State S2
End
download (0)
Start
Start download (1) download (0)
State S3 State S3'
NOTE – In Figure I.3.1-1, states S1 and S2 (and S1' and S2') are distinguished only for convenience in understanding the flow. Upon
receipt of a start download message, and particularly when the ONU re-boots, any partial downloads in progress are discarded.
Section
byte number 0 1 2 ... 30
Window
"Download 0 1 2 ... Window
section number" size-1
Image
G.988(12)_FI.3.2.1-1
Figure I.3.2.1-1 – Relationship between image, windows and sections (baseline message set)
During the initial software download message exchange, the OLT proposes a maximum window size,
but a lower value can be stipulated by the ONU, which must be accepted by the OLT. The OLT may
send windows with fewer sections than this negotiated maximum, but may not exceed the maximum.
Though it is not a preferred choice, the OLT may send all windows at the full negotiated maximum
size, with the final window of the download operation padded out with download section messages
containing only null pad bytes.
Each download section message contains a sequence number, which begins anew at 0 with each
window. By tracking the incrementing sequence numbers, the ONU can confirm that it has in fact
received each section of code.
In the MT field of the last download section message of each window, the OLT indicates the end of
the window by setting the AR (acknowledgement request) bit – prior download section messages are
unacknowledged. If the ONU has not received the entire window correctly, i.e., if it misses a sequence
number, it acknowledges with a command processing error result, whereupon the OLT falls back to
the beginning of the window and tries again. To improve the chance of successful transmission, the
OLT may choose to reduce the size of the window on its next attempt.
When the final window has been successfully downloaded, the OLT sends an end software download
message whose contents include the size of the downloaded image in bytes, along with a CRC-32
computed according to [ITU-T I.363.5], across the entire image but excluding pad bytes that may
have been transmitted. If the ONU agrees with both of these values, it updates the software image
validity attribute to indicate that the newly downloaded image is valid. Figure I.3.2.1-2 illustrates this
process.
Start software download response (instance, success, window size-1[, parallel download info])
...
Download section (instance, section N-1, 31 bytes of image data) [AR = ack rqst]
Download section response (instance, command processing error, section N-1)
ONU signals failure to receive some or all of window.
The OLT re-transmits the window. For illustration, the OLT
chooses to send only S sections this time, S N.
Download section (instance, section 0, 31 bytes of image data)
...
Download section (instance, section S-1, 31 bytes of image data) [AR]
Download section response (instance, success, section S-1)
...
Download section (instance, section F-1, 31 bytes of image data padded with nulls) [AR]
Download section response (instance, success, section F-1)
End software download (instance, CRC-32, image size[, parallel download info])
End software download response (instance, success[, parallel download status])
G.988(12)_FI.3.2.1-2
The ONU should positively acknowledge an end download message only after it has performed
whatever operations may be necessary – such as storage in non-volatile memory – to accept an
immediate activate or commit message from the OLT. As illustrated in Figure I.3.2.1-3, the ONU
should respond with a device busy result code until these operations are complete, and the OLT should
periodically retry the end download command. The OLT should include a timeout to detect an ONU
that never completes the download operation.
...
Download section (section N-1, image data) [AR = ack rqst]
G.988(12)_FI.3.2.1-3
The nested state machines in the OLT and ONU can conceivably get out of step in a number of
unspecified ways; nor is it specified how to escape from a loop of transmission failure and retry. As
a recovery mechanism from detectable state errors, it is recommended that the ONU reply with
command processing error result codes to both the acknowledged download section and end software
download commands, and that the OLT send a final end software download command with a known
bad CRC and image size (e.g., all 0), whereupon both the OLT and ONU should reset to the state in
which no download is in progress, i.e., state S1/S1' of Figure I.3.1-1. Likewise, the OLT should be
able to abort the download operation at any time by sending an end software download message with
invalid CRC and image size.
As well as the download of an image to the ONU as a whole, the download messages allow an option
to download an image to each of several circuit packs in parallel. The starting assumption is that the
OLT knows the set of circuit packs that require the same download file, so that it can specify this set
in the download command sequence.
I.3.2.2 Extended message set download
The description of clause I.3.2.1 pertains also to download using the extended OMCI message set,
except that the maximum size of the section is limited by the extended message format itself, and is
potentially as large as 1965 bytes. The OLT may send smaller sections at will, including the final
section of a file transfer. Because the extended message format allows for variable length, software
image sections are never padded in this message format.
The negotiation of the window size is governed by two opposing criteria: 1) maximize throughput
and 2) avoid ONU receive buffer overflow. A problem arises if the ONU supports both baseline
message set and extended message set. At the time when the ONU negotiates the window size, the
ONU does not know whether the OLT will use baseline or extended message set for the download. If
The OLT updates its MIB and The ONU restarts with a new image,
increments its MIB data sync. which is now active but uncommitted.
...
After a successful start-up sequence,
the OLT decides to commit
the active software image.
G.988(12)_FI.3.3-1
I.4.1 Classical PM
Unneeded PM accumulation may impose an unnecessary load on the ONU host processor and should
be avoided. In classical PM, parameter collection can be disabled only by deleting the PM ME.
In classical PM, the ME ID attribute takes the same value as the parent ME's ID, so that no explicit
pointer to the parent ME is required. The ME class of the parent is fixed in the definition of the
classical PM ME.
Managed entity ID: This attribute uniquely identifies each instance of this ME. Through an
identical ID, this ME is implicitly linked to an instance of a <parent managed
entity class>. (R, set-by-create) (mandatory) (2 bytes)
In classical PM, the control block attribute is always a simple pointer to a threshold data ME, and is
designated as such. The attribute value may be set to a null pointer if no thresholding is desired. If no
assigned threshold number exceeds 7, it is the OLT's option whether to create a threshold data 2 ME
or not. The template text reads as follows, depending on the highest threshold attribute assigned:
Threshold data 1/2 ID: This attribute points to an instance of the threshold data 1 and 2 MEs
that contains PM threshold values. (R, W, set-by-create) (mandatory) (2 bytes)
Or:
Threshold data 1/2 ID: This attribute points to an instance of the threshold data 1 ME that
contains PM threshold values. Since no threshold value attribute number
exceeds 7, a threshold data 2 ME is optional. (R, W, set-by-create) (mandatory)
(2 bytes)
Control fields: (2 bytes). This field is a bit map whose values govern the
behaviour of the extended PM ME. Bits are assigned as follows:
NOTE – When text in this clause refers to the IP host config data ME, or to an IP stack, it is understood to
include the IPv6 host config data ME, or an IPv6 stack, as modified suitably by the differences between IPv4
and IPv6.
This appendix describes mechanisms and services that are common to G-PON systems, as described
in the relevant TC layer specification.
Traffic Traffic
descriptor PQ A4 descriptor
(downstream) (upstream)
Priority queue
4 (upstream)
GEM GEM port
interworking network PQ 4
TP CTP
G.988(12)_FII.1.2.1-1
Figure II.1.2.1-1 shows provisioning to provide upstream mapping of two VIDs and the IEEE 802.1p
priorities within those VIDs. With the VID selected by a VLAN tagging filter, the upper part of
Figure II.1.2.1-1 provisions IEEE 802.1p priorities to two GEM ports, each going to a single priority
queue. In the lower part of Figure II.1.2.1-1, the other VID is provisioned to map IEEE 802.1p
priorities to four GEM ports, each going to a single priority queue.
Figure II.1.2.1-1 shows only four priority queues because this is the minimum requirement of
[b-BBF TR-156]. Figure II.1.2.1-1 can easily be extended to six classes of traffic, the objective of
[b-BBF TR-156], by adding GEM port network CTPs, GEM IW TPs, priority queues and T-CONTs.
NOTE – This clause is specific to [b-BBF TR-156], which contemplates only a single queue per T-CONT.
Multiple queues per T-CONT are discussed further in clause II.3.
Traffic Traffic
descriptor PQ A1 descriptor T-CONT
(downstream) (upstream)
802.1p
mapper Traffic Traffic
service descriptor PQ A4 descriptor Priority queue
profile (downstream) (upstream) 3 (upstream)
VLAN
VID 2 tagging GEM GEM port
filter P bits = 3 interworking network PQ 4
TP CTP T-CONT
Priority queue
4 (upstream)
G.988(12)_FII.1.2.1-2
G.988(12)_FII.1.2.1.5-1
G.988(12)_FII.1.2.1.5-2
G.988(12)_FII.1.2.1.5-3
G.988(12)_FII.1.2.1.5-4
G.988(12)_FII.1.2.1.5-6
Traffic Traffic
descriptor PQ A1 descriptor
(downstream) (upstream) T-CONT
Traffic Traffic
descriptor PQ B1 descriptor Priority queue
(downstream) (upstream) 4 (upstream)
Traffic
descriptor PQ Ax
(downstream)
G.988(12)_FII.1.3.1.1-1
Create response
OLT ONU
Create (GEM port network CTP)
Create response
Create (MAC bridge port config data)
Create response
Create (VLAN tagging filter data) Once per bridge
Create response
Create (GEM interworking TP)
Or multicast GEM
Create response interworking TP
G.988(12)_FII.1.3.1.1.2-1
Traffic PQ Ax
MAC bridge descriptor
port config (downstream)
data MAC bridge Multicast GEM port
port config GEM IW TP network null
data CTP
VLAN Traffic Traffic
tagging descriptor PQ B1 descriptor
filter (downstream) (upstream)
Traffic PQ Ax
descriptor
(downstream)
Figure II.3.1.2-1 – Block diagram example of diffserv upstream QoS for G-PON
The L2-OCM provisioning model defined in clause II.1 supports diffserv. In this model, the traffic
descriptor ME is used to specify the treatment of each traffic class in the ONU. The following
considerations should be used when provisioning the traffic descriptor.
• For EF traffic, the CIR and PIR attributes should be set to the CIR of the EF traffic profile.
• For AF traffic, the CIR attribute should be set to the CIR of the AF traffic profile. The PIR
attribute should be set to the sum of the CIR and EIR of the AF traffic profile.
• For BE traffic, the CIR attribute should be set to the CIR of the BE traffic. The PIR attribute
should be set to the sum of the CIR and EIR of the BE traffic profile.
• The colour mode attribute should be set to 1 to indicate a colour aware traffic flow.
• The ingress colour marking and egress colour marking attributes should be set to 7 to indicate
DSCP AF drop precedence marking.
II.3.1.3 Metro Ethernet over G-PON
[b-MEF 10.2] describes an Ethernet virtual service (EVS), which is a layer 2 connection between
customer edge devices. In the MEF model, the edge of the QoS domain is defined at the ONU UNI,
where the marking/policing function is carried out. [b-MEF 10.2] does not define any specific per-
hop behaviour. Instead, it focuses on end-to-end service level specifications in terms of delay, delay
variation and packet delivery ratio. In this architecture, it is assumed that the UNI is a customer-facing
[IEEE 802.3] (Ethernet) interface on the ONU.
The traffic management defined by [b-MEF 10.2] employs a two-rate, three-colour policer, which is
identical to [b-IETF RFC 4115] if the MEF 10.2 variable CF is set to 0. The two rates are CIR and
EIR, and are defined for both ingress frames and egress frames. If the frame (ingress or egress) length
is less than the number of tokens in the committed token bucket, the frame is declared green; else if
the frame length is less than the number of tokens in the excess token bucket, the frame is declared
yellow; otherwise, the frame is declared red. This policing takes place at the UNI.
NSP2 L2TP
L2TS Access node
User1
NSP3 IP – QoS Eth
BNG agg OLT ODN ONU RG
IP
User2
ASP1 IP – QoS T
U
V S/R R/S Customer prem network
A10
RAN G.988(12)_FII.3.2-1
U
S/R R/S
V
Scheduler Scheduler
Assign to
queues
Classifier according
to GEM port
PON n UNI n
(same as above) (same as above)
ONU n
(same as above)
G.988(12)_FII.3.2.6-1
T-CONT B
V
Classifier
T-CONT C
Scheduler
T-CONT D
Classifier
PON n
(same as
above) ONU n
(same as above)
G.988(12)_FII.3.2.6-2
Traffic
descriptor
(upstream)
Traffic
descriptor
(upstream)
Traffic
descriptor
(upstream)
Figure II.3.3.1.1-1 – Example of weighted scheduling with three queues per T-CONT
and no traffic scheduler, queues connected directly to T-CONT
Figure II.3.3.1.1-2 shows an example of a T-CONT with four queues and a traffic scheduler. Because
each queue is connected to the traffic scheduler, the scheduling discipline is determined from the
policy attribute of the traffic scheduler ME, in this case weighted (policy = WRR).
Traffic
descriptor
(upstream)
Traffic Traffic
T-CONT
descriptor scheduler
(HOL)
(upstream) (WRR)
Traffic
descriptor
(upstream)
Figure II.3.3.1.1-2 – Example of weighted scheduling with four queues per T-CONT
and traffic scheduler, queues connected to traffic scheduler
Figure II.3.3.1.1-3 shows an example of a T-CONT with four queues and a traffic scheduler ME.
Because each queue is directly connected to the T-CONT ME, the scheduling discipline is determined
from the policy attribute of the T-CONT ME, in this case strict priority.
Traffic
descriptor
(upstream)
Traffic
descriptor
(upstream)
Traffic Traffic
T-CONT
descriptor scheduler
(HOL)
(upstream) (WRR)
Traffic
descriptor
(upstream)
NOTE – The traffic scheduler performs no function in this example. It is shown to illustrate components that may be present as
inbuilt features of the ONU architecture.
Figure II.3.3.1.1-3 – Example of strict priority scheduling with four queues per T-CONT
and traffic scheduler, queues connected directly to T-CONT
Traffic scheduler ME
By default, the traffic scheduler ME has a fixed scheduling policy and fixed pointers and a
configurable priority/weight. If the traffic scheduler is present, the following are its attribute settings.
Flexible configuration is discussed in clause II.3.3.2.
• The T-CONT pointer attribute is read-only, and always points to the associated T-CONT.
• The traffic scheduler pointer attribute is read-only and within the scope of this clause is
always null, because hierarchical scheduling is out of scope.
• The policy attribute is read-only, and within the scope of this clause is always the "opposite"
of the T-CONT ME, i.e., one must be WRR and the other must be strict priority.
• The priority/weight attribute is RW, and within the scope of this clause its value is a "don't
care," with a suggested value of zero.
T-CONT ME
The policy attribute is read-only and is always either WRR or strict priority.
Traffic
descriptor
(upstream)
Traffic
descriptor T-CONT
(upstream) (WRR)
Selectable policy
GEM port Priority
network CTP queue
Traffic
descriptor
(upstream)
Figure II.3.3.2.1-1 – Example system of weighted scheduling with four flexible queues
ONU2-G ME
The QoS configuration flexibility attribute of the ONU2-G ME indicates whether the ONU supports
flexible priority queue and traffic scheduler pointers, flexible traffic scheduler and T-CONT
scheduling policies, or flexible queue priority. Specifically, as follows.
1) If bit 1 is set, the priority queue ME may point to any T-CONT ME in the same slot.
2) If bit 2 is set, the priority queue ME may point to any traffic scheduler ME in the same slot.
3) If bit 3 is set, the traffic scheduler ME can point to any T-CONT in the same slot.
4) If bit 4 is set, the traffic scheduler ME policy attribute is RW.
5) If bit 5 is set, the T-CONT ME policy attribute is RW.
6) If bit 6 is set, the priority queue ME priority field is RW.
For the single-level scheduling in the rest of this clause, it is assumed that bits 1, 5 and 6 are set, and
bits 2, 3 and 4 are "don't care".
Priority queue ME
Each priority queue ME has a configurable priority and weight. The OLT can configure each priority
queue ME to point to any traffic scheduler ME or any T-CONT ME in the same slot.
The related port attribute is divided into two parts for upstream traffic: 1) the ME ID of the associated
T-CONT, which should be set to the desired T-CONT in a given slot; and 2) the priority of the queue.
To support strict priority scheduling between multiple queues, each queue must have a different
priority.
The weight attribute is RW, and is used to provide weighted scheduling between the queues
associated with a T-CONT.
The traffic scheduler pointer attribute is RW and is provisioned to either point to the associated traffic
scheduler ME or to the associated T-CONT ME (null pointer value). The value of this attribute should
be set to zero (null), indicating that this queue is mapped to the T-CONT indicated by the related port
attribute. During provisioning, there may be a temporary period where some of the priority queues
The OLT verifies that the ONU supports the OMCI and
SIP based on returned attribute values. This is typically
performed as a part of ONU discovery but is
shown here as a separate action for completeness.
G.988(12)_FII.4.5.1-1
OLT ONU
The OLT verifies that the ONU supports the OMCI and
ITU-T H.248 based on returned attribute values. This is
typically performed as a part of ONU discovery but is
shown here as a separate action for completeness.
G.988(12)_FII.4.5.2-1
Series J Cable networks and transmission of television, sound programme and other multimedia
signals
Printed in Switzerland
Geneva, 2019