OAM协议详解_服务期限怎么填写

大家好，又见面了，我是你们的朋友全栈君。

OAMPDU消息格式及定义

OAMPDU消息的格式如下图6-8所示。各个字段的详细定义如下：

a) 目的地址(DA)：Slow_Protocols_Multicast地址，使用和编码规定见IEEE802.3-2005 Annex 43B；

b) 源地址(SA)：OAMPDU中的SA是独立的MAC地址，该地址与发送OAMPDU的端口相关联；

c) Length/Type：OAMPDU采用Type编码，并且承载Slow_Protocols_Type域值（0x8809），使用和编码规定见IEEE 802.3-2005 Annex 43B；

d) Subtype：Subtype域标识封装的特定的Slow Protocol，OAMPDU Subtype域值为0x03；

e) Flag：包含状态比特，具体规定见IEEE802.3-2008 Clause 57.4.2.1；

f) Code：指示不同的OAMPDU消息，具体规定见IEEE802.3-2008 Clause 57.4.2.2；

g) Data/PAD：这个字段用于OAMPDU的有效载荷。当不使用这些字节时，在发送时填充为0，并在接收时忽略；

h) FCS：该域为帧校验序列，一般由下层MAC产生。

图6-8 OAMPDU消息格式

对OAMPDU的要求

OAMPDU帧长要求

EPON的标准OAMPDU和扩展OAMPDU均应支持1518字节的最大帧长（最大净荷是1500字节）。

OAMPDU帧速率要求

标准OAMPDU帧速率和扩展OAMPDU应符合IEEE 802.3的规定。OLT和ONU OAMPDU的最大帧速率应不能超过IEEE 802.3规定的最大OAM帧速率（此处考虑IEEE 802.3已进行了相应修改）。

OAMPDU定时要求

为使OAMPDU的操作更高效，应限制远端OAM Client收到OAMPDU后的响应时间。具体实现方式如下：

OLT应具有对所发出的OAMPDU的应答响应超时机制（除软件升级的End Download Request消息外）。OLT应对每个向远端OAM Client（ONU）发出的每个OAMPDU设置一个定时器remote_response_timer。当OLT发出一个OAMPDU后，立即启动相应的remote_response_timer。如果OLT在该定时器超时之前接收到了从该远端OAM Client发来的针对该OAMPDU的应答，则OLT应将remote_response_timer复位并对应答的OAMPDU进行相关处理。如果OLT在该定时器超时之前未接收到从该远端OAM Client发来的针对该OAMPDU的应答，则OLT向网管上报响应超时告警（response_timeout），对该定时器超时后收到的针对该OAMPDU的回复做丢弃处理。remote_response_timer定时器的超时时间应可配置，缺省值为1秒。

为了保证正确的操作，在收到标准OAMPDU或扩展OAMPDU后，ONU应在尽快完成相应的操作（如属性值的读取、设置、Action生效和环回状态改变等），并发送应答的OAMPDU。

OAM保活（keep alive）机制

为简化OAM Keep alive处理过程，在发送端（OLT或者ONU），专门用于Keep alive的OAMPDU中仅填充标准的Information TLV（Local Info TLV和Remote Info TLV）即可；在接收端（ONU或者OLT），所接受收到的任何合法的、可解析的OAMPDU（即OAMPDU格式合法且其中包含至少一个可解析的TLV）都起着Keep alive的作用。当且仅当在local_lost_link_timer（设置为5秒±10%）超时之前未收到任何有效的OAMPDU（“未收到任何有效的OAMPDU”包括这样的案例：接收端收到合法的INFO OAMPDU，但INFO OAMPDU仅包含非法的或不可解析的Organization Specific Information TLV），接收端才会认为OAM连接失效，然后重新启动OAM发现过程。

扩展OAM功能要求

EPON系统应支持IEEE802.3规定的OAM功能，并支持IEEE802.3规定的管理对象（Managed Object Class）、属性（Attribute）和操作（Action）。

此外，应采用Organization Specific Extension 机制以实现IEEE802.3所未规定的扩展的ONU远程操作、维护和管理（OAM）所必须的功能。扩展的OAM应支持如下管理功能：

——扩展的OAM发现（Extended OAM Discovery）和能力通告（CapabilityNotification）；

——ONU的基本信息和能力通告；

——与搅动功能相关的密钥交换、更新和同步功能；

——与DBA功能相关的DBA参数读取和设置功能；

——用户端口配置功能（Configuration of User Ports）和管理；

——VLAN配置和管理；

——组播相关功能的配置；

——QoS相关配置，包括业务流分类和标记等；

——reset ONU等操作功能；

——ONU的软件下载功能；

——基于逻辑标识的ONU认证；

——ONU的事件通告；

——ONU语音业务的配置和管理。

扩展OAM的发现

用于扩展OAM发现的OAMPDU消息格式及定义

EPON系统应支持通过对INFO OAMPDU的Information TLV进行扩展，以实现扩展的OAM发现（Extended OAM Discovery）、扩展OAM能力通告（Extended OAM Capability Notification）功能和版本协商。

扩展的OAM发现过程应在标准的OAM发现过程完成后进行，并且只有标准的OAM和扩展的OAM都完成后才能传送数据业务。扩展的OAM发现过程包括OAM能力发现、协商、附加信息的交换以及OAM消息版本的确认。

ONU和OLT通过在标准的Information OAMPDU中附加额外的扩展Information TLV实现扩展的OAM发现。所有的扩展的OAM发现TLV采用Organization SpecificInformation TLV方式，并应符合IEEE 802.3的规范。用于扩展OAM发现的OAMPDU消息格式如图6-9所示，其中Organization SpecificInformation TLV中各字节的取值如表6-3所示。

图6-9 用于扩展OAM发现的OAMPDU消息格式

表6-3 Organization Specific Information TLV的域及其值

ExtSupport字节用于表示是否支持该OUI的OAM扩展。ExtSupport等于“0x01”，表示支持该扩展OAM；ExtSupport值为“0x00”，表示不支持该扩展OAM；其他值作忽略处理。当确定支持某一扩展OAM后，则进行与该OAM扩展相关的进一步的握手过程。

如802.3-2008的Clause57所述，Organization Specific InformationTLV 包含如下几个域：

a） 信息类型（InformationType）：1字节，为OrganizationSpecific Information类型。用于指示在该TLV中承载的数据的种类。对于Organization Specific Information TLV，其值为“0xFE”（见IEEE 802.3-2005 Table 57–6）。

b） 信息长度（InformationLength）：1字节，用于指示该TLV的长度。Organization Specific Information TLV 的长度未规定。

c） 机构唯一性标识OUI(Organizationally Unique Identifier)：3字节，为机构唯一性标识 OUI。该值应可配置，中国电信的OUI暂定为0x111111。

d） 数据域（Data/OrganizationSpecific Value)：包含Organization Specific Information TLV的数据，其长度和内容未规定。

