T REC G.984.4 200911 I!Amd2!PDF E
T REC G.984.4 200911 I!Amd2!PDF E
T REC G.984.4 200911 I!Amd2!PDF E
T e l e c o m m u n i c a t i o n
ITU-T
TELECOMMUNICATION
STANDARDIZATION SECTOR
OF ITU
U n i o n
G.984.4
Amendment 2
(11/2009)
G.100G.199
G.200G.299
G.300G.399
G.400G.449
G.450G.499
G.600G.699
G.700G.799
G.800G.899
G.900G.999
G.900G.909
G.910G.919
G.920G.929
G.930G.939
G.940G.949
G.950G.959
G.960G.969
G.970G.979
G.980G.989
G.990G.999
G.1000G.1999
G.6000G.6999
G.7000G.7999
G.8000G.8999
G.9000G.9999
Amendment 2
Changes and extensions to the OMCI, editorial clarifications and corrections
Summary
Amendment 2 to Recommendation ITU-T G.984.4 contains various updates to Recommendation
ITU-T G.984.4 (2008) and Recommendation ITU-T G.984.4 (2008) Amendment 1 (2009). A
number of editorial corrections and clarifications are included, along with the following substantive
changes and extensions to the G-PON OMCI.
A virtual interface definition for use when an ONT is managed by two domains, OMCI and
for example TR-69.
An extended form of the OMCI message set to facilitate exchange of larger quantities of
control plane information between ONT and OLT.
A mechanism that supports mutual authentication of OLT and ONT and secure transport of
encryption keys.
Source
Amendment 2 to Recommendation ITU-T G.984.4 (2008) was approved on 13 November 2009 by
ITU-T Study Group 15 (2009-2012) under Recommendation ITU-T A.8 procedures.
FOREWORD
The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of
telecommunications, information and communication technologies (ICTs). The ITU Telecommunication
Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical,
operating and tariff questions and issuing Recommendations on them with a view to standardizing
telecommunications on a worldwide basis.
The World Telecommunication Standardization Assembly (WTSA), which meets every four years,
establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on
these topics.
The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.
In some areas of information technology which fall within ITU-T's purview, the necessary standards are
prepared on a collaborative basis with ISO and IEC.
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 2010
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the
prior written permission of ITU.
ii
CONTENTS
Page
1)
1
1
1
1
2)
3)
4)
5)
6)
7)
29
8)
30
30
30
9)
31
31
31
31
10)
33
11)
33
33
34
12)
34
13)
35
14)
35
15)
37
37
37
37
16)
39
17)
39
iii
37
38
38
Page
18)
39
39
39
39
40
19)
Addition of an action in clause 9.3.6, MAC bridge port filter table data .....................
40
20)
Addition of two code points in clause 9.3.10, 802.1p mapper service profile .............
40
21)
41
41
41
42
42
43
23)
43
24)
43
25)
43
26)
44
27)
44
44
44
28)
44
29)
44
30)
45
31)
46
32)
Modification of clause 9.5.1, Physical path termination point Ethernet UNI ..............
46
33)
47
34)
Revision of a Note in clause 9.7.1, Physical path termination point xDSL UNI
part 1 .............................................................................................................................
48
35)
48
36)
48
37)
Addition of an action in clause 9.7.11, xDSL downstream RFI bands profile .............
48
38)
Modification of clause 9.7.17, VDSL2 line inventory and status data part 2...............
49
39)
49
40)
49
41)
Revision of clause 9.8.1, Physical path termination point CES UNI ...........................
49
22)
iv
Page
42)
50
50
50
43)
50
50
50
50
44)
51
45)
Modification of clause 9.9.1, Physical path termination point POTS UNI ..................
45.1) Revision of an attribute ..................................................................................
45.2) Revision of an action ......................................................................................
52
52
52
46)
52
52
53
47)
53
48)
53
53
54
57
49)
Addition of new attributes in clause 9.9.9, VoIP feature access codes ........................
58
50)
58
51)
58
52)
58
53)
58
58
59
59
60
54)
60
60
61
55)
61
56)
61
61
61
57)
62
58)
62
Page
59)
62
60)
62
61)
63
63
64
64
62)
64
63)
Revision of clause 9.13.3, Physical path termination point LCT UNI .........................
66
64)
67
65)
67
66)
75
67)
75
68)
76
69)
76
70)
94
94
94
97
98
103
71)
105
72)
108
73)
108
74)
108
75)
111
76)
111
77)
113
78)
153
79)
153
80)
153
81)
154
vi
Amendment 2
Changes and extensions to the OMCI, editorial clarifications and corrections
1)
1.1)
[ITU-T G.986]
1.2)
Deletion
Modification
To:
[ATIS-0300220]
2)
3)
Security management
[ITU-T G.984.3] specifies some mechanisms from the viewpoint of security. That includes the
downstream data encryption of the ONT. The ONT2-G managed entity can select the downstream
encryption algorithm from a list that presently includes only AES.
OMCI also supports a mechanism to allow mutual authentication of OLT and ONT and subsequent
secure communication of encryption keys.
4)
PON protection
This Recommendation supports the protection function. The type C protection configuration that is
defined in [b-ITU-T G.984.1] is considered in this Recommendation. As the switching behaviour
for PON protection will be done in the TC layer, this Recommendation defines a managed entity to
specify the protection capability.
5)
Required/
Optional
CR
9.5.5
ONT-E
CR
9.1.13
CR
9.13.11
CR
9.8.14
Description
Clause
Revise the description of GEM traffic descriptor to read as follows, and relocate it into the proper
alphabetic order in the table:
Table 8-1 Managed entities of the OMCI
Managed entity
Traffic descriptor
Required/
Optional
CR
Description
Used to specify traffic management parameters
Clause
9.11.3
6)
This clause shows the relationships between managed entities. Figure 8.2-1 gives the legend of
symbols used in these diagrams. The name of the managed entity, sometimes abbreviated for ease
of documentation, appears in each box, with the clause in which it is defined shown in the lower
right corner.
Managed
entity A
9.xx.xx
Managed
entity B
9.xx.xx
1
Managed
entity A
xx PM
history data
9.xx.xx
Managed
entity B
9.xx.xx
Managed
entity B
9.xx.xx
9.xx.xx
Managed
entity B
1
0..X
9.xx.xx
Managed
entity A
9.xx.xx
Managed
entity A
Managed
entity A
9.xx.xx
OR
9.xx.xx
Managed
entity B
9.xx.xx
There is a 1 to 1 relationship of A to B
8.2.1
9.1.4
ONT data
Cardholder
9.1.3
ONT-G
1..127
9.1.5
1..127
Cardholder
9.1.1
0..1
9.1.5
0..1
ONT2-G
1
9.1.2
1
Circuit pack
0,2
0..1
Port mapping
package-G
9.1.6
1..255
9.1.8
0..1
1
1
PPTP
xx
UNI
1
1
UNI-G
Equipment
extension
package 9.1.9
Traffic
scheduler-G
0..n
0..1
0..n
Priority
queue-G
(down) 9.11.1
0..n
1
0..1
Traffic
descriptor
0..n
9.11.3
GEM port
PM history
data
9.2.6
1
ANI-G
User data
ME complex
1..255
0,2
9.1.6
0..256
T-CONT
0..1
9.2.3
Circuit pack
0..256
9.2.2
GEM port
netwk CTP
9.12.1
OR
0..n
0..n
OR
1
0..256
9.11.1
0..256
9.11.2
Priority
queue-G (up)
0..n
9.2.1
Working side
Protecting side
Traffic
scheduler-G
9.11.2
0..n
0..256
0..1
Priority
queue-G (up)
OR
0..n
9.11.1
0..256
0..n
T-CONT
9.2.2
0..n
When protection
is activated,
pointers to TCONTs and
schedulers are
mapped from
working side to
protecting side
Traffic
scheduler-G
9.11.2
0..256
OR
0..256
T-CONT
9.2.2
OR
0..256
0..256
Circuit pack
Circuit pack
9.1.6
1..255
9.1.6
1..255
GEM port
netwk CTP
9.2.3
Protected
traffic
1
ANI-G
9.2.1
1
Protection
data
9.1.10
ANI-G
9.2.1
Working side
Protecting side
Traffic
scheduler-G
0..n
9.11.2
0..256
OR
0..n
0..1
Priority
queue-G (up)
9.11.1
0..256
0..n
T-CONT
9.2.2
When protection
is activated,
pointers to TCONTs and
schedulers are
mapped from
working side to
protecting side
0..n
0..1
Priority
queue-G (up)
Traffic
scheduler-G
9.11.2
0..256
OR
9.11.1
0..n
0..256
T-CONT
0..n
9.2.2
0..n
OR
OR
0..256
0..256
Circuit pack
Circuit pack
1
9.1.6
1..255
GEM port
netwk CTP
GEM port
netwk CTP
9.2.3
ANI-G
9.2.1
1..255
9.2.3
Protected
traffic
9.1.6
Extra
traffic
Protection
data
9.1.10
1
ANI-G
9.2.1
Layer 2 functions
OMCI supports two major layer 2 traffic mapping models: MAC bridging and "802.1p mapping."
MAC bridging is described in [IEEE 802.1D] and [IEEE 802.1Q]. The bridge described in
Figure 8.2.2-1 below has many features, and can be used to direct traffic based on MAC address
(that is, true bridging) or on VLAN characteristics (using the VLAN filter feature). The mapping
function describes the steering of traffic from one UNI-side entity to 1-8 ANI-side Port-IDs, as
shown in Figure 8.2.2-2 below. The mapper is equivalent to a MAC bridge with VLAN filters that
only operate on the priority bits of the VLAN tags.
Extended
VLAN tag
op
9.3.13
VLAN tag
op config
data
9.3.12
Any ME to which
VLAN tagging
can be assigned
0..1
1
9.3.18
1
0..1
MAC bridge
port config
data
9.3.4
0..w
0..m
MAC bridge
service
profile 9.3.1
1
1
1
Dot1 rate
limiter
1
0..1
0..n
0..1
1
1
9.3.2
0..1
1
GAL
Ethernet
PM
9.2.8
GAL
Ethernet
profile 9.2.7
MAC
bridge PM
MAC bridge
port config
data
9.3.4
MAC bridge
config data
9.12.1
0..1
9.3.3
UNI-G
GEM
interworking
TP
9.2.4
0..1
0..p
GEM port
network
CTP
9.2.3
PPTP
xx UNI
1
1
1
1
1
1
MAC bridge
port filter
table
9.3.6
MAC bridge
port bridge
table
9.3.8
0..1
VLAN
tagging filter
data
9.3.11
MB port filter
preassign
table
9.3.7
MB port
designation
data
9.3.5
Enet frame
PM, up/dn
9.3.30-31
1
1
MB port
PM
9.3.9
Extended
VLAN tag
op
9.3.13
VLAN tag
op config
data
9.3.12
Any ME to which
VLAN tagging
can be assigned
GEM port
network
CTP
9.2.3
GEM
interworking
TP
9.2.4
0..1
0..1 1
0..n
8
0..8
802.1p
mapper svc
profile 9.3.10
GAL
Ethernet
PM
9.2.8
GAL
Ethernet
profile 9.2.7
0..1
1
Dot1 rate
limiter
9.3.18
UNI-G
9.12.1
PPTP
xx
UNI
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 ANI service;
1:M mapping, where a mapper is used to serve a single UNI with multiple ANI
connections, based on 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 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.
GEM
interworking
TP
9.2.4
1
Dot1 rate
limiter
1
0..1
(Extended)
VLAN tag
op 9.3.12-13
1
1
MAC bridge
port config
data
9.3.4
MAC bridge
port config
data
9.3.4
9.3.18
MAC bridge
port config
data
9.3.4
MAC bridge
service
profile 9.3.1
N
1
(Extended)
VLAN tag
op 9.3.12-13
PPTP
xx
UNI
1
PPTP
xx
UNI
GEM port
network CTP
GEM port
network CTP
1
GEM
interworking
TP
9.2.4
Dot1 rate
limiter
9.3.18
1
0..1
(Extended)
VLAN tag
op 9.3.12-13
GEM
interworking
TP
9.2.4
802.1p
mapper svc
profile 9.3.10
1
1
1
1
1
PPTP
xx
UNI
10
VLAN
tagging filter
data
9.3.11
GEM
interworking
TP
9.2.4
1
VLAN
tagging filter
data
9.3.11
1
1
MAC bridge
port config
data
9.3.4
P
MAC bridge
service
profile 9.3.1
1
Dot1 rate
limiter
9.3.18
(Extended)
VLAN tag
op 9.3.12-13
1
1
MAC bridge
port config
data
9.3.4
0..1 1
1
GEM
interworking
TP
9.2.4
MAC bridge
port config
data
9.3.4
1
1
1
1
1
VLAN
tagging filter
data
9.3.11
PPTP
xx
UNI
11
GEM port
network CTP
GEM port
network CTP
1
GEM
interworking
TP
9.2.4
1
802.1p
mapper svc
profile 9.3.10
Dot1 rate
limiter
9.3.18
GEM
interworking
TP
9.2.4
1
1
1
MAC bridge
port config
data
9.3.4
MAC bridge
port config
data
9.3.4
0..1 1
MAC bridge
service
profile 9.3.1
MAC bridge
port config
data
9.3.4
(Extended)
VLAN tag
op 9.3.12-13
N
1
1
1
PPTP
xx
UNI
(Extended)
VLAN tag
op 9.3.12-13
1
1
1
PPTP
xx
UNI
12
GEM port
network CTP
GEM port
network CTP
GEM port
network CTP
1
GEM
interworking
TP
9.2.4
1
GEM
interworking
TP
9.2.4
GEM
interworking
TP
9.2.4
1
802.1p
mapper svc
profile 9.3.10
802.1p
mapper svc
profile 9.3.10
1
1
1
1
1
GEM port
network CTP
MAC bridge
port config
data
9.3.4
1
GEM
interworking
TP
9.2.4
1
1
1
MAC bridge
port config
data
9.3.4
1
P
VLAN
tagging filter
data
9.3.11
1
1
MAC bridge
service
profile 9.3.1
Dot1 rate
limiter
VLAN
tagging filter
data
9.3.11
0..1 1
1
9.3.18
(Extended)
VLAN tag
op 9.3.12-13
MAC bridge
port config
data
9.3.4
1
1
1
1
1
VLAN
tagging filter
data
9.3.11
PPTP
xx
UNI
13
VLAN
tagging filter
data
9.3.11
GEM
interworking
TP
9.2.4
9.3.18
1
1
Dot1 rate
limiter
MAC bridge
port config
data
9.3.4
1
P
1
0..1
MAC bridge
port config
data
9.3.4
(Extended)
VLAN tag
op 9.3.12-13
VLAN
tagging filter
data
9.3.11
1
1
MAC bridge
service
profile 9.3.1
1
(Extended)
VLAN tag
op 9.3.12-13
PPTP
xx
UNI
1
1
MAC bridge
port config
data
9.3.4
1
1
1
PPTP
xx
UNI
14
MAC bridge
port config
data
9.3.4
N
1
GEM
interworking
TP
9.2.4
1
1
VLAN
tagging filter
data
9.3.11
GEM port
network CTP
GEM port
network CTP
GEM port
network CTP
1
GEM
interworking
TP
9.2.4
1
802.1p
mapper svc
profile 9.3.10
GEM
interworking
TP
9.2.4
GEM
interworking
TP
9.2.4
1
MAC bridge
port config
data
9.3.4
1
GEM
interworking
TP
9.2.4
1
1
1
1
1
P
MAC bridge
port config
data
9.3.4
1
1
MAC bridge
service
profile 9.3.1
1
MAC bridge
port config
data
9.3.4
(Extended)
VLAN tag
op 9.3.12-13
802.1p
mapper svc
profile 9.3.10
VLAN
tagging filter
data
9.3.11
1
1
GEM port
network CTP
1
1
PPTP
xx
UNI
VLAN
tagging filter
data
9.3.11
N
1
1
(Extended)
VLAN tag
op 9.3.12-13
MAC bridge
port config
data
9.3.4
1
1
1
1
1
VLAN
tagging filter
data
9.3.11
PPTP
xx
UNI
15
Multicast
GEM IW TP
1..n
1
9.2.5
MAC bridge
port config
data
9.3.4
GEM
interworking
TP
9.2.4
Ext VLAN
tag op
(optional)
1
2
MAC bridge
service
profile 9.3.1
1
Note: An extended VLAN tagging
operation config data may be
associated with the multicast GEM
interworking TP or the UNI to
specify simple downstream
multicast VLAN behaviour.
MAC bridge
port config
data
9.3.4
1
(Extended)
VLAN tag
op 9.3.12-13
MAC bridge
port config
data
9.3.4
Ext VLAN
tag op
(optional)
1
1
PPTP
xx
UNI
1
1
1
GEM IW TP
(note)
9.2.4
1..n
1
MAC bridge
port config
data
9.3.4
VLAN
tagging filter
data
9.3.11
1
1
MAC bridge
port config
data
9.3.4
MAC bridge
service
profile 9.3.1
1
1
VLAN
tagging filter
data
9.3.11
MAC bridge
service
profile 9.3.1
M
1
MAC bridge
port config
data
9.3.4
Dot1ag MEP
status
9.3.23
1
MAC bridge
service
0..1
profile
9.3.1
Dot1ag
CFM stack
9.3.25
Dot1ag
default MD
level
9.3.21
1
Dot1ag
1 MEP
Dot1ag
chassis mgt
info
9.3.26
1
0..p
9.3.22
Dot1ag
1
maintenance
assoc
9.3.20
Dot1ag
MEP CCM
database
9.3.24
Dot1ag
maintenance
domain
9.3.19
G.984.4(08)Amd.2(09)_F8.2.2-12
9.3.23
1
Dot1ag
MEP CCM
database
9.3.24
Dot1ag
1 MEP
9.3.22
802.1p
mapper svc
0..1
profile
9.3.10
1
0..p
Dot1ag
1
maintenance
assoc
9.3.20
Dot1ag
CFM stack
9.3.25
Dot1ag
chassis mgt
info
9.3.26
Dot1ag
default MD
level
9.3.21
M
Dot1ag
maintenance
domain
9.3.19
G.984.4(08)Amd.2(09)_F8.2.2-13
17
8.2.3
Routing
GEM port
network CTP
1
GEM
interworking
TP
9.2.4
0..1
0..1
0..n
1
IP router
PM 1..2
9.4.6, -.7
1
0..1
1
ICMP PM
history 1..2
9.4.8, -.9
IP router
service
profile 9.4.1
1
0..p
9.4.3
IP
static routes
9.4.5
1
1
IP
route table
9.4.4
IP port
config data
0..1
ARP service
profile
9.4.3
IP router
config data
9.4.2
9.4.10
ARP config
data
0..1
PPTP
xx
UNI
18
GAL
Ethernet
PM
9.2.8
GAL
Ethernet
profile 9.2.7
IP port
config data
0..w 0..m
9.4.11
1
1
8.2.4
xDSL service
From layer 2 ME (802.1p or
MAC bridge port configuration
data) or VP network CTP-G
0..q
1
0..256
1
xDSL line
config 1..3
1
1
xDSL
subcarrier
mask up 9.7.9
UNI-G
xDSL chan
down status
0..1
9.7.19
PPTP xDSL
UNI 2
0..n
9.7.2
1
xDSL line inv
& status 1..7
9.7.12-15, .28-30
9.7.22
1..4
xTU-R PM
history
9.12.1
VDSL2 line
config ext
1..2 9.7.6, .26
VDSL2 line
inv & status
1..3 9.7.16-18
0..p
9.7.3-5
xDSL down
RFI bands
profile 9.7.11
0..r
9.7.1
xDSL PSD
mask
9.7.10
PPTP xDSL
UNI 1
0..s
xDSL
subcarrier
mask dn 9.7.8
1..4
xDSL chan
upstr status
1
1
9.7.20
TC adaptor
PM history
xDSL 9.7.25
0..1
1
xTU-C PM
history
1
xTU-C
channel
PM
9.7.23
Impulse
noise PM
xDSL chan
config
profile 9.7.7
0..1
1
9.7.27
9.7.21
0..1
1
xTU-R
channel
PM
9.7.24
19
0..1
0..n
9.13.5
0..1
9.13.4
VP network
CTP-G
Interworking
VCC TP
0..1
AAL5
profile
0..n
1
AAL5 PM
history data
9.13.9
9.13.6
0..256
VP PM
history data
9.13.10
802.11 service
From layer 2 ME (802.1p
mapper or MAC bridge
port configuration data)
1
UNI-G
0..1
9.12.1
1
1
802.11 PM
history data
9.6.7
802.11 station
mgt data 1..2
PPTP
802.11 UNI
9.6.1
0..1
1
9.6.2-3
2..n
1
802.11 gen
purpose ME
802.11 PHY
FHSS DSSS
IR tables 9.6.6
0..2
9.6.4
20
1
1
2
802.11 MAC
PHY ops &
antenna 9.6.5
8.2.6
MoCA service
MoCA
interface
PM
9.10.3
0..1
1
1
PPTP MoCA
UNI
9.10.1
0..1
MoCA
Ethernet
PM
9.10.2
0..1
UNI-G
1
9.12.1
0..1
1
0..n
0..1
GAL
Ethernet
PM
9.2.8
GAL
Ethernet
profile 9.2.7
Video return
path service
profile 9.13.7
0..1
PPTP video
ANI
9.13.2
PPTP video
UNI
9.13.1
1
Video ret
path PM
1
1
N
Cardholder
9.13.8
9.1.5
21
8.2.8
VoIP service
VoIP config
data
9.9.18
SIP agent
PM history
SIP call
initiation
PM
9.9.15
9.9.14
1
0..1
SIP config
portal
1
0..1
9.9.19
VoIP line
status
9.9.12
0..1
9.9.11
0..1
PPTP POTS
UNI
1
RTP PM
history data
9.9.13
1
0..1
9.9.1
UNI-G
1
9.12.1
22
VoIP config
data
9.9.18
MGC PM
history
9.9.17
1
0..1
MGC config
portal
9.9.20
VoIP line
status
9.9.12
0..1
1
RTP PM
history data
9.9.13
9.9.11
0..1
PPTP POTS
UNI
1
0..1
9.9.1
0..1
UNI-G
1
9.12.1
23
RTP profile
data
VoIP config
data
0..m
9.9.7
VoIP media
profile
1
Voice
service
profile
9.9.5
9.9.11
9.9.6
1
0..m
9.9.10
VoIP feature
access codes
1 1 1
9.9.3
9.4.14
1
0..1
1
Authenticn
security
method 9.12.4
0..m
0..1
VoIP appl
service
profile 9.9.8
SIP call
initiation
9.9.15
PM
0..1
UNI-G
1
24
0..1
0..m
9.9.12
0..1
SIP agent
config data
TCP/UDP
config data
PPTP POTS
UNI
Call ctrl
PM history
9.9.1
9.9.9
SIP agent
PM history
9.9.14
data
0..1
0..1
0..1
9.9.4
0..m
VoIP line
status
0..m
VoIP voice
CTP
Network dial
plan table
9.9.13
9.9.18
1
1
RTP PM
history data
9.12.1
RTP profile
data
VoIP config
data
0..m
9.9.7
VoIP media
profile
1
Voice
service
profile
9.9.13
9.9.18
1
1
RTP PM
history data
9.9.5
9.9.11
1
VoIP voice
CTP
9.9.6
0..1
1
MGC PM
history data
1
0..1
9.9.4
0..1
VoIP line
status
0..m
0..1
Call
control PM
9.9.12
0..1
1
PPTP POTS
UNI
9.9.1
MGC config
data
9.9.16
UNI-G
1
0..1
9.12.1
TCP/UDP
config data
9.9.17
9.4.14
0..1
1
Network
address
9.12.3
1
Large string
9.12.5
IP host
config data
9.4.12
0..m
1
1
Authenticn
security
method 9.12.4
0..1
1
IP host PM
history data
9.4.13
1
TCP/UDP
config data
9.4.14
25
8.2.9
9.2.4
MPLS PW
TP
9.8.14
TCP/UDP
config data
9.4.14
OR
OR
1
1..n
1
1
Logical
N x 64 CTP
OR
RTP
pseudowire
parms 9.8.6
9.8.7
Pseudowire
termination
point
9.8.5
Unstructured
1
1..n
0..1
9.8.4, -.12-13
9.8.1
UNI-G
1
Pseudowire
PM history
9.8.8
data
CES phy
PM 1, 2, 3
PPTP CES
UNI
9.8.2
26
0..1
9.8.9
Over Ethernet
Pseudowire
mtce profile
Structured
Ethernet
flow TP
Over MPLS
Over IP
9.12.1
GEM port
network CTP
1
CES service
profile-G
1..n
9.8.3
GEM
interworking
TP
9.2.4
1..n
9.2.9
TU
CTP
9.2.10
GAL TDM
profile
9.8.7
GAL TDM
PM history
0..1
Pseudowire
mtce profile
0..1
1
0..1
9.8.10
1
TU PM
history data
9.8.11
Structured
1
Logical
N x 64 CTP
OR
Unstructured
1
1
1..n
CES phy
PM 1, 2, 3
9.8.4, -.12-13
PPTP CES
UNI
9.8.2
9.8.1
UNI-G
1
9.12.1
0..255
RE
ANI-G
9.14.1
27
1
1
RE common
amplifier
parms 9.14.6
RE upstream
amplifier
9.14.3
RE common
1 amplifier
parms 9.14.6
1
RE downstr
amplifier
0..255
1
9.14.4
RE common
amplifier
parms 9.14.6
RE upstream
amplifier
1
1
PPTP
RE UNI
1
1
9.14.3
RE
ANI-G
0..255
9.14.2
9.14.1
RE downstr
amplifier
9.14.4
PPTP
RE UNI
9.14.2
0..255
1
1
RE
ANI-G
9.14.1
28
MAC bridge
port config
data
9.3.4
0..1
1
IP host
config data
9.4.12
0..m
1
To MAC bridge service per
existing in-band management
protocol server
TCP/UDP
config data
9.4.14
0..1
RE config
portal
9.14.5
ONT-E
9.5.1
9.1.13
1
1
ONT data
9.1.3
9.13
Miscellaneous services
9.14
29
8)
8.1)
Revise the attribute value change (AVC) table to read as follows. This removes AVCs on vendor ID,
model and SN.
Attribute value change
Number
1..7
Op state
N/A
10..16
8.2)
Description
Operational state change
Reserved
Alarm
Equipment alarm
Powering alarm
Battery missing
Battery failure
Battery low
Physical intrusion
Dying gasp
Temperature yellow
Temperature red
10
Voltage yellow
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
The ONT is shutting down because the subscriber has turned off
its power switch.
13..207
Reserved
208..223
Vendor-specific alarms
30
Description
Not to be standardized.
9)
9.1)
Add code points 0x86 and 0x96 to the following attribute, as shown:
OMCC version:
This attribute identifies the version of the OMCC protocol being used by the
ONT. This allows the OLT to manage a network with ONTs that support
different OMCC versions. Release levels of G.984.4 may be supported with
the following code points:
0x80
G.984.4 (06/04)
NOTE 1 For historic reasons, this codepoint may also appear in ONTs
that support later versions of G.984.4.
0x81
0x82
0x83
0x84
G.984.4 (02/08)
0x85
0x86
0x96
9.3)
This attribute reports the total number of upstream priority queues that
are not associated with a circuit pack, but with the ONT in its entirety.
Upon ME instantiation, the ONT sets this attribute to the value that
represents its capabilities. (R) (mandatory) (2 bytes)
This attribute indicates the Ethernet connectivity models that the ONU
can support. The value 0 indicates that the capability is not supported; 1
signifies support. The following codepoints are defined:
31
Bit
Model
1 (LSB)
816
Reserved
NOTE 2 It is not implied that an ONU may not support other connectivity
models.
Connectivity model
No selection (default)
N:1 bridging
1:M mapping
1:P filtering
N:M bridge-mapping
1:MP map-filtering
N:P bridge-filtering
N:MP bridge-map-filtering
Reserved
32
This attribute reports whether various managed entities in the ONT are
hard-wired or configurable. For backward compatibility, and if the ONT
does not support this attribute, all such attributes are understood to be
hard-wired. (R) (optional) (2 bytes)
Bit
1 (LSB)
6..16
Discussion:
Reserved
To allow for the possibility that the OLT does not support flexible
configuration, the ONT 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 ONT
initialization and MIB reset. The specifics of such a configuration are
beyond the scope of this Recommendation.
The managed entity ID of both the T-CONT and traffic scheduler
contains a slot number. Even when attributes in the above list are readwrite, 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.
10)
Latch a snapshot (i.e., copy) of the current MIB. Not every managed
entity or every attribute is included in a MIB upload. Table attributes are
excluded. Only the control block attributes of performance monitoring
MEs are uploaded. Other MEs and attributes, such as the PPTP for the
local craft terminal, are excluded as documented in their specific
definitions.
11)
11.1)
33
11.2)
Revise the attribute value change table to read as follows (add ARC):
Attribute value change
Number
1
Actual type
2..4
Description
Actual type of circuit pack in cardholder
N/A
Actual equipment id
6..7
N/A
ARC
9..16
12)
Reserved
Relationships
One instance of this managed entity is associated with two instances of the ANI-G, RE ANI-G or
RE upstream amplifier. One of the ANI managed entities represents the working side; the other
represents the protection side.
Attributes
Managed entity id:
Working ANI-G
pointer:
34
Protection ANI-G
pointer:
Protection type:
This attribute indicates the type of PON protection. Valid values are:
0
1+1 protection
This attribute indicates whether protection is revertive (1) or nonrevertive (0). (R, W (if applicable), Set-by-create (if applicable))
(mandatory) (1 byte)
Wait to restore
time:
This attribute specifies the time, in seconds, to wait after a fault clear
before switching back to the working side. Upon ME instantiation, the
ONT sets this attribute to 3 seconds. (R, W, Set-by-create (if applicable))
(mandatory) (2 bytes)
Switching guard
time:
Actions
Create, delete (if applicable)
Get, set
Notifications
None.
13)
14)
This attribute is used to pass reply information back to the OLT. Its
format is defined by the command format attribute. The get, get next
action sequence must be used with this attribute, since its size is
unspecified. (R) (mandatory) (N bytes)
35
Relationships
All other managed entities in this Recommendation are related directly or indirectly to the ONT-E
entity.
Attributes
Managed entity id:
Vendor id:
This attribute identifies the vendor of the ONT. Both the code set for the
Vendor_ID, specified in [ATIS-0300220] and the organizationally
unique identifier (OUI) specified in clause 9 of [IEEE 802], could be
applied for this attribute.
When the code set for the Vendor_ID, specified in [ATIS-0300220], is
applied for this attribute, the 4 characters are mapped into the 4-byte field
by concatenating the ASCII/ANSI character codes.
When the OUI is applied for this attribute, the 3 characters are mapped
into the 4-byte field with 0xFF assigned to the first octet.
(R) (mandatory) (4 bytes)
Octet
Content
Vendor_ID in [ATIS-0300220]
0xFF
Version:
This attribute identifies the version of the ONT as defined by the vendor.
The character value "0" indicates that version information is not available
or applicable. (R) (mandatory) (14 bytes)
Serial number:
The serial number is unique for each ONT. It is defined by the vendor.
The character value "0" indicates that serial number information is not
available or applicable. (R) (mandatory) (8 bytes)
Actions
Get
Reboot:
Notifications
Alarm
36
Number
Alarm
0
1..207
208..223
Equipment alarm
Reserved
Vendor-specific alarms
Description
Functional failure on an internal interface
Not to be standardized
15)
15.1)
In the introductory text, correct the reference to clause 11.3.3 to read 11.4.3.
15.3)
Null.
HOL Head of line queuing.
WRR Weighted round robin.
15.4)
Revise the descriptions of the two following attributes to read as shown (change GEM traffic
descriptor to traffic descriptor):
Traffic descriptor
profile pointer for
upstream:
Traffic descriptor
profile pointer for
downstream:
37
15.5)
Interworking
option:
Unstructured TDM.
MAC bridge LAN.
Reserved for future use.
IP data service.
Video return path.
802.1p mapper.
Downstream broadcast.
MPLS data service.
if interworking option = 0
if interworking option = 1
if interworking option = 3
if interworking option = 4
if interworking option = 5
if interworking option = 6
if interworking option = 7
Null pointer
Null pointer
15.6)
38
16)
Add the following new attribute at the end of the attributes list:
Dynamic filtering
ageing time:
17)
This attribute specifies the age of dynamic filtering entries in the bridge
database, after which unrefreshed entries are discarded. In accordance
with [IEEE 802.1D] clause 7.9.2 and [IEEE 802.1Q] clause 8.8.3, the
range is 10..1 000 000 seconds, with a resolution of 1 second and a
default of 300 seconds. (R, W, Set-by-create) (optional) (4 bytes)
18.1)
This attribute identifies the type of termination point associated with this
MAC bridge port. Valid values are:
1
2
3
4
5
6
7
8
9
10
11
Revise the descriptions of the two following attributes to read as shown (change GEM traffic
descriptor to traffic descriptor):
Outbound TD
pointer:
This attribute points to a traffic descriptor that limits the traffic rate
leaving the MAC bridge. (R, W) (optional) (2 bytes)
Inbound TD
pointer:
This attribute points to a traffic descriptor that limits the traffic rate
entering the MAC bridge. (R, W) (optional) (2 bytes)
18.3)
39
18.4)
Alarm
Description
Port blocking
1..207
Reserved
208..223 Vendor-specific alarms
Not to be standardized
NOTE 2 To determine the state of a MAC bridge port, the OLT can read the port state attribute of the
MAC bridge port designation data.
19)
Addition of an action in clause 9.3.6, MAC bridge port filter table data
Addition of two code points in clause 9.3.10, 802.1p mapper service profile
TP pointer points to
1
2
3
4
5
6
7
8
This attribute identifies the type of termination point associated with the
mapper.
0
1
2
3
4
40
5
6
7
8
Addition of a code point in clause 9.3.12, VLAN tagging operation configuration data
This attribute specifies the type of the ME that is associated with this
VLAN tagging operation configuration data ME. Values are assigned in
accordance with the following list:
0
1
2
3
4
5
6
7
8
9
10
11
22.1)
This attribute identifies the type of the ME associated with this extended
VLAN tagging ME. Values are assigned as follows:
0
1
2
3
4
5
6
7
8
9
10
41
22.4)
Addition of an action
Reserved
Invalid EAPOL frames received
Reserved
EAP length error frames received
10
NOTE This number associates the TCA with the specified threshold value attribute of the threshold
data 1 managed entity.
24)
Reserved
Retransmission count
2..4
5
Reserved
Invalid radius packets received
NOTE This number associates the TCA with the specified threshold value attribute of the threshold data 1
managed entity.
25)
Revise the descriptions of the three following attributes to read as shown (change GEM traffic
descriptor to traffic descriptor).
Upstream unicast
flood rate pointer:
Upstream broadcast
rate pointer:
Upstream multicast
payload rate
pointer:
43
26)
27.1)
27.2)
Ranging from 0..7, this attribute permits CCM and LTM frames to be
explicitly prioritized, which may be needed if flows are separated, e.g.,
by 802.1p priority. The priority specified in this attribute is also used in
LTR frames originated by this MEP. The value 0xFF selects the 802.1ag
default, whereby CCM and LTM frames are transmitted with the highest
Ethernet priority available. (R, W, Set-by-create) (mandatory) (1 byte)
The test operation causes the MEP to originate one or more loopback
messages (LBMs) or a linktrace message (LTM) in accordance with the
message format defined in clauses II.2.27 and II.2.45 (baseline format)
and clauses II.3.27 and II.3.45 (extended format).
The link trace test returns its results in a general purpose buffer ME,
which must have been created in advance by the OLT. (The general
purpose buffer is designated by a pointer in the test message itself.) Upon
completion of the linktrace operation, the general purpose buffer contains
a sequence of LTR entries in the order they were received:
This attribute specifies the type of termination point associated with this
IP port.
1
2
3
4
5
6
7
8
9
44
10
IP options:
This attribute is a bit map that enables or disables IP related options. The
value 1 enables the option while 0 disables it. The default value of this
attribute is 0.
0x01 Enable DHCP
0x02 Respond to pings
0x04 Respond to traceroute messages
0x08 Enable IP stack
0x10..0x80 Reserved
(R, W) (mandatory) (1 byte)
Several attributes of this managed entity may be paired together into two categories, manual
settings and current values.
Manual settings
Current values
IP address
Current address
Mask
Current mask
Gateway
Current gateway
Primary DNS
Secondary DNS
While the IP stack is disabled, there is no IP connectivity to the external world from this managed
entity 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 default value 0.
(R, W) (mandatory) (4 bytes)
Mask:
The address used for IP host services, this attribute has default value 0.
(R, W) (mandatory) (4 bytes)
Gateway:
The default gateway address used for IP host services, this attribute has
default value 0. (R, W) (mandatory) (4 bytes)
Primary DNS:
The address of the primary DNS server, this attribute has default value 0.
(R, W) (mandatory) (4 bytes)
Secondary DNS:
The address of the secondary DNS server, this attribute has default value
0. (R, W) (mandatory) (4 bytes)
Rec. ITU-T G.984.4 (2008)/Amd.2 (11/2009)
45
Current address:
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 secondary
DNS:
31)
This attribute denotes the maximum frame size allowed across this
interface. Upon ME instantiation, the ONT sets the attribute to 1518.
(R, W) (mandatory for G-PON, optional for GbE) (2 bytes)
46
33)
This managed entity represents the data plane hand-off point in an ONT or ONU to a separate (nonOMCI) management domain. The virtual Ethernet interface point is managed by OMCI, and is
potentially known to the non-OMCI management domain. One or more Ethernet traffic flows are
present at this boundary.
Instances of this managed entity are automatically created and deleted by the ONT. This is
necessary because the required downstream priority queues are subject to physical implementation
constraints. The OLT may use one or more of the virtual Ethernet interface points created by the
ONT.
It is expected that the ONT would create one virtual Ethernet interface point for each non-OMCI
management domain.
Relationships
An instance of this managed entity is associated with an instance of a virtual Ethernet interface
between OMCI and non-OMCI management domains.
Attributes
Managed entity id:
Administrative
state:
This attribute locks (1) and unlocks (0) the functions performed by this
managed entity. When the administrative state is set to lock, all user
functions of this UNI are blocked, and alarms, TCAs and AVCs for this
managed entity and all dependent managed entities are no longer
generated. (R, W) (mandatory) (1 byte)
Operational state:
Inter-domain name:
TCP/UDP pointer:
47
IANA assigned port: This attribute contains the TCP or UDP port value, as assigned by IANA
for the management protocol associated with this virtual Ethernet
interface. This attribute is to be regarded as a hint, not as a requirement
that management communications use this port; the actual port and
protocol are specified in the associated TCP/UDP config data managed
entity. If no port has been assigned, or if the management protocol is free
to be chosen at run-time, this attribute should be set to 0xFFFF. (R)
(mandatory) (2 bytes)
Actions
Get, set
Notifications
Attribute value change
Number
0..1
2
3
4..16
Description
Operational state
Alarm
Number
Alarm
1..207
208..223
Reserved
Vendor specific alarms
34)
Description
Indicates a failure of the connecting function. May be used to
signal faults from the non-OMCI management domain into
OMCI.
Not to be standardized
Revision of a Note in clause 9.7.1, Physical path termination point xDSL UNI part 1
35)
38)
Modification of clause 9.7.17, VDSL2 line inventory and status data part 2
41)
49
42)
42.1)
Delete the second paragraph of the introductory text of this clause in ITU-T G.984.4 (2008), i.e.,
the text that reads as follows:
An instance of this managed entity is created by the OLT before the creation of an associated
interworking termination point (see clause 9.2.4, GEM interworking termination point).
42.2)
43.1)
Revision of an attribute
0
1
2
Ethernet, MEF8.
UDP/IP.
MPLS.
Replacement of an attribute
Replace the Near-end IP info attribute with the north-side pointer attribute as follows:
Near-end IP info:
When the pseudowire service is transported via IP, this attribute points to
an instance of the TCP/UDP config data managed entity. The default
value 0 is applicable if the pseudowire is not transported via IP. (R, W,
Set-by-create) (mandatory for IP transport) (2 bytes)
North-side pointer:
50
44)
TP type:
This attribute points to the instance of the TP associated with this MPLS
PW TP. The type of the associated TP is determined by the TP type
attribute. (R, W, Set-by-create) (mandatory) (2 bytes)
MPLS label
indicator:
Upstream only
Downstream only
Bidirectional
This attribute specifies the label of the inner MPLS pseudowire upstream.
The attribute is not meaningful for unidirectional downstream PWs. (R,
W, Set-by-create) (mandatory) (4 bytes)
MPLS PW
downlink label:
MPLS PW EXP:
This attribute specifies the inner MPLS EXP value in the upstream
direction. The attribute is not meaningful for unidirectional downstream
PWs. (R, W, Set-by-create) (mandatory) (1 byte)
51
MPLS tunnel
direction:
Upstream only
Downstream only
Bidirectional
This attribute specifies the (outer) label for the downstream MPLS
tunnel. If the MPLS tunnel is upstream only, this attribute should be set
to 0. (R, W, Set-by-create) (mandatory) (4 bytes)
This attribute specifies the EXP value of the upstream MPLS tunnel. If
the MPLS tunnel is downstream only, this attribute should be set to 0. (R,
W, Set-by-create) (mandatory for double MPLS labelled case) (1 byte)
Actions
Create, delete, get, set
Notifications
None.
45)
45.1)
Revision of an attribute
45.2)
Revision of an action
Request that the ONT perform one or more MLT tests or a dial tone
make/break test. Vendor-specific tests are also supported by the test and
test result message layouts in clauses II.2.27 and II.2.45 (baseline
message format), and in clauses II.3.27 and II.3.45 (extended message
format).
46)
46.1)
52
This attribute specifies the tone and text to be presented to the subscriber
upon reception of various SIP messages (normally 4xx, 5xx, 6xx
message codes). The table is a sequence of entries, each of which is
defined as follows:
SIP response code (2 bytes): This field is the index into the SIP response
table. When a set operation is performed with the value 0 in this field, the
table is cleared.
Tone (1 byte): This field specifies one of the tones in the tone pattern
table of the associated VoIP application service profile. The specified
tone is played to the subscriber.
Text message (2 bytes): This field is a pointer to a large string that
contains a message to be displayed to the subscriber. If the value of this
field is a null pointer, text pre-associated with the tone may be displayed,
or no text at all.
(R, W) (optional) (N * 5 bytes)
SIP option transmit
control:
This Boolean attribute specifies that the ONT is (true) or is not (false)
enabled to transmit SIP options. The default value is false. (R, W, Set-bycreate) (optional) (1 byte)
This attribute specifies the format of the URI in outgoing SIP messages.
The default value 0 specifies TEL URIs; the value 1 specifies SIP URIs.
Other values are reserved. (R, W, Set-by-create) (optional) (1 byte)
46.2)
Addition of an action
Revise the description of the User protocol pointer attribute to read as follows (underlined text is
new):
User protocol
pointer:
48)
48.1)
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)
53
48.2)
This attribute specifies the power level of DTMF digits that may be
generated by the ONT toward the subscriber set. It is a 2s complement
value referred to 1 mW at the 0 TLP (dBm0), with resolution 1 dB. The
default value 0x8000 selects the ONT's internal policy. (R, W, Set-bycreate) (optional) (2 bytes)
DTMF digit
duration:
Hook flash
minimum time:
Hook flash
maximum time:
54
This attribute is a table each of whose entries specifies an event for which
a tone is defined. If the tone can be synthesized by a sequence of
complex tones and silence, the event refers to an entry in the tone pattern
table. Otherwise, the event refers to a file name that is expected to be
recognized by the ONT environment. Each entry in the tone event table is
a vector comprising the following components:
Event (1 byte): This component is an enumeration of the events for
which a tone may be defined. The event component also serves as the
index for the table. A set operation to event 0 causes the table to be
cleared.
Value
Tone event
Busy
Confirmation
Dial
Message waiting
Reorder
Stutter dial
Call waiting 1
10
Call waiting 2
11
Call waiting 3
12
Call waiting 4
13
Alerting signal
14
Special dial
15
Special info
16
Release
17
Congestion
Rec. ITU-T G.984.4 (2008)/Amd.2 (11/2009)
55
Value
Tone event
18
User defined 1
19
User defined 2
20
User defined 3
21
User defined 4
22..32
Reserved
33
Intrusion
34
Dead tone
35..223
Reserved
224..255
Tone pattern (1 byte): This component specifies an entry point into the
tone pattern table attribute, to be invoked when the specified event
occurs. The value 0 indicates that no tone from the tone pattern table is to
be played.
Tone file (2 bytes): This component points to a large string managed
entity that contains the path and name of a file containing a codec
sequence to be played out. If no file is found after traversing these links,
no tone is played. The behaviour is unspecified if both tone pattern and
tone file are specified.
Tone file repetitions (1 byte): This component specifies the number of
times the tone file is to be repeated. The value 0 means that the file is to
be repeated indefinitely until terminated by some external event such as
call abandonment.
Reserved (2 bytes)
(R, W) (optional) (N * 7 bytes)
Ringing pattern
table:
56
This attribute is a table each of whose entries specifies an event for which
a ringing sequence is defined. If the ringing sequence can be generated as
a sequence of power ringing and silent intervals, the event refers to an
entry in the ringing pattern table. Otherwise, the event refers to a file
name that is expected to be recognized by the ONT environment. Each
entry is a vector comprising the following components:
Event (1 byte): This component is an enumeration of the events for
which a ringing sequence may be defined. The event component also
serves as the index for the table. A set operation with the value 0 in this
field causes the table to be cleared.
Value
Tone event
Default
Splash
3..223
224..255
Reserved
Vendor specific codes, not to be standardized
Addition of an action
57
49)
Attended call
transfer:
50)
52)
RTP errors
Maximum jitter
Buffer underflows
Buffer overflows
Request that the ONT perform one or more MLT tests. See test and test
result message layouts in clauses II.2.27 and II.2.45 (baseline message
format) and in clauses II.3.27 and II.3.45 (extended message format).
53)
53.1)
59
may be changed. The OMCI set command must contain four bytes to match the
attribute size, but the ONT must ignore all except the second byte.
If flexible configuration is not supported, the ONT should reject an attempt to
set the related port with a parameter error result-reason code.
Traffic scheduler-G
pointer:
53.4)
Revise the following attribute description to read as shown (change GEM traffic descriptor to
traffic descriptor).
Drop precedence
colour marking:
This attribute specifies how the drop precedence is marked on the ingress
packets to the priority queue. The default value is 0.
0
1
2
3
4
5
6
7
54)
54.1)
60
54.2)
Null
HOL (head of line)
WRR (weighted round robin)
55)
56.1)
Addition of a Note
Add the following Note at the end of the Administrative state attribute description:
NOTE PPTP MEs also have an administrative state attribute. The user port is unlocked only if both
administrative state attributes are set to unlocked.
56.2)
An ONT may support the ability for some or all of its PPTPs to be
managed either directly by OMCI or from non-OMCI management
environment such as TR-69. This attribute advertises the ONT's
capabilities for each PPTP.
This attribute is an enumeration with the following code points:
0
1
2
OMCI only
Non-OMCI only. In this case, the PPTP may be visible to OMCI,
but only in a read-only sense, e.g., for PM collection
Both OMCI and non-OMCI
61
Non-OMCI
management
identifier:
57)
58)
This attribute specifies the validation scheme used when the ONT
validates a challenge. Validation schemes are defined as follows:
1
Validate using MD5 digest authentication as defined in
[IETF RFC 2069] (recommended)
Revise it to read:
Validation scheme:
This attribute specifies the validation scheme used when the ONT
validates a challenge. Validation schemes are defined as follows:
1
Validate using MD5 digest authentication as defined in
[IETF RFC 2617] (recommended)
59)
Delete the last sentence of the first paragraph of the relationships section, i.e., the text in
ITU-T G.984.4 (2008). The resulting paragraph should read as follows:
An instance of this managed entity may be related to multiple instances of performance monitoring
history data type managed entities.
60)
62
61)
61.1)
File transfer trigger: This attribute causes the file transfer to begin. If a given set operation
writes values to several attributes of this managed entity, the ONT should
apply the file transfer trigger after updating all other attributes. Some
operations may not be applicable to some files; the ONT should deny
commands that request unsupported actions. (R, W) (mandatory) (1 byte)
Value Meaning
0
1
2
3
4
5..255
MC GEM IWTP
pointer:
Reserved
Initiate file download (to the ONT)
Initiate file upload (from the ONT)
Abort current file transfer
Delete target file
Reserved
Revise it to read:
Network address
pointer:
63
File transfer trigger: This attribute causes the file transfer to begin. If a given set operation
writes values to several attributes of this managed entity, the ONT should
apply the file transfer trigger after updating all other attributes. Some
operations may not be applicable to some files; the ONT should deny
commands that request unsupported actions. (R, W) (mandatory) (1 byte)
Value Meaning
0
1
2
3
4
5
Reserved
Initiate file download (to the ONT)
Initiate file upload (from the ONT)
Abort current file transfer
Delete target file
Perform a directory listing operation. The scope of the directory
is not specified; at the vendor's option, the listing may be filtered
by matching some or all of file type, file instance and local file
name attributes.
6..255 Reserved
This attribute is a pointer that specifies a unicast or multicast GEM
interworking termination point, depending on whether the transfer
protocol to be used is unicast or multicast. (R, W) (optional) (2 bytes)
GEM IWTP
pointer:
61.2)
Addition of an AVC
1..6
7
8.. 10
11
N/A
File transfer status
Reserved
Directory listing table
12..16
Reserved
62)
Description
64
The generic status portal ME uses two table attributes to convey status and configuration from a
non-OMCI managed domain to OMCI. Each of these attributes uses an XML document to present
this information. These XML documents are not required to be understood by the OLT or EMS.
The schema for the documents may be used in the creation of tools that parse and interpret the
contents of the document.
Relationships
One instance of this ME is created by the OLT for each separate non-OMCI management domain
whose information is desired to be visible.
Attributes
Managed entity ID:
Status document
table:
Configuration
document table:
This attribute governs the rate at which the generic status portal generates
attribute value change notifications. The default value 0 disables AVCs,
while the highest value 3, which may be useful for debugging, generates
an AVC on every change seen in the non-OMCI management domain.
As a guideline, the value 1 should collect changes into not more than one
notification in ten minutes, while value 2 should generate an AVC not
more than once per second. (R, W, Set-by-create) (optional) (1 byte)
Actions
Create, delete
get, get next
65
Notifications
Attribute value change
Number
1
Configuration document
table
3..16
63)
Description
Indicates an update to the status document table from a nonOMCI interface. Because the attribute is a table, the AVC
contains no information about its value. The OLT must use the
get, get next action sequence if it wishes to obtain the updated
attribute content.
Indicates an update to the configuration document table from a
non-OMCI interface. Because the attribute is a table, the AVC
contains no information about its value. The OLT must use the
get, get next action sequence if it wishes to obtain the updated
attribute content.
Reserved
Revise clause 9.13.3 to read as follows. The text in existing clause 9.13.3 after the administrative
state attribute remains unchanged:
This managed entity models debug access to the ONT from any physical or logical port, for
example via a dedicated local craft terminal UNI, via ordinary subscriber UNIs, or via the IP host
config ME.
The ONT automatically creates an instance of this managed entity per port:
when the ONT has an LCT port built into its factory configuration;
when a cardholder provisioned for plug-and-play is equipped with a circuit pack of LCT
type. Note that the installation of a plug-and-play card may indicate the presence of LCT
ports via equipment ID as well as its type, and indeed may cause the ONT to instantiate a
port mapping package that specifies LCT ports;
when the ONT supports debug access through some other physical or logical means.
The ONT automatically deletes an instance of this managed entity when a cardholder is neither
provisioned to expect an LCT circuit pack, nor is it equipped with an LCT circuit pack, or if the
ONT is reconfigured in such a way that it no longer supports debug access.
LCT instances are not reported during a MIB upload.
Relationships
An instance of this managed entity is associated with an instance of a real or virtual circuit pack
managed entity classified as LCT type. An instance of this managed entity may also be associated
with the ONT as a whole, if the ONT supports debug access through means other than a dedicated
physical LCT port.
Attributes
Managed entity id:
66
Administrative
state:
64)
This attribute locks (1) and unlocks (0) the functions performed by this
managed entity. When the administrative state is set to lock, debug
access through all physical or logical means is blocked, except that the
operation of a possible ONT remote debug ME is not affected.
Administrative lock of ME instance 0 overrides administrative lock of
any other PPTP LCT UNIs that may exist. Selection of a default value
for this attribute is outside the scope of this Recommendation. (R, W)
(mandatory) (1 byte)
65)
OLT crypto
capabilities:
(lsb=1, msb=128)
HMAC-SHA-256
HMAC-SHA-512
Reserved
67
OLT random
challenge table:
This attribute specifies the random challenge issued by the OLT during
authentication step 1. It is structured as a table, with each entry being
17 bytes. The first byte is the entry index, and the remaining 16 bytes are
the content of the entry. In normal use, the OLT will write all the entries
in the table, and then trigger the ONT's processing of the entire table
using the OLT challenge status attribute. The table size is known by the
maximum index set by the OLT. The OLT can clear the table with a set
operation to index 0. (R, W) (mandatory) (17*N bytes)
OLT challenge
status:
If the OLT challenge status attribute is false and the OLT sets the
OLT challenge status attribute to true, the ONT begins
processing the contents of the OLT crypto capabilities and OLT
random challenge table using the selected cryptographic hash
algorithm.
The ONT initializes this attribute to the value false. (R, W) (mandatory)
(1 byte)
ONT selected crypto This attribute specifies the cryptographic capability selected by the ONT
capabilities:
in authentication step 2. Its value specifies one of the bit positions that
has the value 1 in the OLT crypto capabilities attribute. (R) (mandatory)
(1 byte)
ONT random
challenge table:
68
This attribute specifies the random challenge issued by the ONT during
authentication step 2. It is structured as a table, with each entry being 16
bytes of content. Once the OLT triggers a response to be generated using
the OLT challenge status attribute, the ONT generates the response, and
then writes the table (in a single operation). The AVC generated by this
attribute signals the OLT that the challenge is ready, so that the OLT can
commence a get/get-next sequence to obtain the table's contents. (R)
(mandatory) (16*P bytes)
ONT authentication
result table:
OLT authentication
result table:
If the OLT result status is false and the OLT sets the OLT result
status to true, the ONT begins processing the contents of the
OLT authentication result table using the specified algorithm.
69
ONT authentication
status:
When the ONT authentication status has the value 3, encryption keys
exchanged in the TC layer will be encrypted using the session key. The
OLT should check the value of this attribute before initiating a key
switch.
(R) (mandatory) (1 byte)
Session key name:
(PSK
OLT
random_challenge
ONT
70
Notifications
Attribute value change
Number
1..4
Description
Reserved
7..9
Reserved
10
11..16
Reserved
Supplementary information
This managed entity contains the facilities to perform a conventional three-step hash-based
authentication sequence found in [b-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:
Message 1: (Peer 1 peer 2) my_cryptographic_capabilities, random_challenge_1
Message 2: (Peer 2 peer 1): selected_cryptographic_capabilities, random_challenge_2, MsgHash
(PSK,
selected_cryptographic_capabilities,
random_challenge_1,
random_challenge_2,
peer_1_identity)
Message 3: (Peer 1 peer 2): MsgHash (PSK, selected_cryptographic_capabilities,
random_challenge_2, random_challenge_1, peer_2_identity)
Where:
MsgHash () is a keyed hash function of the message
PSK is the pre-shared key known only to the peers of the session
Peer_1_identity is always "0x0000 0000 0000 0000"
Peer_2_identity is the ONT serial number
The prerequisite is the availability of a pre-shared secret: PSK. A PSK of 128 bits simplifies the
application of security algorithms based on AES-128 (e.g., AES-CMAC-128). A PSK is associated
with a particular ONT and is stored at that ONT and at the operator infrastructure. On the operator
side, the PSK for a particular ONT might be stored in the physically-connected OLT, or at a central
server that the OLT accesses during authentication. Configuration of the PSK into the ONT and into
the operator infrastructure may be done in any manner that satisfies these requirements.
In OMCI, the authentication message sequence follows the steps illustrated in Figure 9.13.11-1.
71
OLT
ONT
Get_response [ ]
c)
d)
e)
f)
73
NOTE 1 Timer T1 ONT challenge pending timer. Timer T1 is used to abort an unsuccessful OLT
authentication attempt by limiting the overall time an ONT can remain in state S2. The recommended value
of T1 is 3 seconds.
NOTE 2 Timer T2 Authentication failure timer. Timer T2 is used to assert a mismatch of the session key
condition by limiting the time an ONT can remain in state S4. The recommended value of T2 is 1 second.
NOTE 3 Timer T3 Authentication error timer. Timer T3 is used to assert a failure of authentication
condition by limiting the time an ONT can remain in state S5. The recommended value of T3 is 1 second.
74
Revise the second paragraph of the introductory material, and add a Note. The second paragraph,
with the Note, then reads as follows:
The RE model includes one built-in ONT, which serves for management of the RE itself, as well as
for optional subscriber or craft UNIs. The ONT is therefore able to use any of the managed entities
defined elsewhere in this Recommendation, including the ANI-G and T-CONT MEs, which
represent the built-in ONT's individual uplink.
NOTE Although the built-in management ONT is physically contained within a physical reach extender
equipment, the management model perspective is that the ONT software controls the entire equipment. In
terms of the model, therefore, the management ONT contains the reach extender equipment and
functionality.
67)
Revise the Per burst receive signal level table attribute description to read as follows:
Per burst receive
signal level table:
This table attribute reports the most recent measurement of received burst
upstream optical signal level at 1310 nm. Each table entry has a two-byte
ONU-ID field (Note) (most significant end), and a two-byte power
measurement field. The power measurement field is a 2s complement
integer referred to 1 mW (i.e., dBm), with 0.002 dB granularity. (R)
(optional) (4N bytes, where N is the number of distinct ONTs connected
to the S'/R' interface.)
NOTE In its initial definition, only one byte was assigned to ONU-ID. This
was changed to two bytes in anticipation that future PON technologies may
support a split ratio greater than 256.
75
68)
Revise the Per burst receive signal level table attribute description to read as follows:
Per burst receive
signal level table:
This table attribute reports the most recent measurement of received burst
upstream optical signal level at 1310 nm. Each table entry has a two-byte
ONU-ID field (Note) (most significant end), and a two-byte power
measurement field. The power measurement field is a 2s complement
integer referred to 1 mW (i.e., dBm), with 0.002 dB granularity. (R)
(optional) (4N bytes, where N is the number of distinct ONTs connected
to the S'/R' interface.)
NOTE In its initial definition, only one byte was assigned to ONU-ID. This
was changed to two bytes in anticipation that future PON technologies may
support a split ratio greater than 256.
69)
11.1
Two OMCI message formats are defined in clause 11.2, the baseline and the extended message
formats.
Baseline messages have 48-byte fixed length PDUs, while extended messages have variable length
PDUs. A receiver that does not support extended messages may therefore reject extended messages
based on nothing more than their length.
Both baseline and extended messages carry an I.363.5 CRC code in their final four bytes. This
facilitates an ad hoc recovery of both message types by a receiver.
Baseline and extended messages are distinguished from one another by the device identifier field,
which is in the same byte location in both message types. Baseline messages are addressed to
device identifier 0x0A, while extended messages employ device identifier 0x0B.
All ONTs and all OLTs are required to support the baseline format. During initialization, and
whenever the ONT is re-ranged onto the PON, both entities use baseline format to establish
communications and to negotiate their capabilities. If both endpoints support extended messages,
they may or may not choose to conduct all or some subsequent communications in the extended
message set. Baseline messages may be used for any transaction, that is, any exchange of one or
more related messages such as a get/get-next sequence.
Figure 11.1-1 illustrates the negotiation and the exchange of messages in one or the other message
formats.
76
11.2
Packet format
Each OMCI protocol packet is encapsulated directly in one GEM frame, which may be fragmented
in accordance with normal fragmentation rules. The GEM frame header contains the port ID of the
OMCC for the addressed ONT, with a header PTI of 000 or 001.
77
Two message formats are defined, a baseline format and an extended format. The following clauses
discuss the details.
The baseline packet format is shown in Figure 11.2-1. This fixed length 48-byte format reflects the
ATM heritage of PON.
Transaction
correlation
identifier
(2 bytes)
Message
type
(1 byte)
Device
identifier
(1 byte)
Message
identifier
(4 bytes)
Message
contents
(32 bytes)
OMCI
trailer
(8 bytes)
Figure 11.2-1 ONT management and control protocol baseline packet format
Figure 11.2-2 shows the extended packet format. The packet has variable length, up to 1980 bytes.
Transaction
correlation
identifier
(2 bytes)
Message
type
(1 byte)
Device
identifier
(1 byte)
Message
identifier
(4 bytes)
Message
contents
length
(2 bytes)
Message
contents
(variable)
CRC
(4 bytes)
Figure 11.2-2 ONT management and control protocol extended packet format
The following clauses specify each field of these messages.
11.2.1 Transaction correlation identifier
The transaction correlation identifier is used to associate a request message with its response
message. For request messages, the OLT selects a transaction identifier. A response message carries
the transaction identifier of the message to which it is responding. The transaction identifier of
messages generated autonomously by the ONT is 0.
As explained in clause 11.4.1, and for the baseline message format only, the most significant bit of
the transaction correlation identifier indicates the priority of the message. The following coding is
used: 0 = low priority, 1 = high priority. The OLT decides whether a command should be executed
with low or high priority. The extended message format does not recognize priorities.
The remainder of the transaction identifier may be arbitrary, but should be chosen to avoid the
possibility of ambiguous responses from ONTs.
11.2.2 Message type
The message type field is subdivided into four parts. These are shown in Figure 11.2.2-1.
DB
AR
AK
1
MT
78
Bit 8, the most significant bit, is reserved (DB). This bit is always 0. This bit is not used in the
baseline message format, but is available for possible future use in the extended message format.
Bit 7, acknowledge request (AR), indicates whether or not the message requires an
acknowledgement. An acknowledgement is a response to an action request, not a link layer
handshake. If an acknowledgement is expected, this bit is set to 1. If no acknowledgement is
expected, this bit is 0. In messages sent by the ONT, this bit is always 0.
Bit 6, acknowledgement (AK), indicates whether or not this message is an acknowledgement to an
action request. If a message is an acknowledgement, this bit is set to 1. If the message is not a
response to a command, this bit is set to 0. In messages sent by the OLT, this bit is always 0.
Bits 5..1, message type (MT), indicate the message type, as defined in Table 11-1. Values not
shown in the table are reserved.
Table 11-1 OMCI message types
MT
Type
Purpose
AK
Increment
MIB
data sync
Create
Yes
Yes
Delete
Yes
Yes
Set
Yes
Yes
Get
Yes
No
11
Yes
No
12
Yes
No
13
MIB upload
Yes
No
14
Yes
No
15
MIB reset
Yes
No
16
Alarm
Notification of an alarm
No
No
17
Attribute value
change
No
No
18
Test
Yes
No
19
Start software
download
Yes
Yes
20
Download section
(Note)
No
21
End software
download
Yes
Yes
22
Activate software
Yes
Yes
23
Commit software
Yes
Yes
24
Synchronize time
Yes
No
25
Reboot
Yes
No
26
Get next
Yes
No
27
Test result
No
No
79
Type
Purpose
AK
Increment
MIB
data sync
28
Yes
No
29
Set table
Yes
Yes
NOTE The download section action is acknowledged only for the last section within a window. See
clause I.2.7.
80
Managed entity
ONTB-PON
ONT data
Cardholder
Circuit pack
Software image
UNIB-PON
TC AdapterB-PON
10
Managed entity
11
12
13
14
15
AAL1 profileB-PON
16
AAL5 profile
17
18
19
AAL2 profile
20
21
22
(Reserved)
23
24
25
VP network CTP
26
ATM VP cross-connection
27
Priority queueB-PON
28
29
30
31
32
33
34
35
36
37
38
ANI
39
PON TC adapter
40
41
42
Threshold dataB-PON
43
Operator specific
44
Vendor specific
45
46
47
81
82
Managed entity
48
49
50
51
52
53
54
Voice CTP
55
56
57
58
59
60
61
62
63
Traffic scheduler
64
T-CONT buffer
65
66
67
68
69
70
71
72
73
74
IP route table
75
IP static routes
76
77
78
79
80
81
(Reserved)
82
83
84
Managed entity
85
ONUB-PON
86
ATM VC cross-connection
87
VC network CTPB-PON
88
VC PM history data
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
83
84
Managed entity
122
123
124
125
126
127
128
129
130
131
OLT-G
132
133
134
135
136
137
Network address
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
Large string
158
Managed entity
159
160
161
162
163
164
165
166
167
168
169
170
171
172..239
240-255
256
ONT-G
257
ONT2-G
258
ONU-G
259
ONU2-G
260
261
PON TC adapter-G
262
T-CONT
263
ANI-G
264
UNI-G
265
266
267
268
269
VP network CTP-G
270
VC network CTP-G
271
272
273
Threshold data 1
274
Threshold data 2
275
276
277
Priority queue-G
85
86
Managed entity
278
Traffic scheduler-G
279
Protection data
280
281
282
283
284
285
286
287
OMCI
288
Managed entity
289
Attribute
290
291
292
293
294
TU CTP
295
296
297
298
299
300
301
302
Dot1ag MEP
303
304
305
306
307
Octet string
308
309
310
311
312
313
RE ANI-G
314
Managed entity
315
RE upstream amplifier
316
RE downstream amplifier
317
RE config portal
318
319
320
321
322
323
324
325
326
327
328
329
330
331
ONT-E
332
333
334-65279
65280-65535
87
Limited by
Maximum
size, bytes
Create
34
Get response
25
Set
30
Get response
25
Extended messages are limited by the total size of the PDU. For backward compatibility, attribute
definitions remain within the size limits of baseline messages, but more attributes may be contained
within a single extended message. The following considerations apply to baseline messages only.
The larger PDU eliminates the possibility of message length violation in the extended message set.
It is important that OLT and ONT implementations take size limits into account. For example, it is
easy to form a (baseline) get command that asks the ONT to return more attributes than can fit into
a (baseline) get response message. If the OLT asks for too many attributes in a get request, the ONT
may respond with as many attributes as fit into the space available. From the attribute-present mask,
the OLT can parse the attributes that were sent correctly, and can issue another get to retrieve the
attributes that did not fit.
While this is the preferred behaviour, an alternate interpretation may be that the ONT would return
a parameter error code when it receives a (baseline) get request whose response does not completely
fit into one (baseline) get response message. For the sake of interoperability, the expected behaviour
between an OLT and ONT with different interpretations is provided below:
Case 1:
The ONT reports a parameter error, and the OLT expects a partial list. If this happens, the OLT
should react by simplifying its get request. The ONT then responds without an error.
Case 2:
The ONT provides a partial list, while the OLT expects to get an error. The OLT receives a normal
message and processes it normally. The OLT asks again for any attributes it did not get.
11.2.10 Test result enumeration
Test actions can return measurements of various physical parameters in vendor-specific ways.
Table 11-4 identifies parameters that may be of interest, with enumerated values to represent them
in the test response message defined in Appendix II.
88
The resolution shown in the following descriptions merely indicates the weight attached to the least
significant bit, and is not intended to impose requirements for precision or accuracy of the measured
value.
Table 11-4 Codes to represent measured values
Type
Parameter
Representation
Low voltage, V
Video level, dB
Video level, V
10
11
12
Temperature, degrees C
13..239
240-254
255
11.3
Reserved
NOTE Prioritized message handling is defined only for the baseline message set. In the context of the
extended message set, this clause should be read with the understanding that there is only one priority class.
The flow control/error recovery procedures for message exchange over the OMCC are based on a
simplex acknowledged transaction stop-and-wait mechanism that can be extended to support
concurrent execution of multiple transaction requests of different priority levels. These flow control
procedures ensure that a low level acknowledged transaction request transmitted from the OLT has
been properly received and processed to completion by the ONT before the next message of the
same priority level is sent by the OLT. The stop-and-wait protocol uses the transaction correlation
identifier field, retry counter(s), and applicable transaction request timer(s) to control the message
flow rate while relying on a CRC calculation to verify the data integrity of all received messages.
A transaction request timer Ti with expiration time Tmaxi is started when a transaction request
message of priority level i is sent to an ONT, and is stopped upon receipt of an acknowledgement
message containing the same transaction correlation identifier value. If a valid acknowledgement
message is not received by the OLT after timer Ti expires, the OLT re-sends the original transaction
request message.
A retransmitted acknowledged transaction request message carries the same transaction correlation
ID as the original message. Each time an acknowledged transaction request message is
retransmitted by the OLT, the transmitter increments the retry counter Ri (the counter associated
with priority level i acknowledged transaction requests). When a retry counter Ri (initialized to 0
Rec. ITU-T G.984.4 (2008)/Amd.2 (11/2009)
89
upon the first transmission of each new command) reaches the maximum retry value, Rmaxi, the
transmitter stops re-transmitting the message and declares an OMCC link state error.
These timers (Ti) and retry counters (Ri) are only maintained within the OLT controller and do not
exist within the ONT. Threshold values for timer expiration (Tmaxi) and number of retries (Rmaxi)
are not subject to standardization. It is suggested that the default threshold values of both Tmax and
Rmax be independently configurable for each priority level. The default value for Tmax1 (i.e., high
priority threshold) should account for the typical message transmission delay plus the command
message response time.
These flow control/error recovery procedures are illustrated in Figure 11.3-1 for a case where the
OMCC link is not permanently broken. First the OLT sends an acknowledged transaction request
(message 1) with priority level 0. Subsequently (while message 1 is still outstanding), the OLT
issues an additional acknowledged transaction request (message 2) with priority level 1. Both of
these commands are received and executed with the associated response (acknowledgement
messages) returned to the OLT by the ONT. The acknowledgement for message 1 is received by the
OLT in time; however, the response to message 2 is lost and never received. The OLT detects that
something went wrong because timer T1 expires, and the OLT therefore retransmits the original
command (message 2). From the identical transaction ID, the ONT detects that this retransmitted
command is identical to the last received command (for priority level 1) and therefore does not
re-execute it. The ONT simply retransmits the original response from the previous execution of
message 2, which reaches the OLT in time.
The final transaction in the example is the case where the OLT sends an acknowledged transaction
request (message 3) with priority level 0, but the message itself gets lost and is never properly
received by the ONT. After the associated timer (T0) expires, the OLT retransmits the command
and now all goes well.
90
91
OLT
Start T0
ONT
Expiry T0
Increment R0
Expiry T0
(T0 > Tmax 0)
Resend message 4,
Restart T0,
Increment R0
Expiry T0
(T0 > Tmax 0)
Increment R0
(R 0 > Rmax0)
Declare Link Error
T1534140-99
This clause specifies the behaviour of the ONT more precisely than in the preceding clause with
respect to the prioritized request mechanism of the OMCC.
Conceptually, the way the ONT handles the OMCC requests can be illustrated by referring to the
dual priority level implementation example shown in Figure 11.4.1-1.
When the ONT receives a GEM frame via the GEM port associated with the management channel,
it shall calculate the CRC and compare it with the value found in the OMCI trailer. If the values do
not match, the ONT shall discard the message. It is recommended that this event be logged by the
ONT and possibly communicated to the OLT by some out-of-band mechanism but, as far as the
protocol is concerned, the message is discarded silently.
Messages with a correct CRC are then placed into either of two distinct incoming FIFO-based
message queues, according to the high or low priority level of the associated command encoded in
the most significant bit of the transaction correlation identifier field. If the associated incoming
message queue is already full, the ONT must simply discard the message. It is recommended that
this event be logged by the ONT and possibly communicated to the OLT by some out-of-band
mechanism but, as far as the protocol is concerned, the message is discarded silently.
There are two distinct incoming command processing protocol entities, one associated with each
priority level, that serve messages sequentially from independent incoming FIFO queues. Each
protocol entity can execute concurrently. If a message is a one-way (unacknowledged) command,
92
the protocol entity simply executes the command. If a message is an acknowledged command, the
protocol entity must first look at the transaction correlation identifier. If it is not equal to the
transaction correlation identifier of the last executed command with the same priority level, the
protocol entity executes the command and places the response/acknowledgement, with an identical
transaction correlation identifier, in the outgoing FIFO queue of the same priority level. If the
transaction correlation identifier is equal to that of the last executed command with the same
priority level (the case where the OLT retransmits a command due to lack of proper
acknowledgement), the protocol entity does not actually execute the command but simply places the
response from the last execution of that command in the outgoing FIFO queue to re-send the
previous acknowledgement response. In both cases, the command processing protocol entity for a
given priority level should block until there is room in the associated outgoing FIFO queue for the
response message.
In the other direction, requests by ONT applications to send autonomous event notifications simply
result in the corresponding messages being directed to an event notification protocol entity for
transmission to the OLT. The event notification protocol entity forwards these event notification
messages to the low priority outgoing FIFO queue. In this case as well, the event notification
protocol entity should block until there is room in the low priority outgoing FIFO queue to hold the
notification message. The CRC generator removes messages from the outgoing FIFO queues using
a strict priority discipline (that is, the low-priority queue is served only when the high-priority
queue is empty), generates a CRC, formats the packet as either a baseline or an extended message,
depending on which form is in use, and transmits the message to the OLT.
93
70)
70.1)
70.2)
Common mechanisms
The revised content of this clause now appears in the G.984.4 implementers' guide [b-G.Imp984.4].
I.1.2
The revised content of this clause now appears in the G.984.4 implementers' guide [b-G.Imp984.4].
I.1.3
The revised content of this clause now appears in the G.984.4 implementers' guide [b-G.Imp984.4].
I.1.4
The revised content of this clause now appears in the G.984.4 implementers' guide [b-G.Imp984.4].
I.1.5
Table attributes
Normal attributes are coded such that they do not exceed the maximum OMCI attribute size, as
limited by the baseline message format. However, there are cases where attributes need to be larger
because they comprise arrays of data. In other cases, the attribute may be unstructured, but
nevertheless be too large to be represented as a conventional attribute. Both types of large attributes
are known as tables, and can be identified by the word table in their names.
A table entry may be short enough that more than one row would fit into a (baseline) set command.
However, the set command has no deterministic way to specify how many such rows are present.
Therefore, the set action is permitted to set only a single entry in the table, the size of which is
specified in clause 9 for the particular attribute in question.
94
The set operation on a table row is possible only when individual table entries have a fixed size that
does not exceed the maximum that can be conveyed in the (baseline) set message. A table attribute
with variable-length rows or longer fixed-length rows is restricted to being read-only.
An optional set table command is defined in the extended message set. Functionally, the set table
command is the equivalent of an ordered sequence of set commands, each directed to the same table
attribute of a given managed entity. As with the set command, table rows must have fixed length,
and because of the backward compatibility requirement, no table row may exceed the baseline
length limit.
The actual size of any given table attribute instance at any given time may be smaller than the
OMCI single-message limit. Regardless of its actual size, however, the following sequence governs
the retrieval of all table attributes.
Figure I.1.5-1 shows how the OLT retrieves a table attribute. The OLT sends a get command, just
as for any other attribute. The ONT latches a copy of the table for the anticipated get next sequence.
In the get response, the ONT returns, not the value of the table attribute, but a four-byte field
containing the table's size, expressed in bytes.
NOTE Zero is a valid size for many table attributes.
The OLT then requests the attribute data from the ONT via the appropriate number of get next
commands. There is no structure in the get next response; it simply regards the table as a byte
string.
95
OLT
ONT
NOTE N+1 is the number of get next commands as derived by the OLT to retrieve the complete table. For
baseline OMCI messages, Y is 29 bytes; for extended OMCI messages, Y = 1966 Bytes (1980 PDU size 14
Bytes of OMCI header).
96
If more than one bit is set in the get next command attribute mask, or if the specified attribute is not
a table, the ONT should respond with a parameter error result code.
In each get next command, the OLT generates a sequence number, starting from 0. The sequence
number resets to 0 for each attribute, even if successive attributes are part of the same managed
entity parent.
70.3)
Alarm reporting control allows for the suppression of alarms from physical path termination points
and cardholders, under the control of the management system. [ITU-T M.3100] completely
describes ARC from a generic viewpoint. OMCI provides for ARC functions using two attributes of
the parent managed entity: ARC and ARC_interval. These two attributes are described below.
ARC
This attribute allows the activation of alarm reporting control (ARC) for this PPTP or cardholder.
The attribute works in concert with the ARC_interval attribute. A value of 0 indicates disabled,
while a value of 1 indicates enabled. 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. Alarms are reported normally
in the ALM state. When the ARC attribute is set to enabled, the PPTP or cardholder is in the
ITU-T M.3100 NALM-QI state, in which alarms are suppressed.
The PPTP or cardholder moves from state ALM to state NALM-QI when the OLT changes the
ARC attribute to enabled. The PPTP or cardholder moves from the NALM-QI state to the ALM
state when either 1) the PPTP or cardholder is trouble free and the ARC_interval timer expires, or
2) the ARC attribute is set to disabled by the OLT. Continuation or recurrence of a fault resets the
timer. If the ARC_interval timer expires, the ONT sets the ARC attribute to disabled autonomously,
and sends an AVC to notify the OLT. Refer to [ITU-T M.3100] for a more extensive discussion.
The ARC_interval attribute can assume normal timing values of 0 to 254 minutes. The value 0
implies that a PPTP or cardholder in the NALM-QI state goes immediately to the ALM state upon
detection of a problem-free state. An ARC_interval value of 255 has the special meaning that the
timer never expires. The PPTP or cardholder remains in the NALM-QI state until the OLT sets the
ARC attribute to disabled. This behaviour is equivalent to the NALM state, which is another
generic behaviour of the ARC function in [ITU-T M.3100].
Note that there is no support for the NALM-TI sub-function in the OMCI system. (R,W) (optional)
(1 byte)
ARC_interval
This attribute defines the interval to be used with the ARC function for this PPTP. The values 0
through 254 give the duration in minutes for the NALM-QI timer. The special value 255 means that
the timer never expires. The default value is zero. (R, W) (optional) (1 byte)
ARC suppresses alarm reporting on the parent managed entity and all dependent entities, but does
not suppress the alarm conditions themselves. Therefore, if an alarm condition develops during an
ARC interval, the ONT should maintain the internal indication of the alarm, and if the OLT gets all
alarms regardless of ARC, it should be reported.
97
70.4)
Performance monitoring
This Recommendation defines a number of performance monitoring managed entities. They share a
number of characteristics, as described here. Exceptions to the generic behaviour are defined in the
specific managed entity affected. Two groups of performance monitoring (PM) managed entities
are defined:
1)
Classical PM, whose members are identified by names containing the string, "performance
monitoring history data."
2)
Extended PM, whose members are identified by names containing the string, "extended
PM."
The remainder of this clause describes behaviour common to the two classes of PM MEs. The
subclauses then discuss aspects unique to each PM ME class.
All PM managed entities are created and deleted by the OLT.
Classical PM, and optionally extended PM, are based on the assumption of a continuing sequence
of 15-minute intervals. This sequence of 15-minute intervals is synchronized by the synchronize
time action, issued by the OLT against the ONT-G managed entity. The synchronize time action
establishes a 15-minute tick boundary and starts numbering the intervals from 0. The interval
number is returned in the interval end time attribute. In the PM ME template, the interval end time
is a single byte, which rolls over from 255 to 0.
The synchronize time action is the only mechanism guaranteed to reset either the phase or the
interval number. For example, neither ONT re-boot nor MIB reset can be expected to have these
effects (the performance monitoring consequence of the latter events is undefined). In the absence
of a synchronize time message, an ONT would be expected to maintain 15-minute intervals
asynchronously with the outside world, and with arbitrary interval end-time identifiers.
The ONT performs no archival; archival is the function of the OLT or a management system. In a
15-minute accumulation mode, the ONT conceptually has only two storage bins: a current
accumulator and a history bin. At 15-minute intervals, they switch roles. History is discarded at age
thirty minutes, when the previous history bin is initialized into its role as the new current
accumulator. The previous accumulator, now in its role as the history bin, retains its totals for
15 minutes, so that the OLT can upload them if desired.
In a 15-minute accumulation mode, the get action on a PM managed entity returns the values of
attributes in the history bin. An ONT may also support an optional action in this mode, get current
data. The effect of this action is to return the value of attributes in the current accumulator. When a
PM attribute is an average, it acquires a value only at the close of a 15-minute interval. The value
returned by a get current data operation is undefined (0xFF in every byte would be reasonable).
OMCI supports PM thresholds and threshold crossing alerts (TCAs). Not all PM attributes need to
be thresholded; threshold definition and assignment is part of the specification of each PM attribute.
Most performance attributes are counters. During the accumulation interval, the PM managed entity
collects counter statistics in accordance with each PM attribute definition, and continuously
compares the accumulated values with any thresholds that may exist. When an accumulated value
first equals or exceeds the threshold, the ONT originates a TCA. At the end of the current
15-minute interval, the ONT issues a second TCA, cancelling the first.
If a counter PM attribute should fill up during the interval, it remains at its maximum possible
value, rather than rolling over.
98
When a PM attribute is an average, its value is computed only at the end of the interval. A TCA on
such an attribute can therefore be declared only at the end of the interval. The TCA would then be
immediately cleared as the accumulator was reset for the next interval. The definition of a given PM
attribute may specify different or more detailed behaviour.
When a PM attribute is a high-water mark, a TCA is declared when the monitored parameter equals
or exceeds the threshold value from below; conversely for a low-water mark attribute. There is no
general definition of the mechanism to clear the TCA, nor specification of delay or hysteresis to
avoid TCA storms for a parameter fluctuating near the threshold value. These should be defined in
the specification of each PM attribute.
It should be noted that TCAs are reported in OMCI alarm messages. There is no overlap between
TCA codepoints and alarm codepoints, because a given ME class declares either alarms or TCAs,
but not both.
Even when thresholding is defined on a PM managed entity, it is the option of the OLT whether to
provision it (see clause I.1.10 regarding optional pointers). The PM managed entity template
includes a placeholder for a pointer to an instance of the threshold data 1/2 managed entities.
Threshold configuration is performed by means of threshold data MEs, which are created and
deleted by the OLT. If no assigned threshold attribute number exceeds seven in a PM ME's
definition, the existence of a threshold data 2 ME is optional.
The control block of a PM ME contains persistent data that can be set by the OLT. Setting the value
of a control block attribute therefore increments MIB sync. In addition, the control block attribute
of a PM ME is included in MIB upload. Other PM attributes are transient and are not included in
MIB uploads.
Template for the definition of a PM ME
Existing PM generally follows the outline below. Significant exceptions are discussed here; an
implementation is advised to be aware that the definitions of individual MEs and attributes may
contain other exceptions.
<Description>
Relationships
<Relationships>
Attributes
Managed entity id:
This attribute identifies the most recently finished 15-minute interval. (R)
(mandatory) (1 byte)
Control block:
PM1:
PM2:
Actions
Create, delete, get, set
Rec. ITU-T G.984.4 (2008)/Amd.2 (11/2009)
99
PM1
PM2
NOTE This number associates the TCA with the specified threshold value attribute of the threshold data
1 managed entity.
The Threshold crossing alert column lists thresholded parameters in order. The Number column
merely identifies a row in the table and should not be considered significant.
The Threshold data counter column assigns threshold attributes of the threshold data 1 and if
required, the threshold data 2 MEs. In all cases, the assignment is monotonic, but existing PM
definitions may or may not skip a threshold attribute for each PM attribute that is to be thresholded.
In future PM definitions, it is recommended that threshold attributes be assigned sequentially,
without gaps. If, for example, the only thresholded PM attributes were the first, third and sixth in
order of PM ME definition, they would still be assigned threshold attributes 1, 2, 3.
I.1.9.1
Classical PM
In classical PM, the managed entity ID attribute takes the same value as the parent managed entity's
ME 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:
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:
Or:
Threshold data 1/2
id:
I.1.9.2
Extended PM
In extended PM, the control block attribute is defined to be (R, W, Set-by-create) (mandatory)
(16 bytes). The template for these 16 bytes is as follows:
100
The definition of this field is the same as that in classical PM. When PM is
collected on a continuously-running basis, rather than in 15-minute
intervals, counter thresholds should not be established. There is no
mechanism to clear a TCA, and any counter parameter may eventually be
expected to cross any given threshold value
Parent ME class:
(2 bytes)
This field contains the enumerated value of the ME class of the PM ME's
parent. Together with the parent ME instance field, this permits a given PM
ME to be associated with any OMCI ME. The definition of an extended
PM ME should list the allowed parent ME classes
Parent ME
instance: (2 bytes)
Accumulation
disable: (2 bytes)
TCA disable:
(2 bytes)
15
14
13
Global PM14
disable
Global Th14
disable
...
2
1 (LSB)
PM2 PM1
Th2
Th1
Also clarified in table xx-x, this field permits TCAs to be inhibited, either
individually or for the complete managed entity 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 defined in the associated threshold data 1 and 2 ME instances.
When the global or attribute-specific value changes from 0 to 1,
outstanding TCAs are cleared, either for the ME instance globally or for
the individual disabled threshold. These bits affect only notifications, not
the underlying parameter accumulation or storage.
If the threshold data 1/2 id attribute does not contain a valid pointer, this
field is not meaningful.
Thresholds should be used with caution if PM attributes are accumulated
continuously.
101
Control fields:
(2 bytes)
This field is a bit map whose values govern the behaviour of the PM ME.
Bits are assigned as follows:
Bit 1 (LSB) The value 1 specifies continuous accumulation, regardless of
15-minute intervals. There is no concept of current and
historic accumulators; get and get current data (if supported)
both return current values. The value 0 specifies 15-minute
accumulators exactly like those of classical PM.
Bit 2
Bits 3..16
Reserved: (4 bytes)
The other template boiler plate fields are revised to read as follows:
Managed entity id:
It is not expected that PM accumulation policy will be changed in actual deployment practice, and
the behaviour of intervals, TCAs and accumulated history across a transition between continuous
and interval accumulation is not specified. It may be desirable to disable and clear PM at such a
transition.
The synchronize time action has no observable effect on PM that is accumulated continuously.
Counter PM attributes do not roll over in interval PM mode, but do roll over from maximum to zero
in continuous accumulation mode. PM attributes that record averages are undefined in continuous
accumulation mode. Both of these behaviours may be overridden by explicit specification in the
definition of a given extended PM ME.
102
70.5)
The software image download operation is a file transfer from the OLT to the ONT. Software
download is first described in the context of the baseline OMCI message set; the description is then
modified as appropriate for the extended message set.
I.2.7.1 Baseline message set download
The atomic unit of file transfer is the section, the 31 bytes of data that can be transferred in a single
(baseline) download section message. The last section in a software download may be padded with
null bytes as needed.
A number of sections comprise a so-called window. The size of a window may not exceed
256 sections. During the initial software download message exchange, the OLT proposes a
maximum window size, but a lower value can be stipulated by the ONT, 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 ONT can confirm that it has in fact
received each section of code.
In the message type field of the last download section message of the window, the OLT indicates
the end of the window by setting the AR (acknowledgement request) bit prior download section
messages are unacknowledged. If the ONT has not received the entire window correctly, i.e., if it
misses a sequence number or discards a download section because of a CRC error, 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 ONT agrees with both of these values, it acknowledges
successful completion of the download and updates the software image validity attribute to indicate
that the newly downloaded image is valid.
The ONT should not positively acknowledge an end download message until it has confirmed
image size and CRC, and performed whatever operations may be necessary such as non-volatile
storage to accept an immediate activate or commit message from the OLT. The ONT should
respond with a device busy result code until these operations are complete, and the OLT should
periodically re-try the end download command.
The nested state machines in OLT and ONT can conceivably get out of step in a number of
unspecified ways. Furthermore, it is not 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 ONT
reply with command processing error result codes to both 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 0s), whereupon both OLT and ONT should reset to
the state in which no download is in progress, that is, state S1/S1' of Figure 9.1.4-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.
Rec. ITU-T G.984.4 (2008)/Amd.2 (11/2009)
103
As well as the download of an image to the ONT 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.2.7.2
When the extended message set is used for software download, 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.
71)
General remarks
II.1.1
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 of the failure. If the
result was failure, the rest of the message contents may provide details of the failure, be filled with
all 0s, or in the extended message set, simply be omitted. The definition of each result and reason
appears in Table II.1.3-1:
Table II.1.3-1 Result and reason codes
Code
Headline
0000
Command processed
successfully
0001
0010
0011
Parameter error
0100
0101
Description
There are two functions for command processing: command
interpretation and command execution. This result means that
the received command, such as get/set/test/reboot, was properly
interpreted by the ONT's command interpretation function
without errors and that the interpreted command was
successfully transferred to the ONT's command execution
function.
This result means the command processing failed at the ONT
for some reason not described by one of the more specific error
codes.
This result means that the message type (baseline message set
byte 8, extended byte 3) is not supported by the ONT.
This result means that the command message received by the
ONT was errored. It would be appropriate if an attribute mask
were out of range, for example. In practice, this result code is
frequently used interchangeably with code 1001. However, the
optional-attribute and attribute execution masks in the reply
messages are only defined for code 1001.
This result means that the managed entity class (baseline bytes
10..11, extended bytes 5..6) is not supported by the ONT.
This result means that the managed entity instance (baseline
bytes 12..13, extended bytes 7..8) does not exist in the ONT.
105
Headline
Description
0110
Device busy
0111
Instance exists
1001
II.1.4
This result means that the command could not be processed due
to process-related congestion at the ONT. This result code may
also be used as a pause indication to the OLT while the ONT
conducts a time-consuming operation such as storage of a
software image into non-volatile memory.
This result means that the ONT already has a managed entity
instance that corresponds to the one the OLT is attempting to
create.
This result means that an optional attribute is not supported by
the ONT or that a mandatory/optional attribute could not be
executed by the ONT, even if it is supported, for example,
because of a range or type violation. In conjunction with this
result, attribute masks are used to indicate which attributes
failed or were unknown.
The following two kinds of attribute masks are used when this
result/reason is raised:
For an attribute mask, a bit map is used in the get, get response, create response, and set messages.
This bit map indicates which attributes are requested (get) or provided (get response and set). The
bit map is composed as follows:
Byte
Bit
8
Attribute 3
Attribute 4
Attribute 5
Attribute 6
Attribute 7
Attribute 8
Attribute 1 Attribute 2
106
Attribute numbers correspond to the ordering of the attributes in clause 9. Note that the managed
entity identifier, which is an attribute of each managed entity, has no corresponding bit in the
attribute mask. Thus, attributes are counted starting from the first attribute after the managed entity
identifier.
II.1.5
Alarm notifications
The ONT sends this notification each time an alarm status changes for the entity indicated in the
message identifier. 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 maximum number of alarms supported by OMCI for a given managed entity 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
Alarm 0
Alarm 1
Alarm 2
Alarm 3
Alarm 4
Alarm 5
Alarm 6
Alarm 7
Alarm 8
Alarm 9
Alarm 10
Alarm 11
Alarm 12
Alarm 13
Alarm 14
Alarm 15
Alarm 216
Alarm 217
Alarm 218
Alarm 219
Alarm 220
Alarm 221
Alarm 222
Alarm 223
28
Alarm numbers correspond to the alarm coding in clause 9. 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.
Alarm message sequence numbers can take values in the interval 1 to 255. Zero is excluded in order
to make this counter similar to the MIB data sync counter.
II.1.6
The descriptions below indicate how test, test response and test result messages are related.
Test:
This message is used to initiate either a self test or any of the other specific
tests defined against various managed entity types.
Test response:
Test result:
This message is used to report the result of either a self test (requested by the
OLT) or one of the specific tests defined against various managed entity types.
The test result notification is not used for autonomous tests that produce only
pass-fail results. Instead, notification is sent to the OLT via an alarm if the
managed entity fails its autonomous self test. Autonomous tests on the ANI-G
managed entity may, however, be reported with an autonomous test result
message, with or without corresponding alarms, on grounds that the actual
measured values may be important.
A test on a particular managed entity instance is invoked by sending a test message to this instance.
Each managed entity that supports tests needs to have an action test defined for it. The type of test
invoked by a test message depends on the managed entity.
The test response message is an indication to the OLT that the test request is received and is being
processed. The results of a requested test are sent to the OLT via a specific test result message.
Rec. ITU-T G.984.4 (2008)/Amd.2 (11/2009)
107
The test response message is sent immediately after the test message is received (i.e., within the
normal response time). The transaction identifier of the test response message is identical to the
transaction identifier of the test message that requested the test.
72)
In all subclauses of this clause, whenever bytes 10-11 read "Message identifier," revise the text to
read "Managed entity identifier."
73)
74)
Revise the introductory text to read per the following paragraph, and add the two new text formats
at the end of this clause:
The format of the test message is specific to the target entity class. A number of formats are
presently defined. Future test extensions for a given entity class can be supported by adding
additional encodings to presently unused bits or bytes. Future specification of tests for other entity
classes may use an existing format or may define new formats for the test message. These extension
mechanisms allow future tests to be supported without changing the principle of operation.
Format for dot1ag MEP entity class, loopback test
Field
Byte
Transaction identifier
6-7
Message type
Managed entity
identifier
108
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = test
10-11
OMCI = 0x0A
Entity class.
12
13
Field
Message contents
Byte
Comments
14
15
x=select test
0: Ethernet loopback test
1: IEEE 802.1ag link trace test (see
separate format description below)
Other values reserved
If c = 1, the value of the MEP's
CCM and LTM priority attribute is
used, with drop eligibility false.
If c = 0, pppd represents the priority
(p bits) and drop eligibility fields of
the transmitted LBM frame.
MAC address of target MHF or
MEP, or 0 if the destination MEP ID
is to be used instead.
[b-IEEE 802.1ag] specifies unicast
addresses; [b-ITU-T Y.1731] also
allows for multicast.
16-21
22-23
24-25
26-27
28-29
30-31
32-33
34-45
Padding
109
Byte
Transaction identifier
Message type
6-7
8
9
10-11
12
13
14
15
Message contents
16-21
22-23
24
25-26
27-45
110
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = test
OMCI = 0x0A
Entity class. NOTE This format
applies to the dot1ag MEP entity
class.
MSB entity instance
LSB entity instance
x=select test
0: Ethernet loopback test (see
separate format description above)
1: IEEE 802.1ag link trace test
Other values reserved
Flags, a bit mask
f: Use FDB only. When 1, the bridge
uses only its normal MAC
forwarding tables for forwarding.
When 0, the bridge may also consult
its MIP CCM database to determine
the forwarding port.
Unicast MAC address of target MHF
or MEP, or 0 if the destination MEP
ID is to be used instead.
Destination MEP ID, in the range
1..8191, or 0 if the unicast MAC
address in bytes 16-21 is to be used
instead.
Max hops count specifies initial
TTL (time to live); limits the number
of relay stages through which the
LTM is forwarded before being
discarded, and the number of LTRs
that may be returned.
[b-IEEE 802.1ag] recommends a
default value of 64.
Pointer to a general purpose buffer
ME, used to return the link trace
results. The ONT should deny the
test operation command if this field
is a null or an invalid pointer.
Padding
75)
Replace the message contents part of the table with the following (to correct the implication that
bytes 17..xx could contain content from more than one attribute):
Message contents
14
15
16
17..xx
xx-45
76)
Result, reason
0000 = command processed
successfully
0001 = command processing
error
0010 = command not supported
0011 = parameter error
0100 = unknown managed entity
0101 = unknown managed entity
instance
0110 = device busy
Padding
Revise the introductory text to read per the following paragraphs, and add two new test result
formats at the end of this clause:
The test result message is used to report the outcome of a test. In the case of a requested test, the
transaction identifier of the test result message is identical to the transaction identifier of the test
message that initiated the corresponding test. In the case of a self-triggered test result, the
transaction identifier is set to 0.
Several formats are currently defined. They are used as follows:
Self-test results, ONT-G, circuit pack, or any other ME that supports self test.
POTS (or BRI) test results, either MLT, dial tone draw-break or vendor-specific POTS tests
that use a general purpose buffer.
The results of an optical line supervision test on the ANI-G, RE ANI-G, PPTP RE UNI, RE
upstream amplifier or RE downstream amplifier.
111
Format for test action invoked against dot1ag MEP entity class, loopback test
Field
Byte
Transaction identifier
Message type
6-7
8
9
10-11
Message contents
12
13
14
15-16
17-18
19-20
21-24
25-45
Comments
DB = 0, AR = 0, AK =0
bits 5-1: action = test result
OMCI = 0x0A
Entity class.
NOTE This message format
pertains to the dot1ag MEP entity
class.
MSB entity instance
LSB entity instance
X = 1: indicates failure to receive
any loopback replies (LBRs) within
5 seconds
Valid LBRs count: the number of
valid, in-order LBRs received.
Out of order LBRs count: the
number of valid LBRs received that
were out of order.
Mismatch LBRs count: the number
of received LBRs whose MAC SDU
did not match that of the
corresponding LBM (except for
opcode). Optional feature, set to
0xFF if not supported.
Delay from LB message
transmission to LB response
reception, measured in
microseconds. The value 0 indicates
no information available.
Padding
Format for test action invoked against dot1ag MEP entity class, linktrace test
Field
Byte
Transaction identifier
Message type
6-7
8
Managed entity
identifier
112
Comments
DB = 0, AR = 0, AK =0
bits 5-1: action = test result
10-11
OMCI = 0x0A
Entity class.
12
13
Field
Message contents
Byte
14
15-18
19-26
27-45
77)
Comments
Padding
Extended OMCI messages may be up to 1980 bytes long, including headers. The previous
discussion of oversize get next messages remains applicable, although problems are less likely to
occur in practice.
II.3.1
Create
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = create
Extended OMCI = 0x0B
Entity class
7
8
9-10
11-n
The contents of the create message apply only to attributes that are defined to be set-by-create.
Writeable attributes that are not set-by-create are not permitted in a create message. Thus, the first
byte of the message contents field begins with the value of the first set-by-create attribute and so
forth. Space for each set-by-create attribute must be allocated in the create message, even if the
attribute is optional. When an optional attribute is not to be instantiated, the placeholder value to be
entered into this space is specific to the definition of each attribute.
113
II.3.2
Create response
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
11
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = create
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents field, bytes
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
0111 instance exists
12
Attribute execution mask (attributes
1-8), used when result, reason = 0011
0
attribute ok
1
illegal attribute value
13
Attribute execution mask (attributes
9-16), used when result, reason = 0011
0
attribute ok
1
illegal attribute value
NOTE If the result, reason code is not 0011, the attribute execution mask in bytes 12-13 is omitted.
II.3.3
II.3.4
II.3.5
Delete
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
114
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = delete
Extended OMCI = 0x0B
Field
Managed entity
identifier
Message contents
length
II.3.6
Byte
Comments
5-6
Entity class
7
8
9-10
Delete response
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
11
II.3.8
II.3.9
Set
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
4
5-6
7
8
9-10
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = delete
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents
field = 1 byte
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
II.3.7
Message contents
length
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = set
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents field, bytes
115
Field
Message contents
Byte
11
12
13-n
Comments
Attributes mask (attributes 1-8)
Attributes mask (attributes 9-16)
Value of first attribute to set (size
depending on the type of attribute)
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
DB = 0, AR = 0, AK = 1
bits 5-1: action = set
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents field, bytes
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
1001 attribute(s) failed or unknown
12
Optional-attribute mask (attributes
1-8), used with 1001 encoding:
0
default
1
unsupported attribute
13
Optional-attribute mask (attributes
9-16), used with 1001 encoding:
0
default
1
unsupported attribute
14
Attribute execution mask (attributes
1-8), used with 1001 encoding:
0
default
1
failed attribute
15
Attribute execution mask (attributes
9-16), used with 1001 encoding:
0
default
1
failed attribute
NOTE If the result code is not 1001, the attribute masks in bytes 12-15 are omitted.
116
11
Comments
II.3.11 Get
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = get
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents
field = 2 bytes
Attributes mask (attributes 1-8)
Attributes mask (attributes 9-16)
11
12
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
11
12
13
14
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = get
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents field, bytes
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
1001 attribute(s) failed or unknown
Attribute mask (attributes 1-8)
Attribute mask (attributes 9-16)
Optional-attribute mask (attributes
1-8), used with 1001 encoding:
0
default
1
unsupported attribute
117
Field
Byte
15
Comments
Optional-attribute mask (attributes
9-16), used with 1001 encoding:
0
default
1
unsupported attribute
Attribute execution mask (attributes
1-8), used with 1001 encoding:
0
default
1
failed attribute
Attribute execution mask (attributes
9-16), used with 1001 encoding:
0
default
1
failed attribute
Value of first attribute included (size
depending on the type of attribute)
16
17
18-n
Bytes 14-17 are reserved for the optional-attribute and attribute execution masks; however, the
content of these bytes is only valid in conjunction with result code 1001 used to indicate failed or
unknown attributes. When the result code is not 1001, these bytes should be set to 0 by the ONT
transmitter and ignored by the OLT receiver.
NOTE The position of these bytes differs from that in the baseline get response message.
When the OLT wishes to retrieve a table attribute, i.e., an attribute whose size is, or might be, larger
than the space available in one OMCI baseline message, the ONT indicates the size of that attribute
in bytes, rather than its value. The size is conveyed as four bytes in the value field for that attribute,
with the attribute execution mask set to indicate that the attribute is included. The OLT should then
use a sequence of get next messages to retrieve such an attribute. This convention also pertains to
extended OMCI messages, even though some table attributes might fit into an extended get
response message.
II.3.13 This clause is intentionally left blank
II.3.14 This clause is intentionally left blank
II.3.15 Get all alarms
Field
Byte
Transaction
correlation identifier
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Message contents
length
118
DB = 0, AR = 1, AK = 0
bits 5-1: action = get all alarms
0
9-10
Field
Message contents
Byte
11
Comments
x = alarm retrieval mode
0 Get all alarms regardless of ARC
status
1 Get all alarms not currently under
ARC
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = get all alarms
Extended OMCI = 0x0B
Entity class = ONT data
MS byte entity instance
LS byte entity instance
Size of message contents field = 2
11
12
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
11
12
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = get all alarms next
Extended OMCI = 0x0B
Entity class = ONT data
MS byte entity instance
LS byte entity instance
Size of message contents field = 2
MS byte of command sequence
number
LS byte of command sequence
number
119
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents 1
4
5-6
7
8
9-10
11-12
13
14
Message contents 2
15-42
43-44
45
46
47-74
Message contents n
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = get all alarms next
Extended OMCI = 0x0B
Entity class = ONT data
MS byte entity instance
LS byte entity instance
Size of message contents field
including all sub-parts, bytes
Entity class whose alarms are reported
MS byte entity instance whose alarms
are reported
LS byte entity instance whose alarms
are reported
Bit map alarms
Entity class whose alarms are reported
MS byte entity instance whose alarms
are reported
LS byte entity instance whose alarms
are reported
Bit map alarms
Further managed entity alarm masks
as needed
The bit map used in the get all alarms next response for a given managed entity class is identical to
the bit map used in the alarm notifications for that managed entity class.
If the ONT receives a get all alarms next request message whose command sequence number is out
of range, the get all alarms next response message should contain a null message contents field.
II.3.19 MIB upload
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
120
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = MIB upload
Extended OMCI = 0x0B
Field
Managed entity
identifier
Message contents
length
Byte
Comments
5-6
7
8
9-10
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = MIB upload
Extended OMCI = 0x0B
Entity class = ONT data
MS byte entity instance
LS byte entity instance
Size of message contents field = 2
11
12
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
11
12
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = MIB upload next
Extended OMCI = 0x0B
Entity class = ONT data
MS byte entity instance
LS byte entity instance
Size of message contents field = 2
MS byte of command sequence
number
LS byte of command sequence
number
121
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents,
ME instance 1
4
5-6
7
8
9-10
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = MIB upload next
Extended OMCI = 0x0B
Entity class = ONT data
MS byte entity instance
LS byte entity instance
Size of message contents field
including all sub-fields, bytes
Size of ME instance 1 attribute values
included (excluding bytes 11-18),
bytes
Entity class of ME instance 1
MS byte entity instance
LS byte entity instance
Attribute mask (attributes 1-8)
Attribute mask (attributes 9-16)
Value of first attribute (size depending
on the type of the attribute)
...
Value of last attribute
Content of ME instance 2, defined as
above.
11-12
13-14
15
16
17
18
19-n
Message contents,
ME instance 2
Message contents,
ME instance k
Note that, if not all attributes of a managed entity fit within one MIB upload next response message,
the attributes are split over several messages. The OLT can use the information in the attribute mask
to determine which attribute values are reported in which MIB upload next response message.
Thus, a single extended MIB upload next response message must contain an integer number of
attribute values. A message may contain leading or trailing fragments of ME instances and any
number of complete ME instances.
If the ONT receives a MIB upload next request message whose command sequence number is out
of range, it should respond with a message containing no message contents field. This is also the
appropriate response if the ONT times out (one minute) from the most recent MIB upload next or
MIB upload request from the OLT.
II.3.23 MIB reset
Field
Byte
Transaction
correlation identifier
1-2
122
Comments
Field
Message type
Device identifier
Managed entity
identifier
Message contents
length
Byte
4
5-6
7
8
9-10
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = MIB reset
Extended OMCI = 0x0B
Entity class = ONT data
MS byte entity instance
LS byte entity instance
Size of message contents field = 0
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = MIB reset
Extended OMCI = 0x0B
Entity class = ONT data
MS byte entity instance
LS byte entity instance
Size of message contents field = 1
11
Field
Byte
Transaction
correlation identifier
Message type
1-2
3
Device identifier
Managed entity
identifier
4
5-6
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
II.3.25 Alarm
Message contents
length
7
8
9-10
Comments
DB = 0, AR = 0, AK = 0
bits 5-1: action = alarm
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents field, bytes
123
Field
Message contents
Byte
11
Comments
Alarm mask
Alarm mask
Alarm sequence number
38
39
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
Comments
DB = 0, AR = 0, AK = 0
bits 5-1: action = attribute value
change
Extended OMCI = 0x0B
Entity class
7
8
9-10
11
12
13-n
The AVC message for a table attribute contains no attribute value, only a mask, and the ONT
creates no snapshot of the table. If the OLT wishes to obtain the new value, it must do a get
operation, followed by the required number of get next operations.
II.3.27 Test
The format of the test message is specific to the target entity class. Several formats are defined.
Future test extensions for a given entity class can be supported by adding additional encodings to
presently unused bits or bytes. Future specification of tests for other entity classes may use an
existing format or may define new formats for the test message. These extension mechanisms allow
future tests to be supported without changing the principle of operation.
124
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
11
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = test
Extended OMCI = 0x0B
Entity class.
NOTE This format applies to entity
classes ONT-G, ANI-G, RE ANI-G,
PPTP RE UNI, RE upstream
amplifier, RE downstream amplifier
and circuit pack.
MS byte entity instance
LS byte entity instance
Size of message contents field = 1
xxxx = select test
0000..0110
Reserved for future
use
0111
Self test
1000..1111
Vendor-specific use.
See description
related to the test
result message.
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
4
5-6
7
8
9-10
Comments
125
Field
Message contents
Byte
Comments
11
12-15
Format for POTS UNI and PPTP ISDN UNI entity classes
This message supports two basic categories of test operation, a defined set of tests that look in and
out from the POTS port, and a set of codepoints that may be used for vendor-specific tests. The
latter category is further subdivided into codepoints that return test results in a general purpose
buffer ME, using the test result message primarily as an event trigger to signal test completion, and
codepoints that return all test results in an ordinary test result message. If it is needed, the OLT must
create the general purpose buffer managed entity before initiating the test action.
Note that a single message can be used to initiate multiple tests on a given ME if desired.
Bytes 12-25 are used by the dial tone make-break test. A zero value for a timer causes the ONT to
use its built-in defaults. As many as three dial tone frequencies can be specified, or omitted by
setting their values to 0. Other fields are also omitted with the value 0, or controlled by flags. An
ONT can support the dial tone test with internal defaults only, and is not required to support any of
the attributes of bytes 12-25. Likewise, an ONT can use internal defaults for drop test, rather than
the values given in bytes 26-35. The capabilities of an ONT are documented by the vendor and
known through administrative practices.
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
126
4
5-6
7
8
9-10
Comments
DB = 0, AR = 1, AK = 0
Bits 5-1: action = test
Extended OMCI = 0x0B
Entity class
NOTE This format applies to entity
classes PPTP POTS UNI and PPTP
ISDN UNI.
MS byte entity instance
LS byte entity instance
Size of message contents field, bytes
Field
Message contents
Byte
Comments
11
a test mode
0
normal; deny test if line busy
1
forced mode
xxxx = select test
0000 all MLT tests
0001 hazardous potential
0010 foreign EMF
0011 resistive faults
0100 receiver off-hook
0101 ringer
0110 NT1 dc signature test
0111 self test
1000 dial tone make-break test
1001..1011
vendor-specific test,
all results returned in test
results message
1100..1111
vendor-specific test,
test results returned in
general purpose buffer ME.
The ONT should deny a test
operation command in this
range if bytes 36..37 do not
point to a GP buffer.
DBDT timer T1 (slow dial tone
threshold), in units of 0.1 seconds.
Range 0.1 to 6.0 seconds.
DBDT timer T2 (no dial tone
threshold), in units of 0.1 seconds.
Range 1.0 to 10.0 seconds.
DBDT timer T3 (slow break dial tone
threshold), in units of 0.1 seconds.
Range 0.1 to 3.0 seconds.
DBDT timer T4 (no break dial tone
threshold), in units of 0.1 seconds.
Range 1.0 to 3.0 seconds.
DBDT control byte
d: dialled digit
1
dialled digit specified in
byte 17
0
use default digit
p = pulse (1) or tone (0) dialling
Digit to be dialled, ASCII character in
range "0"-"9", "*", "#".
Dial tone frequency 1, in units of Hz
Dial tone frequency 2, in units of Hz.
0 = unused (i.e., if only one tone is
specified).
Dial tone frequency 3, in units of Hz.
0 = unused (i.e., if only one or two
tones are specified).
12
13
14
15
16
17
18-19
20-21
22-23
127
Field
Byte
24
Comments
Dial tone power threshold, absolute
value, 0.1 dB resolution, range []0.1
to []25.3 dBm0, e.g.,
13 dBm0 = 0x82.
0 = unspecified.
Idle channel power threshold, absolute
value, 1 dB resolution, range []1 to
[]90 dBm0. 0 = unspecified.
DC hazardous voltage threshold,
absolute value, volts. 0 = unspecified.
AC hazardous voltage threshold, volts
RMS. 0 = unspecified.
DC foreign voltage threshold, absolute
value, volts. 0 = unspecified.
AC foreign voltage threshold, volts
RMS. 0 = unspecified.
Tip-ground and ring-ground resistance
threshold, k. 0 = unspecified.
Tip-ring resistance threshold, k.
0 = unspecified.
Ringer equivalence minimum
threshold, in 0.01 REN units.
0 = unspecified.
Ringer equivalence maximum
threshold, in 0.01 REN units.
0 = unspecified.
Pointer to a general purpose buffer
ME, used to return vendor-specific
test results.
25
26
27
28
29
30
31
32-33
34-35
36-37
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
128
4
5-6
7
8
9-10
Comments
DB = 0, AR = 1, AK = 0
Bits 5-1: action = test
Extended OMCI = 0x0B
Entity class
NOTE This format applies to the
dot1ag MEP entity class.
MS byte entity instance
LS byte entity instance
Size of message contents field, bytes
Field
Message contents
Byte
Comments
11
12
x=select test
0: Ethernet loopback test
1: IEEE 802.1ag link trace test (see
separate format description below)
Other values reserved
If c = 1, the value of the MEP's CCM
and LTM priority attribute is used,
with drop eligibility false.
If c = 0, pppd represents the priority (p
bits) and drop eligibility fields of the
transmitted LBM frame.
MAC address of target MHF or MEP,
or 0 if the destination MEP ID is to be
used instead. [b-IEEE 802.1ag]
specifies unicast addresses;
ITU-T Y.1731 also allows for
multicast.
Destination MEP ID, in the range
1..8191, or 0 if the MAC address in
bytes 13..18 is to be used instead.
Repetition count, range 1..1024. This
governs how many LBMs are
generated. The rate at which LBMs
are generated is not specified. If 5
seconds elapses with no LBRs
received, the test aborts.
These four fields are pointers to as
many as four-octet string MEs, which
are concatenated to form an octet
string of up to 1500 bytes. The string
is packaged into a data TLV and
transmitted as part of the LBM. If all
four fields are null pointers, no data
TLV is sent. If only one octet string is
needed, it should be specified in bytes
23..24, etc., with null pointers in the
higher-numbered bytes of the test
message.
13-18
19-20
21-22
23-24
25-26
27-28
29-30
Byte
Transaction
correlation identifier
Message type
1-2
3
Device identifier
Managed entity
identifier
4
5-6
7
8
Comments
DB = 0, AR = 1, AK = 0
Bits 5-1: action = test
Extended OMCI = 0x0B
Entity class
NOTE This format applies to the
dot1ag MEP entity class
MS byte entity instance
LS byte entity instance
129
Field
Message contents
length
Message contents
Byte
9-10
Comments
Size of message contents field, bytes
11
12
13-18
19-20
21
22-23
x=select test
0: Ethernet loopback test (see separate
format description above)
1: IEEE 802.1ag link trace test
Other values reserved
Flags, a bit mask
f: Use FDB only. When 1, the bridge
uses only its normal MAC forwarding
tables for forwarding. When 0, the
bridge may also consult its MIP CCM
database to determine the forwarding
port.
Unicast MAC address of target MHF
or MEP, or 0 if the destination MEP
ID is to be used instead.
Destination MEP ID, in the range
1..8191, or 0 if the unicast MAC
address in bytes 13..18 is to be used
instead.
Max hops count specifies initial TTL
(time to live); limits the number of
relay stages through which the LTM is
forwarded before being discarded, and
the number of LTRs that may be
returned. [b-IEEE 802.1ag]
recommends a default value of 64.
Pointer to a general purpose buffer
ME, used to return the link trace
results. The ONT should deny the test
operation command if this field is a
null or an invalid pointer.
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
130
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = test
Extended OMCI = 0x0B
Field
Managed entity
identifier
Message contents
length
Message contents
Byte
Comments
5-6
Entity class
7
8
9-10
11
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
The test response message is an indication to the OLT that the test request is received and is being
processed. The test outcome is reported by a subsequent autonomous test result message.
II.3.29 Start software download
When a file is to be downloaded to a single instance of the software image managed entity, the
target ME id is specified in bytes 7..8. An optional feature permits the same file to be downloaded
to a number of circuit packs by setting bytes 7..8 = 0xFFFF and specifying the software image ME
ids in bytes 17-18, 19-20, etc.
Field
Byte
Transaction
correlation identifier
Message type
1-2
3
Device identifier
Managed entity
identifier
4
5-6
Message contents
length
9-10
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = start software
download
Extended OMCI = 0x0B
Entity class = software image
MS byte of software image instance
0
ONT-G
1..254 slot number
255
download to multiple
software image managed
entities
LS byte of software image instance
0
instance 0
1
instance 1
255
multiple download
Size of message contents field, bytes
131
Field
Message contents
Byte
11
12-15
16
Comments
Window size 1
Image size in bytes
Number of circuit packs to be updated
in parallel (value 1...9)
MS byte of software image instance
(slot number of circuit pack)
LS byte of software image instance
(value 0..1)
Software image ME ids (same format
as bytes 17..18) for additional
simultaneous downloads.
17
18
19-xx
Byte
Transaction
correlation identifier
Message type
1-2
3
Device identifier
Managed entity
identifier
4
5-6
Message contents
length
132
9-10
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = start software
download
Extended OMCI = 0x0B
Entity class = software image
MS byte of software image instance
0
ONT-G
1..254 slot number
255
download to multiple
software image managed
entities
LS byte of software image instance
0
instance 0
1
instance 1
255
multiple download
Size of message contents field, bytes
Field
Message contents
Byte
Comments
11
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
Window size 1
Number of instances responding
(value 0..9)
ME id of software image entity
instance (slot number plus instance
0..1)
Result, reason for bytes 14..15 same
coding as byte 11
Repeat coding of bytes 14..16 for
additional requested software image
instances.
Comments
12
13
14-15
16
17-n
Byte
Transaction
correlation identifier
Message type
1-2
3
Device identifier
Managed entity
identifier
4
5-6
9-10
11
12-n
Message contents
length
Message contents
DB = 0, AR = x, AK = 0
x = 0 no response expected
(section within a window)
x = 1 response expected
(last section of a window)
bits 5-1: action = sw download section
Extended OMCI = 0x0B
Entity class = software image
133
Byte
Transaction
correlation identifier
Message type
1-2
3
Device identifier
Managed entity
identifier
4
5-6
9-10
11
DB = 0, AR = 0, AK = 1
bits 5-1: action = sw download section
Extended OMCI = 0x0B
Entity class = software image
MS byte of software image instance
0
ONT-G
1..254 slot number
255
download to multiple
software image managed
entities
LS byte of software image instance
0
instance 0
1
instance 1
255
multiple download
Size of message contents field = 2
Message contents
length
Message contents
Comments
12
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
Download section number
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
134
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = end software
download
Extended OMCI = 0x0B
Field
Managed entity
identifier
Byte
5-6
Message contents
length
Message contents
Comments
9-10
11-14
15-18
19
20
21
22-xx
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = end software
download
Extended OMCI = 0x0B
135
Field
Managed entity
identifier
Byte
5-6
Message contents
length
Message contents
9-10
11
12
13-14
15
16-n
136
Comments
Result, reason
0000 command processed
successfully (CRC correct)
0001 command processing error
(CRC incorrect)
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
Number of instances responding
(value 0..9)
ME id of software image entity
instance (slot number plus instance
0..1)
Result, reason for bytes 13..14 same
coding as byte 11
Repeat coding of bytes 13..15 for
additional software image instances.
Byte
Transaction
correlation identifier
Message type
1-2
3
Device identifier
Managed entity
identifier
4
5-6
Message contents
length
9-10
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = activate image
Extended OMCI = 0x0B
Entity class = software image
MS byte entity instance
0
ONT-G
1..254 slot number
LS byte entity instance
0
first instance
1
second instance
Size of message contents field = 0
Byte
Transaction
correlation identifier
Message type
1-2
3
Device identifier
Managed entity
identifier
4
5-6
Message contents
length
Message contents
9-10
11
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = activate image
Extended OMCI = 0x0B
Entity class = software image
MS byte entity instance
0
ONT-G
1..254 slot number
LS byte entity instance
0
first instance
1
second instance
Size of message contents field = 1
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
137
Byte
Transaction
correlation identifier
Message type
1-2
3
Device identifier
Managed entity
identifier
4
5-6
Message contents
length
9-10
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = commit image
Extended OMCI = 0x0B
Entity class = software image
MS byte entity instance
0
ONT-G
1..254 slot number
LS byte entity instance
0
first instance
1
second instance
Size of message contents field = 0
Byte
Transaction
correlation identifier
Message type
1-2
3
Device identifier
Managed entity
identifier
4
5-6
Message contents
length
Message contents
138
9-10
11
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = commit image
Extended OMCI = 0x0B
Entity class = software image
MS byte entity instance
0
ONT-G
1..254 slot number
LS byte entity instance
0
first instance
1
second instance
Size of message contents field = 1
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = synchronize time
Extended OMCI = 0x0B
Entity class = ONT-G
7
8
9-10
11-12
13
14
15
16
17
Byte
Transaction
correlation identifier
Message type
1-2
3
Device identifier
Managed entity
identifier
4
5-6
7
8
Comments
DB = 0, AR = 0, AK = 1
Bits 5-1: action = synchronize time
Extended OMCI = 0x0B
Entity class = ONT-G
MS byte entity instance = 0
LS byte entity instance = 0
139
Field
Message contents
length
Message contents
Byte
Comments
9-10
11
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
II.3.41 Reboot
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
4
5-6
7
8
9-10
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = reboot
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents field = 0
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
140
4
5-6
7
8
9-10
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = reboot
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents field = 1
Field
Message contents
Byte
11
Comments
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
If the attribute mask specifies more than one attribute (result code 0011).
If the attribute mask specifies an attribute that is not a table (result code 0011).
If the specified attribute has not been prepared for upload with a prior get command (the
prior get is subject to one-minute timeout) (result code 0001).
Command sequence numbers start from 0.
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
11
12
13
14
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = get next
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents field = 4
Attribute mask (attributes 1-8)
Attribute mask (attributes 9-16)
MS byte of command sequence
number
LS byte of command sequence
number
141
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
11
Comments
DB = 0, AR = 0, AK =1
bits 5-1: action = get next
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents field, bytes
12
13
14-n
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
Attribute mask (attributes 1-8)
Attribute mask (attributes 9-16)
Value of the specified attribute (size
depending on type of attribute, limited
by message capacity)
If the ONT receives a get next request message whose command sequence number is out of range,
the ONT responds with parameter error.
II.3.45 Test result
The test result message is used to report the outcome of a test. In the case of a requested test, the
transaction identifier of the test result message is identical to the transaction identifier of the test
message that initiated the corresponding test. In the case of a self-triggered test result, the
transaction identifier is set to 0.
Several formats are currently defined. They are used as follows:
Self test results, ONT-G, circuit pack, or any other ME that supports self test.
POTS (or BRI) test results, either MLT, dial tone draw-break or vendor-specific POTS tests
that use a general purpose buffer.
The results of an optical line supervision test on the ANI-G, RE ANI-G, PPTP RE UNI, RE
upstream amplifier or RE downstream amplifier.
142
If a new test for the presently-supported entities is defined in the future, the corresponding test
results can be reported by extending the test result message layout. If a new test for other managed
entity classes is defined in the future, a new test result message layout may be defined.
Format for self test action invoked against ONT-G and circuit pack entity classes
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
0
0
0
0
0
0
0
0
0
0
0
0
0
x
0
x
7
8
9-10
11
12
Comments
DB = 0, AR = 0, AK =0
bits 5-1: action = test result
Extended OMCI = 0x0B
Entity class
NOTE This message format pertains
to ONT-G and circuit pack entity
classes.
MS byte entity instance
LS byte entity instance
Size of message contents field = 2
Reserved
xx: self test result
00
failed
01
passed
10
not completed
Format for vendor-specific test actions invoked against ONT-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.
Field
Byte
Transaction
correlation identifier
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Message contents
length
Comments
DB = 0, AR = 0, AK =0
bits 5-1: action = test result
0
9-10
143
Field
Message contents
Byte
11
Comments
Type 1 (Note)
12-13
Value 1
14
Type 2
15-16
Value 2
17
Type 3
18-19
Value 3
20
Type 4
21-22
Value 4
23
Type 5
24-25
Value 5
26
Type 6
27-28
Value 6
29
Type 7
30-31
Value 7
32
Type 8
33-34
Value 8
35
Type 9
36-37
Value 9
38
Type 10
39-40
Value 10
NOTE Test result types are specified in clause 11.2.10. Type-value fields are packed in the lowest byte
positions. Unused trailing byte positions may be omitted. If more than 10 type-value pairs are to be
returned, an additional test type should be defined in the test message. At the vendor's discretion, a test
result may include an ordered sequence of repeated type-value pairs to represent, for example, port
ordering, or first/second power input. In this case, missing values can be flagged with type = 255.
Format for POTS UNI and PPTP ISDN UNI entity classes
Byte 11 reports a summary MLT test result. The result for each test category is limited to the two
values pass test or test not run or failed test. Byte 13 reports the results of a dial tone test.
Byte 12 reports the result of a self test or a vendor-specific test that returns results in a general
purpose buffer. At present, self test is not supported for the POTS UNI and PPTP ISDN UNI entity
classes, and this byte should be set to 0.
There are four possible outcomes for a given test: it can pass, fail, not be run, or not be recognized
by the ONT. If an ONT does not support or recognize a given test, it is expected to deny the test
request message. To avoid physical damage, an ONT may cease testing if a test fails usually
hazardous potential and thus some subsequent tests will not be run. In addition, the ONT may
support some but not all tests of a given suite, such as power measurements in the dial tone test
sequence. The category summary in byte 11 includes two values. The value 1 indicates either that
all tests in a category passed, or that nothing in the category was tested, while 0 indicates that at
least one test in the category failed. Further information appears in flags specific to each test results
attribute to indicate whether each detailed test was run or not, whether it passed or failed and
whether a measured result is reported or not.
144
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
11
12
13
14
15
16
7
8
9-10
Comments
DB = 0, AR = 0, AK = 0
bits 5-1: action = test result
Extended OMCI = 0x0B
Entity class
NOTE This message format pertains
to PPTP POTS UNI and PPTP ISDN
UNI entity classes.
MS byte entity instance
LS byte entity instance
Size of message contents field, bytes
MLT drop test result:
0
fail test a/b/c/d/e/f
1
pass test, or test not run
a
hazardous potential
b
foreign EMF
c
resistive faults
d
receiver off-hook
e
ringer
f
NT1 dc signature test
xx: Result of self test or vendorspecific test
00
failed
01
passed
10
not completed
Dial tone make-break flags:
ddd Dial tone draw
000
test not run
01m failed, could not draw
10m slow draw
11m passed
bbb Dial tone break
000
test not run
01m failed, could not break
10m slow break
11m passed
m measured value flag
0
measurement not reported
1
measurement reported
Dial tone power flags (Note)
aaa Quiet channel power
bbb Dial tone power
Loop test DC voltage flags (Note)
aaa VDC, tip-ground
bbb VDC, ring-ground
Loop test AC voltage flags (Note)
aaa VAC, tip-ground
bbb VAC, ring-ground
145
Field
Byte
Comments
17
18
19
20
21
22
23-24
25-26
27
28
29-30
31-32
33-34
35
36-37
146
Format for test action invoked against IP host config data entity class
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
11
12..n
Comments
DB = 0, AR = 0, AK =0
bits 5-1: action = test result
Extended OMCI = 0x0B
Entity class
NOTE This format applies to entity
class IP host config data.
MS byte entity instance
LS byte entity instance
Size of message contents field, bytes
xxx: Test result
000
timed out, no response
001
ICMP echo responses
attached
010
ICMP time exceeded
responses attached
011
Unexpected ICMP
response
100..111 Reserved
See following descriptions for the
content of these bytes
If xxx = 001 (echo response ping), the remainder of the message contains the following content.
How many echo requests are sent and the resolution of the delay measurement are specific to a
vendor's implementation. The special value 0xFFFF indicates a lost response.
12-13
14-15
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.
12-15
18-21
147
If xxx = 011 (unexpected ICMP response), the remainder of the message contains the following
content:
12
13
14-15
18-21
Type
Code
Checksum
Bytes 5-8 of ICMP message (meaning
depends on type/code)
Internet header + original datagram
(truncated if necessary by extended
OMCI message size limit)
22-n
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
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
17
18-19
20
21-22
23
24-25
7
8
9-10
11
12-13
14
15-16
Comments
DB = 0, AR = 0, AK =0
bits 5-1: action = test result
Extended OMCI = 0x0B
Entity class
NOTE This message format pertains
to ANI-G, RE ANI-G, PPTP RE UNI,
RE upstream amplifier or RE
downstream amplifier entity class.
MS byte entity instance
LS byte entity instance
Size of message contents field, bytes
Type = 1, Power feed voltage
V, 2s complement, 20 mV resolution
Type = 3, Received optical power
dBW, 2s complement, 0.002 dB
resolution
Type = 5, Transmitted optical power
dBW, 2s complement, 0.002 dB
resolution
Type = 9, Laser bias current
Unsigned integer, 2 A resolution
Type 12, Temperature, degrees
2s complement, 1/256 degree C
resolution
NOTE Unsupported tests are indicated with test type indicator 0 and 2 bytes of 0 data.
148
Format for test action invoked against dot1ag MEP entity class, loopback test
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
7
8
9-10
11
12-13
14-15
16-17
18-19
Comments
DB = 0, AR = 0, AK =0
bits 5-1: action = test result
Extended OMCI = 0x0B
Entity class
NOTE This message format pertains
to ONT-G and circuit pack entity
classes.
MS byte entity instance
LS byte entity instance
Size of message contents field = 2
X = 1: indicates failure to receive any
loopback replies (LBRs) within 5
seconds
Valid LBRs count: the number of
valid, in-order LBRs received.
Out of order LBRs count: the number
of valid LBRs received that were out
of order.
Mismatch LBRs count: the number of
received LBRs whose MAC SDU did
not match that of the corresponding
LBM (except for opcode). Optional
feature, set to 0xFF if not supported.
Delay from LB message transmission
to LB response reception, measured in
microseconds. The value 0 indicates
no information available.
Format for test action invoked against dot1ag MEP entity class, linktrace test
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
4
5-6
7
8
9-10
Comments
DB = 0, AR = 0, AK =0
bits 5-1: action = test result
Extended OMCI = 0x0B
Entity class
NOTE This message format pertains
to ONT-G and circuit pack entity
classes.
MS byte entity instance
LS byte entity instance
Size of message contents field
149
Field
Message contents
Byte
Comments
11
Comments
12-15
16-23
Byte
Transaction
correlation identifier
Message type
1-2
3
Device identifier
Managed entity
identifier
4
5-6
Message contents
length
Message contents
7
8
9-10
DB = 0, AR = 1, AK = 0
bits 5-1: action = get current data
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents field = 2
11
12
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
150
4
5-6
7
8
9-10
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = get current data
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents field, bytes
Field
Message contents
Byte
Comments
11
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
1001 attribute(s) failed or unknown
Attribute mask (attributes 1-8)
Attribute mask (attributes 9-16)
Optional-attribute mask
(attributes 1-8), used with 1001
encoding:
0
default
1
unsupported attribute
Optional-attribute mask
(attributes 9-16), used with 1001
encoding:
0
default
1
unsupported attribute
Attribute execution mask
(attributes 1-8), used with 1001
encoding:
0
default
1
failed attribute
Attribute execution mask
(attributes 9-16), used with 1001
encoding:
0
default
1
failed attribute
Value of first attribute included (size
depending on the type of attribute)
12
13
14
15
16
17
18-n
Bytes 14..17 are reserved for the optional-attribute and attribute execution masks; however, the
content of these bytes is only valid in conjunction with the 1001 encoding used to indicate failed or
unknown attributes. If the result code is not 1001, these bytes are still present, but should be set to 0
by the ONT and ignored by the OLT.
II.3.48 Set table
The set table command provides a way in which a number of rows may be written into a table with
a single command. The same function can be achieved with individual set commands, with each
command instance directed to a single row of the table.
Writeable tables in OMCI have various mechanisms to control whether a given set operation causes
a new row to be added to the table, an existing row to be overwritten or deleted, or the entire table
cleared. All such mechanisms are embedded within the definition of the table row itself. Conflicting
control semantics are therefore possible. The set table command executes each table row
sequentially, in list order.
Rec. ITU-T G.984.4 (2008)/Amd.2 (11/2009)
151
Field
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
4
5-6
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = set table
Extended OMCI = 0x0B
Entity class
7
8
9-10
11
12
13-n
NOTE Exactly one bit of the attribute mask must be set, and that bit must correspond to a read-write table
attribute in the definition of the parent managed entity.
Byte
Transaction
correlation identifier
Message type
1-2
Device identifier
Managed entity
identifier
Message contents
length
Message contents
152
4
5-6
7
8
9-10
11
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = set table
Extended OMCI = 0x0B
Entity class
MS byte entity instance
LS byte entity instance
Size of message contents field = 1
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
0101 unknown managed entity
instance
0110 device busy
1001 attribute(s) failed or unknown
78)
In slightly more complex implementations, ONTs may implement some level of traffic scheduling
within each T-CONT. These are described using priority queues and one or more levels of traffic
scheduler MEs. The arrangement of priority queues and traffic schedulers is determined by the
ONT, and is by default not controllable by the OLT. An example of the configuration of the traffic
scheduler appears in Figure III.2-1. This model consists of three stages, such as two-delay control
and one guaranteed rate control stages. A delay control stage can be worked by HOL (head of line)
scheduling. A guaranteed rate control stage can be worked by WRR. This configuration may also be
used when the traffic management option attribute in the ONT-G ME is 0 (priority controlled).
79)
Revise the following two clauses to read as shown (change GEM traffic descriptor to traffic
descriptor).
III.3
An alternative method of controlling traffic in ONTs is to provide traffic descriptors to the ONT,
and leave the details of honouring and enforcing these contracts to the ONT implementation. This is
controlled using traffic descriptor MEs. This method makes the theoretical assumption that a workconserving scheduling methodology will be used. In this configuration, traffic is shaped to conform
to PIR and PBS in the traffic descriptor ME. This configuration is used when the traffic
management option attribute in the ONT-G ME is 1 (rate controlled).
III.4
Another method of controlling traffic in ONTs is to provide not only priority control with traffic
scheduling, but also traffic descriptors. This is controlled using traffic descriptor, priority queue-G
and traffic scheduler-G MEs. This method makes the theoretical assumption that a work-conserving
scheduling methodology will be used. In this configuration, traffic is policed to conform to PIR and
PBS, and may be marked green or yellow according to CIR/CBS/PIR/PBS in the traffic descriptor
ME. This configuration is used when the traffic management option attribute in the ONT-G ME is 2
(priority and rate controlled).
80)
Flexible assignment
By default, priority queues and traffic schedulers are assigned to T-CONTs by the ONT architecture
in a fixed configuration, which may not be altered. It is also possible that the ONT implements its
QoS components in such a way that they may be flexibly reassigned (Note). ONT flexibility is
signalled to the OLT by means of the QoS configuration flexibility bit map attribute of the ONT2-G
managed entity.
NOTE Given the slot-port model of ONT equipment, which appears among other places in the managed
entity identifiers of T-CONT, physical path termination points, the traffic scheduler, and the related port
attribute of the priority queue managed entity, it is not anticipated that implementation flexibility would
extend across slots. Accordingly, OMCI restricts flexibility to be only within a slot, but does not permit
flexible assignment across slots.
153
81)
154
Series D
Series E
Overall network operation, telephone service, service operation and human factors
Series F
Series G
Series H
Series I
Series J
Cable networks and transmission of television, sound programme and other multimedia signals
Series K
Series L
Construction, installation and protection of cables and other elements of outside plant
Series M
Series N
Series O
Series P
Series Q
Series R
Telegraph transmission
Series S
Series T
Series U
Telegraph switching
Series V
Series X
Series Y
Series Z
Printed in Switzerland
Geneva, 2010