用于扩展OAM发现的Organization Specific Information TLV的数据（Data）域包含ExtSupport字节和一个所支持的OUI-Version的列表。OUI-Version列表用于提供扩展的OAM能力通告功能，表示该设备支持由该OUI所表示的组织发布的OAM扩展及其版本。OUI of Supported Extension的值应与该OrgnizationSpecific Information TLV中的OUI（即下图中该Information TLV的Length域之后、Data域之前的OUI）相同。在OrganizationSpecific Information TLV中，对OUI-Version的排序没有要求。目前中国电信的EPON企标版本有1.0、1.3、2.0、2.1及此次的3.0版本，如果OUI为中国电信的OUI，相应的OUI-Version的取值只能是0x01、0x13、0x20、0x21和0x30中的一个或几个。

发送端（OLT或者ONU）在发送INFOOAMPDU时，如果该OAMPDU包含标准的INFO TLV（Local Information TLV和Remote Information TLV）和Organization Specific Information TLV，则应优先发送标准的INFO TLV，然后再发送Organization Specific Information TLV。如果Organization SpecificInformation TLV中包含中国电信扩展的INFO TLV和其他机构扩展的INFO TLV，应优先发送中国电信扩展的INFO TLV，然后再发送其他机构扩展的INFO TLV。

EPON系统中OAM接收侧设备（ONU或者OLT）应支持对INFOOAMPDU中多个INFO TLV的解析处理（在InformationOAMPDU中，End of TLV marker用于表示本PDU中再没有其他INFO TLV，因此，接收侧应处理INFO OAMPDU中End of TLV marker之前的所有INFO TLV，包括IEEE802.3标准规定的Local Information TLV和Remote Information TLV、一个或者多个OrganizationSpecific Information TLV）。在接收侧（ONU或者OLT），对于接收到的任何合法的、可解析的（包含双方协商好的特定机构扩展INFO TLV的）OAMPDU，接收侧都应进行相应的处理。如果收到的OAMPDU中包含未知或者不希望接收的TLV类型或者不可解析的INFO TLV，则对该TLV做忽略处理（对该OAMPDU中其他合法的或者能够处理的TLV仍按IEEE802.3或者本规范的要求进行相应的处理）。“不可解析”是指接收侧设备无法理解和处理――即便该TLV格式正确、合法，比如A厂商的ONU收到来自B厂商OLT发来的其私有的TLV，由于该ONU无法理解其TLV内Value域的内容，因此也认为该TLV为“不可解析的”。这个“不可解析就作忽略处理”的原则适用于对所有OAMPDU的处理。

通过扩展的OAM发现，OLT和ONU协商为某一个版本后，OLT应按照该版本的要求进行属性管理和操作，不应向ONU发送其他版本所特有的属性和操作。建议支持较高版本的ONU能兼容较低版本的OAM属性管理和操作。如果支持《中国电信EPON设备技术要求V2.1》的ONU兼容V2.0，那么在该ONU发送给OLT的OAM Ext_INFO中的OUI-Version列表中应明确包含0x20的取值。

扩展OAM的发现流程

扩展的OAM发现流程如图6-10所示。在完成OAMdiscovery过程后，OLT发起扩展的OAM发现流程。OLT首先发送OAM Ext_INFO的消息，通知OLT的OAM扩展的OUI、版本以及所支持的OUI-version列表。ONU根据收到的OLT的信息后，返回一个OAM Ext_INFO，将OUI设置为OLT的OUI，Ver.=0x00，并且将ONU所支持的OUI-Version列表上报给OLT。如果ONU支持该OUI，则ExtSupport=0x01；否则ExtSupport=0x00。OLT根据ONU上报的信息，如果ExtSupport=0x01，且ONU支持OLT当前的OUI的版本，并写入到OAM Ext_INFO->OUI和OAM Ext_INFO-〉Ver.Z，发给ONU，最后ONU收到OLT选择的OUI和版本的消息，返回确认信息，完成了扩展OAM的发现过程。如果ExtSupport=0x01且ONU不支持OLT当前的OUI版本，或者ExtSupport=0x00，则OLT发出告警，上报网管。

“Verof supported Extension”字段采用如下格式：xxxx.yyyy（4比特.4比特）。其中，“xxxx”表示主版本号，“yyyy”表示次版本号。例如，如果设备支持《中国电信EPON设备技术要求V1.3》规定的OAM扩展，则“Ver.Of supported Extension”应设为“01.03”，即0x13；如果设备支持《中国电信EPON设备技术要求V2.0》规定的OAM扩展，则“ver. Of 1st supported Extension”应设为02.00，即0x20。

支持扩展的OAM发现流程的OLT和ONU的状态机分别如图6-11和图6-12所示。

图6-10 扩展的OAM发现流程

图6-11 OLT的扩展OAM发现流程的状态机

图6-12 ONU的扩展OAM发现流程的状态机

扩展的事件通告（EventNotification） OAMPDU消息

概述

EPON设备应支持IEEE802.3－2005中Clause57规定的Event Notification功能，并支持57.5.3中规定的Link Event TLV：Errored Symbol Period Event、Errored FrameEvent、Errored Frame Period Event、Errored Frame Seconds Summary Event。

此外，EPON设备还应支持基于Organization Specific EventNotification机制，以实现各种告警和警示功能。

扩展事件通告OAMPDU的格式和消息定义

扩展的事件通告OAM消息（Event Notification OAMPDU）应符合IEEE802.3-2008Clause57.4.3.2中关于Event Notification OAM的规定。扩展的Event Notification OAMPDU包含一个或者多个OrganizationSpecific Event TLV，具体结构如图6-13所示。扩展的Event Notification OAMPDU中的目的地址、源地址、Length/Type、Subtype、Flags、FCS域的规定与本标准6.5.1节的定义相同。Code和Data域的具体定义如下：

a) Code：本字段值为0x01，表示该OAMPDU为Event Notification OAMPDU；

b) Data：包含Sequence Number、一个或多个OrganizationSpecific Event TLV。其中Sequence Number的具体取值见IEEE802.3-2008 Clause 57.4.3.2，OrganizationSpecific Event TLV的取值如下所示：

l Event Type：这里取值为0xFE；

l Event Length：为整个OrganizationSpecific Event TLV的长度值，单位为字节（Octets）

l OUI：为机构唯一标识码。具体的OUI的值应可配置。中国电信的OUI值暂定为0x111111；

l Organization Specific Value：用于表示具体的扩展的事件通告的内容，具体定义如表6-4所示。

图6-13 Organization Specific EventNotification OAMPDU帧格式

表6-4 事件通告OAMPDU中OrganizationSpecific Value域的构成

扩展的组织特定（Organization Specific）OAMPDU消息概述

扩展的组织特定（Organization Specific）OAMPDU消息结构及定义

扩展的组织特定OAMPDU消息（即Organization Specific OAMPDU）应符合IEEE 802.3-2008 Clause57.4.3.6中关于OAM扩展的规定。本规范所定义的Organization Specific Extension OAMPDU的结构如下图所示6-14所示。Organization Specific OAMPDU中的目的地址、源地址、Length/Type、Subtype、Flags、FCS域的规定与本标准6.5.1节的定义相同。Code和Data域的具体定义如下：

c) Code：本字段值为0xFE，表示该OAMPDU为OrganizationSpecific OAMPDU；

d) Data：包含一个OUI、扩展操作码（Ext. Opcode）和Payload，具体取值如下：

l 机构唯一性标识OUI：3字节，为机构唯一性标识 OUI。该值应可配置，中国电信的OUI暂定为0x111111；

l 扩展的操作码（Ext.Opcode）：用于表示扩展的操作类型，具体取值见表6-5；

l Payload：表示具体的内容。

图6-14 OrganizationSpecific OAMPDU 帧格式

表6-5 扩展的Organization Specific OAMPDU的扩展操作码的取值

各种扩展的操作类型（Extended Operation）描述如下：

——Extended Variable Request：扩展的VariableRequest可以读取标准的和扩展的对象的属性，在每个IEEE 802.3-2008的Variable Request类型的扩展OAMPDU中的数据域包括一系列Variable Descriptor TLV以及管理对象实例索引TLV（如果需要管理对象实例索引TLV的话。关于管理对象实例索引的定义见6.5.6.2）。

——Extended Variable Response：扩展的VariableResponse是对远端Variable Request的响应，在每个IEEE 802.3-2008的Variable Request类型的扩展OAMPDU中的数据域包括一系列Variable Containers TLV。

——Set Request：OLT发送SetRequest类型的OAMPDU对远端ONU的管理对象的参数进行写操作。Set Request类型的OAMPDU中Payload域的格式与Variable Response类型的OAMPDU类似，包含一系列用于指定所要设置的变量（Variable）的Variable Container TLV以及管理对象实例索引TLV（如果需要的话），Variable Container TLV的数据字段包含该变量的设置值。

——Set Response：ONU向OLT发送Set Response类型的OAMPDU，用于确认写操作是否成功。Set Response类型的OAMPDU包含一系列Variable Containers TLV以及管理对象实例索引TLV（如果需要的话），并带有对应于Variable Set消息中每个设置请求（Set Request）和设置操作（Action）的回复码（Return Code）。典型的ariable Containers TLV中的Value/Length字段包含一个操作确认码，具体的操作确认码如本规范6.5.6.5节。

——ONU Authentication：用于基于逻辑标识的ONU认证过程所必需的协议交互过程，具体的消息格式见6.5.11节。

——ONU Software Download：用于ONU软件（包括芯片的固件）升级过程所需要的协议交互过程，具体的消息格式见6.5.12节。

——Churning：用于搅动过程的密钥交换和同步过程所必须的协议交互过程。具体的消息格式见6.5.13节。

——DBA：用于实现DBA的互通性所必须的DBA参数读取和设置功能。具体的消息格式见6.5.14节。

——Event Notification：用于特定Event ID的告警状态及门限的配置与查询。具体的消息格式见6.5.15节。

在ExtendedVariable Request、Extended Variable Response、Set Request、Set Response消息中，应包含本标准定义的标准属性/操作和扩展属性和操作。

扩展OAMPDU中操作对象的实例索引TLV

EPON系统中的操作对象包括端口、LLID、PON接口和ONU等。在图6-14所示的帧格式中的Payload域可能会包含一个或多个操作对象，上述某些操作对象可能存在多个实例。例如对于Port对象而言，每个ONU可能存在多个物理端口。操作对象的实例索引用于标识其后的标准的或扩展的属性与操作所应用的操作对象的实例。

支持《中国电信EPON设备技术要求》V2.0及以下版本的ONU设备应支持附录C规定的实例索引TLV的格式；支持V2.1及以上版本的ONU设备应支持表6-6规定的实例索引TLV的格式，建议兼容附录C所规定的TLV格式（V2.0）。OLT应支持附录C和表6-6规定的操作对象实例索引，并能根据扩展OAM发现过程协商的CTC EPON版本采用相应的实例索引TLV的格式。

操作对象实例索引TLV的格式如表6-6所示。

表6-6 操作对象的实例索引TLV的格式

1） Leaf域的取值如表6-7所示。

表6-7 各种操作对象的Leaf值

2） Value域表示该操作对象的实例编号。针对不同的操作对象，Value域的取值如下所示。

a) 当操作对象为Port时，对ONU上所有类型的UNI端口（包括以太网端口、VoIP端口、E1端口）进行统一编号，编号规则如下：

l Bit31（最高位）～Bit24：表示端口类型。0x01：表示以太网端口；0x02：表示VoIP端口；0x03：表示ADSL2＋端口；0x04：表示VDSL2端口；0x05：表示E1端口；其他值（0x06～0xFF）：预留。

l Bit23～Bit22：表示ONU为多机框级联情况下的机框编号。编号为“0b00”表示该ONU不级联，或者是在ONU级联情况下，直接连接到ODN的ONU（根ONU）；“0b01”表示级联在根ONU下的级联ONU；“0b10”表示级联在第二个ONU下的级联ONU；“0b11”表示级联在第三个ONU下的级联ONU；缺省情况下bit8～bit9的取值为“0b00”。

l Bit21～Bit16：表示ONU的框内的槽位编号。对于FTTH ONU和固定式MDU，本字段取值为“0b000000”。对于插板式MDU，编号范围为“0b000001~0b111110”则扩展的OAM消息中的槽位编号应与ONU面板上的槽位编号严格的一一对应（OAM编号＝面板编号），编号从1起始，至62止。对于插板式MDU，槽位编号为“0b111111”（63）表示该ONU机框上所有槽位的集合。

l Bit15～Bit0（最低位）：表示ONU特定板卡上的用户端口的编号，端口编号范围为0x01~0xFF，扩展的OAM消息中的端口编号应与ONU面板的端口编号严格的一一对应（OAM编号＝面板编号），应从1起始，至255止。0xFFFF表示该槽位内的所有用户端口的集合。对于编号为“0xFFFF”的属性（Attribute）管理和操作（Action）即为对该板卡上所有物理端口均执行相同的属性管理和操作。

b) 当操作对象为LLID时，Value域表示LLID的编号，取值范围从0x00-00-00-00到0x00-00-FF-FF。其他值保留，在接收时忽略处理。该操作对象仅适用于对工作在多LLID模式下的ONU的LLIDQueueConfig属性进行操作。工作在多LLID模式下的ONU的其他属性和工作在单LLID模式下的ONU不使用该操作对象。

c) 当操作对象为PON IF时，Value域表示PON接口的编号，取值为0x00-00-00-00和0x00-00-00-01，其他值保留，在接收时忽略。该操作对象仅适用于支持光链路保护的ONU，其余ONU不使用该操作对象。

d) 当操作对象为ONU时，扩展OAMPDU中不携带表6-6所示的实例索引TLV。

如果OLT和ONU接收到的扩展OAMPDU中的实例索引格式不符合规范要求，接收侧应对该OAMPDU做忽略处理。当OLT向ONU发送的OAMPDU中包含操作对象的实例索引TLV以及对应于该实例的特定属性/操作的Variable Container/Descriptor时，ONU返回给OLT的OAMPDU也应采用相同的操作对象的实例索引的Variable Container。

VariableDescriptor TLV和VariableContainer TLV

在图6-14所示的Payload域中，每个操作对象的实例索引TLV之后可以存在针对该实例的多个属性/操作(Attribute/Action)的Variable Descriptor TLV或Variable ContainerTLV。在一个扩展OAMPDU中，一个操作对象实例索引之后的全部Variable Descriptor或Variable Container均为针对该实例的属性和操作，直至该OAMPDU的数据部分结束（即出现Padding）或出现该操作对象的另外一个实例索引或者另外一个操作对象的Variable Descriptor/Container。

Variable Descriptor TLV和Variable Container TLV的格式应符合IEEE 802.3的规定，其中Branch和Leaf的应符合6.5.6.4节的规定。

扩展的属性和操作

扩展OAM管理对象的Branch值

对于ONU各种对象的属性和操作管理，其Variable Descriptor TLV或Variable ContainerTLV中的Branch值如表6-8所示。

表6-8 扩展OAM管理对象的Branch值

扩展OAM管理对象的Leaf值

对于ONU各种对象的属性和操作管理，其Variable Descriptor TLV或Variable ContainerTLV中的Leaf值如表6-9所示。

表6-9 扩展的属性和操作的Branch值

扩展OAM的管理对象要求

OLT和各种类型ONU应支持的扩展OAM的管理对象要求如表6-10所示。扩展OAM的管理对象的具体格式见附录D。

表6-10 扩展OAM的管理对象要求

扩展OAMPDU的回复码（return code）

ONU需要对OLT发出的Extended Get Request OAMPDU和Set Request OAMPDU进行确认，需要在应答的Extended GetResponse OAMPDU和Set Response OAMPDU中的Variable Container内的length域携带回复码。回复码的取值及说明应符合IEEE 802.3-2008 Subclause 57.6.5的规定。IEEE802.3-2008中57.6.5节定义的回复码均可用于ExtendedGet Response OAMPDU和Set Response OAMPDU。同时，为了更好的实现对OLT发送的消息的确认，本标准对Variable Container的Variable Indication（bit7=1）指示的回复码做相应扩展：

当Variable Indication的值为0x80时，表示Set Request的属性（Attribute）或操作（Action）操作成功的确认；当Variable Indication的值为0x86时，表示Extended Get Request或Set Request请求的属性（Attribute）或操作（Action）的参数无效（VarBadParameters）；当VariableIndication的值为0x87时，表示Extended GetRequest或Set Request请求的属性（Attribute）或操作（Action）的参数有效，但ONU的当前状态使该操作无法完成（VarNoResource）。如表6-11所示。

表6-11 ExtendedVariable Respons

Extended Get Request扩展OAM

Extended Get Request扩展OAMPDU用于OLT向ONU查询相关属性和操作，具体消息结构如图6-15所示。每个实例索引TLV后可以包含一个或多个Variable Descriptor TLV，这些VariableDescriptor TLV均是对这个实例索引TLV的各种属性和操作进行查询。Extended Get Request扩展OAMPDU消息可以包含一个或多个实例索引TLV。

图6-15 Extended GetRequest扩展OAMPDU消息结构

如果操作对象是Port，Value值为0xFF-FF-FF-FF，则表示对该ONU的所有端口进行查询。如果操作对象是ONU，在Extended Get Request扩展OAMPDU消息中不存在实例索引TLV。

Extended Get Request扩展OAMPDU消息的管理对象参见附录D。

Extended Get Response扩展OAM

Extended Get Response扩展OAMPDU用于ONU向OLT回复其查询的相关属性和操作，具体消息结构如图6-16所示。Extended Get Response扩展OAMPDU应分别对Extended Get Request消息的每个实例对象的每个属性或操作进行回复；即每个实例索引TLV后可以包含一个或多个Variable Container TLV，与Extended Get Request扩展OAMPDU消息中的Variable Descriptor TLV一一对应；Extended GetResponse扩展OAMPDU消息可以包含一个或多个实例索引TLV，与Extended Get Request扩展OAMPDU消息中的实例索引TLV一一对应。

如果Extended Get Request扩展OAMPDU中的操作对象是Port，Value值为0xFF-FF-FF-FF；则Extended Get Response扩展OAMPDU应针对每个端口的实例索引分别返回查询结果。如果在Extended GetRequest扩展OAMPDU消息中不存在实例索引TLV，即操作对象是ONU；则Extended Get Response扩展OAMPDU消息中也不应携带实例索引TLV。

图6-16 Extended Get Response扩展OAMPDU消息结构

考虑到Variable ContainerTLV中的Variable Width最大值为128，如果某个Variable Container TLV中携带的Value的长度大于128，则应将该Variable Container TLV进行分段传输，如图6-17所示。OLT接收时，如果检测到连续的Variable Container TLV中含有同样的Branch和Leaf字段，应认为这是同一个Variable Container TLV。

图6-17 Extended GetResponse扩展OAMPDU消息举例

如果Extended Get Response扩展OAMPDU消息中回复码的取值与IEEE 802.3-2008的表57-17或本标准表6-11相同的话，ExtendedGet Response扩展OAMPDU消息的VariableContainer不携带Value域。

Extended Get Request扩展OAMPDU消息的管理对象参见附录D。

Extended Set Request扩展OAM

Extended Set Request扩展OAMPDU用于OLT向ONU设置相关属性和操作，具体消息结构如图6-18所示。每个实例索引TLV后可以包含一个或多个Variable Container TLV，这些Variable ContainerTLV均是对这个实例索引TLV的各种属性和操作进行设置。ExtendedSet Request扩展OAMPDU消息可以包含一个或多个实例索引TLV。

如果Extended Set Request扩展OAMPDU中的某个Variable Container TLV中携带的Value的长度大于128，则应将该VariableContainer TLV进行分段传输，如图6-17所示。ONU接收时，如果检测到连续的Variable Container TLV中含有同样的Branch和Leaf字段，应认为这是同一个Variable Container TLV。

图6-18 Extended Set Request扩展OAMPDU消息结构

如果操作对象是Port，Value值为0xFF-FF-FF-FF，则表示对该ONU的所有端口进行查询。如果操作对象是ONU，在Extended Get Request扩展OAMPDU消息中不存在实例索引TLV。

Extended Set Request扩展OAMPDU消息的管理对象参见附录D。

Extended Set Response扩展OAM

Extended Set Response扩展OAMPDU用于ONU向OLT回复其查询的相关属性和操作，具体消息结构如图6-19所示。Extended Set Response扩展OAMPDU应分别对Extended Set Request消息的每个实例对象的每个属性或操作进行回复。具体回复码的取值参见与EEE 802.3-2008的表57-17或本标准表6-11的规定。Extended Get Response扩展OAMPDU消息的Variable Container不携带Value域。

图6-19 Extended Set Request扩展OAMPDU消息结构

Extended Set Response扩展OAMPDU消息的管理对象参见附录D。

ONU认证（Authentication）相关扩展OAM

基于逻辑标识的ONU认证的扩展OAM消息采用值为“0x05”的扩展操作码。具体消息格式如图6-20所示。

图6-20 用于基于逻辑标识的ONU认证的OAMPDU格式

图中Auth_Code字段（长度为1字节）表示具体的ONU认证操作。包括如下4种操作类型：

——认证请求（Auth_Request）：值为0x01，由OLT向ONU发出，以请求ONU上报其LOID和Password；

——认证响应（Auth_Response）：值为0x02，作为ONU对OLT发来的Auth_Request报文的响应，向OLT上报其LOID和Password；

——认证成功（Auth_Sucess）：值为0x03，由OLT向ONU发出，表明该ONU已经通过认证；

——认证失败（Auth_Failure）：值为0x04，由OLT向ONU发出，表明该ONU认证失败。

Length of AuthenticationData字段（长度为2字节）表示其后面的AuthenticationData字段的长度，单位为字节。

Authentication Data字段（其长度和内容取决于Auth_Code）为具体的数据，具体规定如下：

1） 认证请求报文（Auth_Request）：

Auth_Request报文的Authentication Data字段包括Auth_Type字段，长度为1字节。Auth_Type字段表示认证类型。在Auth_Request报文中Auth_Type默认取值为0x01：表示LOID+Password方式，即要求ONU在Auth_Response报文上报其LOID和Password；其他取值保留作为扩展。

2） 认证响应（Auth_Response）：

Auth_Response报文的Authentication Data字段包括Auth_Type字段（长度为1字节）和Auth_Type_Data字段（长度可变）。

Auth_Type字段表示认证类型。目前，在Auth_Response报文中Auth_Type有2个取值：取值为0x01时的定义与Auth_Request报文中的定义相同；取值为0x02时表示ONU不支持或不能接受Auth_Request消息中请求的认证类型（Auth_Type），即Nak（这个取值仅对Auth_Response有意义，即Auth_Response Only）；其他取值保留。

当Auth_Type＝0x01时，Auth_Response报文中的Auth_Type_Data字段包含长度为24字节的LOID和长度为12字节的Password。LOID和Password均以ASCII码表示。这种情况下的Auth_Response报文及Auth_Type_Data字段的格式如图6-21（a）所示。如果LOID/Password的实际长度小于24字节/12字节，则在实际的ONU_ID/Password前面填ASCII码的“NUL”（十六进制数为0x00）以补足24字节/12字节。实际的LOID和Password（不包含为补足24/12字节而填充的“NUL”）均不应以从“NUL”到“SPACE”的特殊字符（十六进制值为0x00～0x20）、“@”字符、“DEL”字符以及标点符号开始，也不应以上述字符结束。

当Auth_Type＝0x02时，Auth_Response报文中的Auth_Type_Data字段包含长度为一个字节的Desired Auth_Type，该字段表示ONU希望采用的认证类型（当前的缺省值为0x01，表示希望采用的认证类型为LOID+Password方式，因为暂时没有其他认证类型）。这种情况下的Auth_Response报文及Auth_Type_Data字段的格式如图6-21（b）所示。

通常Auth_Response中的Auth_Type域和Auth_Request中的Auth_Type域相同，除Auth_Response中返回值为Nak的Auth_Type情况除外。

3） 认证成功（Auth_Sucess）：

Auth_Sucess报文不存在Authentication Data字段，所以其Length of Authentication Data字段为0x00。

4） 认证失败（Auth_Failure）

Auth_Failure报文格式如图11-9（c）所示，其Length of Authentication Data字段为0x01，其Authentication Data字段仅包含一个字节的“Failure_Type”字段。Failure_Type＝0x01表示LOID不存在；Failure_Type＝0x02表示LOID存在但Password错误；Failure_Type＝0x03表示LOID冲突，即已有该LOID的ONU认证成功。

（a） Auth_Response报文格式（LOID+PW类型）

（b） Auth_Response报文格式（Nak类型）

（c） Auth_Failure报文格式

图6-21 几种典型认证报文的格式

ONU软件升级（Software Upgrade）相关扩展OAM

在EPON系统中，用于软件/固件的远程升级信息由扩展OAMPDU承载，采用Orgnization-Specific Extension 方式实现其交互过程，扩展操作码的值为“0x06”。具体消息的格式如图6-22所示：

图6-22 软件升级的扩展OAMPDU 帧格式

Payload字段中包括Data Type、Length、TID和Messageformat 三个域：

a) Data Type：表示Payload部分的数据类型，0x01表示是软件下载的数据；0x02表示是校验文件完整性的数据；0x03表示是加载并执行软件镜像的数据。

b) Length：表示Payload域的字节长度，是Data Type、Length、TID和Message format三个域的长度之和；

c) TID：采用ONU的LLID号来表示TID，在M-LLID模式下，采用Base LLLID号来表示TID；

d) Message format：包括4种消息类型。其中，第一种为软件下载消息，包括File Write Request（相当于TFTP协议中的Write Request消息）， File Transfer Data（相当于TFTP协议中的Data消息），FileTransfer ACK（相当于TFTP协议中的ACK消息）和Error消息（相当于TFTP协议中的Error消息），其Data Type的值均为0x01，这四种软件下载消息的格式应符合图6-23的规定。第二种为文件完整性校验消息，包括End DownloadResquest和End Download Response两个消息，其Data Type的值均为0x02。第三种为文件激活消息，包括Activate Image Request和Activate ImageResponse消息，用于配置ONU激活并执行有效的镜像软件，其Data Type的值均为0x03。第四种为软件加载消息，包括Commit Image Request和Commit Image Response消息，用于将当前备用存储区的软件变为主用存储区的软件，并作为ONU启动时默认加载执行的软件，其Data Type的值均为0x04。消息的具体格式如图6-23所示：

图6-23 软件升级扩展OAM消息中Message Format的格式

软件/固件下载过程的消息交互协议

ONU软件升级过程有如下几种消息：

• File Write Request：File WriteRequest消息用于向接收端发起文件接收请求，接收端应按照该消息的要求接收一个文件。接收端在接收到该文件接收请求前应发送File Transfer ACK消息作为对File Write Request的应答，并且序列号（Block number）为0，或者发送Error消息表示有错误，错误类型参见ErrorCode域。在File Write Request消息内，Mode域应为“Octet”，其他域的定义应符合IETF RFC1350的规定。Filename域的格式应为”Vendor.ONU type.software version.date”。

• File Transfer Data：每个文件均应分为一个或者多个分段（Block）依次传输。每个File Transfer Data消息带有一个序列号（block number）和数据文件中的一个分段。分段大小在0～1400字节之间变化，如果是1400字节长则该分段不是最后一个分段，否则是文件的最后一个分段。数据帧应按照顺序发送，第一个分段的序列号是1，随后的分段的序列号依次递增。只有当数据帧的发送端收到接收端的确认发送才能发送下一个数据帧。

• File Transfer Ack：该消息用于对FileWrite Request、File Transfer Data消息的确认。File Transfer ACK消息包含一个序列号，表示ONU此次接收的分段的序列号。

• Error：用于服务器不能处理读请求或写请求的情况。在文件传输过程中的读和写差错也会导致传送这种报文，接着停止传输。ErrorCode域的取值如下：

0x00-00 不作规定，具体信息参见ErrMsg域（如果存在ErrMsg域的话）；

0x00-03 软件镜像文件的存储空间已满；

0x00-04 接收到非法的软件升级扩展OAM消息；

0x00-06 软件镜像文件已经存在；

其余值预留，在接收时忽略。

ErrMsg域是在ErrorCode = 0x00-00时，用来提供额外的信息。ErrMsg消息以ASCII码的“NULL”（0x00）终结。

• End DownloadRequest：用于校验该消息给出的文件的正确性，并且确认该文件是否成功写入非易失性存储器（non-volatile storage，如flash）。该消息的参数包括传送的文件的大小。该消息在OLT收到最后一个分段的File Transfer ACK消息后才能发送。

• End DownloadResponse：该消息用于对End Download Request消息的确认。在这个消息中，RPSCode＝0x00，表示下载的软件校验成功并且已经写入非易失性存储器；RPSCode＝0x01，表示ONU正在将软件写入非易失性存储器；RPSCode＝0x02，表示下载的软件校验错误；RPSCode＝0x03，表示OLT发送的消息参数错误；RPSCode＝0x04，表示ONU不支持该命令。

• Activate ImageRequest：该消息用于激活并执行一个有效的镜像文件。在这个消息中，如果Flag字段的值为“0x00”，表示挂起主用启动存储区的软件，加载并执行备用存储区（新下载的或者未激活的）有效的软件镜像。ONU收到该Flag=0x00的ActivateImage Request消息后，应返回Activate Image Response消息，并将主用存储区的软件镜像挂起，然后使用备用存储区的软件镜像重新启动。ONU以后重启时，若新加载的软件没有被commited之前，仍然使用原有的主用存储区的软件镜像。

• Activate ImageResponse：该消息用于对Activate Image Request消息的确认。ACK＝0x00，表示设置成功；ACK＝0x01，表示OLT发送的消息参数错误；ACK＝0x02，表示ONU不支持该命令；ACK＝0x03，表示ONU加载失败。

• Commit ImageRequest：Flag=“0x00”，则该消息将当前备用存储区的软件变为主用存储区的软件，作为ONU启动时默认加载执行的软件，而主用区的软件镜像变为备用区的软件。当ONU以后重启，均使用新主用存储区的软件镜像。

• Commit ImageResponse：该消息用于对Commit Image Request消息的确认。ACK＝0x00，表示设置成功；ACK＝0x01，表示OLT发送的消息参数错误；ACK＝0x02，表示ONU不支持该命令；ACK＝0x03，表示ONU加载失败。

搅动（Churning）相关扩展OAM

用于搅动的密钥交互消息包括两种类型：

1） 新密钥请求帧（new_key_request）

2） 新密钥通知帧（new_churning_key）

对于基于扩展的组织特定OAMPDU消息进行密钥更新和同步的系统，通过“Organization Specific” OAMPDU (Code=0xFE)通过Flag域进一步标识消息类型。

EPON系统中的扩展的组织特定OAMPDU消息的格式应符合本标准6.5.6.1节的规定。

EPON系统中的用于Churning的Organization-SpecificExtension OAM消息中Payload部分的格式如表6-12所示。Churning Code域的值对应的消息类型如表6-13所示

表6-12 用于搅动的Organization Specific Extension OAM消息中payload部分的格式

表6-13 用于搅动的扩展OAM消息中Churning Code域的值及其对应的消息类型

对搅动相关的OAM消息的规定如下：

1） 新密钥请求帧（new_key_request）

新密钥请求帧的定义如图6-24所示。Churning_code=“0x00”，In-use_Key_Index字节的最低位用于指示OLT正在使用的密钥的序号（“0”或者“1”），其他比特为“0”。In-use Key Index域之后为填充字节。

图6-24 new_key_request消息的帧格式

2） 新密钥通知帧（new_churning_key）

1G-EPON ONU发送的新密钥通知帧的定义如图6-25所示，10G-EPON ONU发送的新密钥通知帧的定义如图6-26所示。Churning_code=“0x01”，New_Key_Index字节的最低位用于指示所发送的密钥的序号（“0”或者“1”），其他比特为“0”。1G-EPON ONU的Churning Key字段包含3字节的新搅动密钥，传送顺序为[(MSB)X1,X2,…,X8,P1,P2,…,P16(LSB)]。10G-EPON ONU的Churning Key字段包含3个3字节的新搅动密钥，第一个3字节的Churning Key字段包含第一级搅动的新搅动密钥，传送顺序为[(MSB)X1,X2,…,X8,P1,P2,…,P16(LSB)]；接着两个3字节的Churning Key字段分别包含第二级和第三级搅动的新搅动密钥，传送顺序均为[(MSB)X1,X2,…,X8,P1,P2,…,P16(LSB)]。Churning Key字段之后为填充字节。

图6-25 1G-EPON ONU new_churning_key消息的帧格式

图6-26 10G-EPON ONU new_churning_key消息的帧格式

DBA参数配置的扩展OAM

DBA参数远程管理功能定义

DBA的管理属性包括ONU的Report帧支持的Queue Set数量和每个Queue Set所对应的阈值（Threshold）。DBA协商的OAM扩展主要涉及对ONU所要支持的Queue Set的数量及其阈值进行操作。

在ONU的DBA参数配置过程中，OLT应工作在主动（Active）模式，ONU工作在被动（Passive）模式。OLT通过get_DBA_request消息和set_DBA_request消息对ONU的DBA参数进行读取和设置操作，ONU通过get_DBA_response消息和set_DBA_response消息对OLT的读取和设置操作请求做出应答。

当ONU接收到get_DBA_request消息后，应向OLT发送get_DBA_response消息，该消息中包含其当前DBA参数值。

当ONU接收到set_DBA_request后，应按照set_DBA_request消息所定义的DBA参数设置本地的DBA参数，并发送set_DBA_response消息，以确认其是否已完成此次DBA参数设置。

DBA参数远程管理过程的消息定义

在EPON系统中，用于ONU的DBA参数远程管理的信息由OAMPDU承载，采用Organization-Specific Extension 方式实现其交互过程，扩展操作码（Ext. Opcode）的值为“Ox0A”。用于ONU的DBA参数管理的Organization-SpecificExtension OAMPDU的Data/padding部分的格式如表6-14所示，DBA Code域进一步标识ONU的DBA参数配置功能所需要的消息类型。

表6-14 用于DBA的Organization-SpecificExtension OAM消息中payload部分的格式

用于ONU的DBA参数配置的Organization Specific Extension OAM消息包括4种类型，具体的消息编码如表6-15所示：

1) DBA参数请求帧（get_DBA_request）

2) DBA参数响应帧（get_DBA_response）

3) DBA参数设置请求帧（set_DBA_request）

4) DBA参数设置确认帧（set_DBA_response）

表6-15 Organization-SpecificExtension OAM消息中DBA Code域的值及其对应的消息类型

该四种消息的具体定义如下：

1） DBA参数请求帧（get_DBA_request）

OLT利用DBA参数请求帧指示ONU汇报其当前的DBA参数（Report帧中的Queue Set数量和阈值）。DBA参数请求OAMPDU的结构如图6-27所示，Data/Pad域的详细的定义如下：

a) OUI：3字节，包含24比特Organizationally Unique Identifier。具体的OUI值待定；

b) 扩展操作码（Ext.Opcode）：1字节，用于标识扩展的操作类型，对于用于DBA参数配置的扩展的OAMPDU，其值为“0x0A”；

c) DBA code：1字节，用于标识具体的DBA参数操作类型，对于get_DBA_request消息，其值为“0x00”；

d) 填充字节（PAD）：0～30个字节，用于填充该OAM帧中的剩余字段使该OAM帧的总长度达到64字节，填充内容为“0x00”。

图6-27 get_DBA_requestOAMPDU的帧格式

2） DBA参数响应帧（get_DBA_response）

ONU利用DBA参数响应帧向OLT汇报其当前的DBA参数（Report帧中的Queue Set数量和阈值）。DBA参数响应帧的结构如图6-28所示，Data/Pad域的详细的定义如下：

a) OUI：3字节，包含24比特Organizationally Unique Identifier。具体的OUI值待定；

b) 扩展操作码（Ext. Opcode）：1字节，用于标识扩展的操作类型，对于用于DBA参数配置的扩展的OAMPDU，其值为“0x0A”；

c) DBA code：1字节，用于标识具体的DBA参数操作类型，对于get_DBA_response消息，其值为“0x01”；

d) 队列集数量（Numberof Queue Sets）：1字节，用于描述ONU所发送的Report帧中的队列集（Queue Set）的数量，取值范围为“0x02”到“0x04”；

e) 报告位图（ReportBitmap）：1字节，为一个8比特标志寄存器，指明Report MPCPDU中包含哪些队列，如表6-16所示；

f) 队列n的阈值（Queue ＃n Threshold）：2字节，表示队列n上，该Queue Set所对应的阈值；

g) 填充字节（PAD）：37字节，用于填充该OAM帧中的剩余字段使该OAM帧的总长度达到64字节，填充内容为“0x00”。

图6-28 get_DBA_responseOAMPDU帧格式

表6-16 用于DBA 参数管理的OAMPDU中的报告位图（Report bitmap）域的定义

3） DBA参数设置请求帧（set_DBA_Request）

OLT利用DBA参数设置请求帧指示ONU设置其DBA参数（Report帧中的Queue Set数量和阈值）。DBA参数设置请求帧的结构如图6-29所示，Data/Pad域的详细的定义如下：

a) OUI：3字节，包含24比特Organizationally Unique Identifier。具体的OUI值待定；

b) 扩展操作码（Ext.Opcode）：1字节，用于标识扩展的操作类型，对于用于DBA参数配置的扩展的OAMPDU，其值为“0x0A”；

c) DBA code：1字节，用于标识具体的DBA参数操作类型，对于set_DBA_request消息，其值为“0x02”；

d) 队列集数量（Numberof Queue Sets）：1字节，用于描述ONU所发送的Report帧中应有的队列集（Queue Set）的数量，取值范围为“0x02”到“0x04”，ONU应按照该值设置其REPORT帧中的队列集数量；

e) 报告位图（ReportBitmap）：1字节，为一个8比特标志寄存器，指明Report MPCPDU中应包含哪些队列，如表6-16所示。

f) 队列n的阈值（Queue ＃n Threshold）：2字节，表示队列n上，该Queue Set所对应的阈值；第一个Queue Set的Queue ＃n Threshold的值应小于第二个Queue Set的Queue ＃n Threshold的值，依次类推；

g) 填充字节（PAD）：0～30个字节，用于填充该OAM帧中的剩余字段使该OAM帧的总长度达到64字节，填充内容为“0x00”。

图6-29 set_DBA_requestOAMPDU帧格式

注：本标准规定Report帧格式中最后一个Queue Set用于填写所有队列的全部长度，因此，set_DBA_request帧中的Queue＃n Threshold的数量为（Number of Queue Sets-1）

4） DBA参数设置确认帧（set_DBA_response）

ONU向OLT发送DBA参数设置确认帧（set_DBA_response）以通告其是否成功设置DBA参数。DBA参数设置确认帧的结构如图6-30所示，Data/Pad域的详细的定义如下：

a) OUI：3字节，包含24比特Organizationally Unique Identifier。具体的OUI值待定；

b) 扩展操作码（Ext.Opcode）：1字节，用于标识扩展的操作类型，对于用于DBA参数配置的扩展的OAMPDU，其值为“0x0A”；

c) DBA code：1字节，用于标识具体的DBA参数操作类型，对于set_DBA_response消息，其值为“0x03”；

d) 设置确认（Set ACK）：1字节，用于表示ONU的DBA参数设置是否成功；当Set ACK的值为“0x00”表示DBA参数设置未完成或被拒绝（Nack）；当Set ACK的值为“0x01”表示DBA参数设置已完成（Ack）；

e) 队列集数量（Numberof Queue Sets）：1字节，用于描述ONU的Report帧中应有的队列集（Queue Set）的数量（DBA参数设置后），取值范围为“0x02”到“0x04”，ONU应按照该值设置其REPORT帧中的队列集数量；

f) 报告位图（ReportBitmap）：1字节，为一个8比特标志寄存器，指明Report MPCPDU中应包含哪些队列（DBA参数设置后），如表6-16所示；

g) 队列n的阈值（Queue ＃n Threshold）：2字节，表示队列n上，该Queue Set所对应的阈值；第一个QUEUE set的Queue ＃nThreshold的值应小于第二个Queue Set的Queue＃n Threshold的值(如果包含3个或3个以上的Queue Set)，依次类推；

h) 填充字节（PAD）：1～29个字节，用于填充该OAM帧中的剩余字段使该OAM帧的总长度达到64字节，填充内容为“0x00”。

图6-30 DBA参数设置确认帧的格式

注：本标准规定Report帧格式中最后一个Queue Set用于填写所有队列的全部长度，因此，set_DBA_request帧中的Queue＃n Threshold的数量为（Number of Queue Sets-1）。

事件(Event)相关扩展OAM

事件相关扩展OAMPDU消息结构

事件相关的扩展OAM消息用于OLT和ONU之间来交换特定事件（警示/警告）的告警状态（打开/关闭）和相应的告警产生/清除的阈值。具体的消息结构如图6-31所示。

图6-31 事件相关扩展OAMPDU的格式

事件相关扩展OAMPDU类型

事件相关扩展OAMPDU消息的类型如下所示：

a) EventStatus_Request消息用于OLT查询特定Alarms/Warnings的告警状态, 包含一个或者多个ObjectType，ObjectInstance和EventID的三元组；

b) EventStatus_Set消息用于OLT来设置特定Alarms/Warnings的告警状态, 包含一个或者多个ObjectType，ObjectInstance和EventID的三元组；

c) EventStatus_Reponse消息用于ONU返回对EventStatus_Request消息和EventStatus_Set消息的应答；

d) EventThreshold_Request消息用于OLT查询特定Alarms/Warnings的的告警产生/清除的阈值, 包含一个或者多个ObjectType，ObjectInstance和EventID的三元组；

e) EventThreshold_Set消息用于OLT来设置特定Alarms/Warnings的的告警产生/清除的阈值, 包含一个或者多个ObjectType，ObjectInstance和EventID的三元组；

f) EventThreshold_Reponse消息用于ONU返回对EventThreshold_Request消息和EventThreshold_Set消息的应答。

如果任何事件相关类型的OAMPDU不包含ObjectType，ObjectInstance，EventID等内容，在接收时应忽略。

EventStatus_Request扩展OAMPDU类型

EventStatus_Request消息用于OLT查询特定Alarms/Warnings的告警状态, 包含一个或者多个ObjectType，ObjectInstance和EventID的三元组。具体格式如表6-17所示。

表6‑17 EventStatus_Request扩展OAMPDU格式

ObjectType、ObjectInstance和AlarmID的具体要求同本标准6.5.5.2节的规定。

EventStatus_Set扩展OAMPDU类型

EventStatus_Set消息用于OLT来设置特定Alarms/Warnings的告警状态, 包含一个或者多个ObjectType，ObjectInstance和EventID的三元组。具体格式如表6-18所示。

表6‑18 EventStatus_Set扩展OAMPDU格式

ObjectType、ObjectInstance和AlarmID的具体要求同本标准6.5.5.2节的规定。

EventStatus_Response扩展OAMPDU类型

EventStatus_Reponse消息用于ONU返回对EventStatus_Request消息和EventStatus_Set消息的应答。具体格式如表6-19所示。

表6‑19 EventStatus_Respone扩展OAMPDU格式

ObjectType、ObjectInstance和AlarmID的具体要求同本标准6.5.5.2节的规定。

EventThreshold_Request扩展OAMPDU类型

EventThreshold_Request消息用于OLT查询特定Alarms/Warnings的的告警产生/清除的阈值, 包含一个或者多个ObjectType，ObjectInstance和EventID的三元组。具体格式如表6-20所示。

表6-20 EventThreshold_Request扩展OAMPDU格式

ObjectType、ObjectInstance和AlarmID的具体要求同本标准6.5.5.2节的规定。

EventThreshold_Set扩展OAMPDU类型

EventThreshold_Set消息用于OLT来设置特定Alarms/Warnings的的告警产生/清除的阈值, 包含一个或者多个ObjectType，ObjectInstance和EventID的三元组。具体格式如表6-21所示。

表6-21 EventThreshold_Set扩展OAMPDU类型

ObjectType、ObjectInstance和AlarmID的具体要求同本标准6.5.5.2节的规定。

EventThreshold_Response扩展OAMPDU类型

EventThreshold_Reponse消息用于ONU返回对EventThreshold_Request消息和EventThreshold_Set消息的应答。具体格式如表6-22所示。

表6-22 EventThreshold_Response扩展OAMPDU类型

ObjectType、ObjectInstance和AlarmID的具体要求同本标准6.5.5.2节的规定。

ONU的初始化自动配置

当ONU上电后，OLT应自动将所有必需的配置数据自动下发给ONU。

ONU完成MPCP注册、标准和扩展的OAM发现过程后，OLT应向ONU查询ONU SN、ONU芯片的FirmwareVer、ONUChipset ID、ONU Capabilities-1、ONUCapabilities-2、ONU Capabilities-3等属性，并根据ONU返回的ONU Capabilities-1或者ONU Capabilities-2属性确定ONU支持的端口编号方式（表9或者表12），然后启用三重搅动功能，并进行DBA参数配置。

对于SFU/HGU设备，在完成三重搅动和DBA参数配置后，OLT应根据业务需求远程配置如下功能和参数：以太网端口/E1/VOIP端口的打开，以太网端口的VLAN配置、ONU每个端口业务流分类/排队/标记规则、以太网端口上行限速（Policing）功能、以太网端口流控功能、组播相关功能等内容。每次SFU/HGU重新注册后，需等待OLT重新下发OAM消息，不保存OLT以前下发的OAM消息。

对于新安装的MDU/MTU/SBU设备，在完成三重搅动和DBA参数配置后，EMS通过SNMP对MDU/MTU进行远程配置，配置完成后将其保存在MDU/MTU本地存储器。当MDU/MTU/SBU由于断电或者人工使能重启动等原因重新启动后，MDU/MTU/SBU需等待OLT重新下发OAM消息，不保存OLT以前下发的OAM消息；基于OLT远程下发的OAM消息和本地存储器中保存的配置文件进行相关业务配置的恢复，而不需要由EMS重新下发相关配置（参见18.2.2）。

ONU的缺省配置

在缺省状态下，ONU采用如下配置：

1) 以太网端口状态（aPhyAdminState）：Enabled；

2) E1/VoIP端口状态：Disabled；

3) VLAN配置：Transparent模式；

4) 组播控制：IGMP/MLD Snooping模式（CTC动态可控组播协议：Disabled）。

5) Classification& Marking功能：Disabled；

6) FEC功能（aFECmode）：Disabled；

7) 端口自协商：Enabled；

8) MDT/MTU的ONU的端口之间是隔离的；

9) 告警功能：关闭

其他属性的缺省值暂不规定。

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/204016.html原文链接：https://javaforall.cn