IEEE 803.3-2005 第 5 章：以太网 subscriber access 网络标准

5星 · 超过95%的资源需积分: 9 190 浏览量更新于2024-07-31 收藏 3.97MB PDF 举报

IEEE 803.3-2005-SECTION 5 IEEE 803.3-2005-SECTION 5是IEEE 803.3标准的第五章节，该章节详细介绍了以太网（Ethernet）在subscriber access networks中的应用，特别是Ethernet in the First Mile（EFM）的技术规范。关键知识点一：Ethernet in the First Mile（EFM） EFM是一种基于以太网技术的subscriber access network解决方案，旨在提供高速、可靠的网络接入服务。EFM技术将以太网媒体访问控制（MAC）和MAC控制子层进行了扩展，使其能够在subscriber access networks中提供point-to-point（P2P）连接和point-to-multipoint（P2MP）连接。关键知识点二：Physical Medium Dependent（PMD）子层 PMD子层是EFM技术中的一部分，负责处理物理层面的数据传输。PMD子层包括光纤和语音级铜缆物理介质子层，用于实现P2P连接和P2MP连接。关键知识点三：Ethernet Passive Optical Network（EPON） EPON是一种基于EFM技术的P2MP网络拓扑结构，使用被动式光纤分离器来实现网络连接。EPON技术可以提供高速、可靠的网络接入服务，适用于大规模的subscriber access networks。关键知识点四：MAC控制子层 MAC控制子层是EFM技术中的一部分，负责处理媒体访问控制和流量控制。MAC控制子层的扩展使得EFM技术能够在subscriber access networks中提供高效的网络接入服务。关键知识点五：Clause 56-67和Annex 58A-67A Clause 56-67和Annex 58A-67A是IEEE 803.3-2005-SECTION 5中的规范部分，详细介绍了EFM技术的要求和规范，包括物理层面的规范、数据链路层面的规范和网络层面的规范。 IEEE 803.3-2005-SECTION 5详细介绍了Ethernet in the First Mile（EFM）技术在subscriber access networks中的应用，包括Physical Medium Dependent（PMD）子层、Ethernet Passive Optical Network（EPON）和MAC控制子层等关键技术规范。

IEEE

Std 802.3-2005 REVISION OF IEEE Std 802.3:

57.2.8.2.2 Semantics of the service primitive

The semantics of the primitive are as follows:

OAMI.indication (

destination_address,

source_address,

oam_service_data_unit,

frame_check_sequence,

reception_status

)

The destination_address parameter is the Slow Protocols Multicast Address as specified by the DA field of

the incoming frame. The source_address parameter is an individual address as specified by the SA field of

the incoming frame. The oam_service_data_unit parameter specifies the OAM service data unit as received

by the internal OAM function. The frame_check_sequence parameter, if present, is the cyclic redundancy

check value (see 3.2.8) as specified by the FCS field of the incoming frame. The reception_status parameter

is used to pass status information to the internal OAM function. Values for the reception_status parameter

can be found in 4.3.2.

57.2.8.2.3 When generated

This primitive is generated whenever the Parser function intends to pass a received OAMPDU to the Control

function, internal to the OAM sublayer. Frames are reported only if they are validly formed and received

without error.

57.2.8.2.4 Effect of receipt

The receipt of this primitive will cause the Control function to update internal state variables and pass the

OAMPDU to the OAM client via the OAMPDU.indication service primitive (see 57.2.5.2).

57.2.9 Modes

DTEs incorporating the OAM sublayer support Active and/or Passive mode. When OAM is enabled, a DTE

capable of both Active and Passive modes shall select either Active or Passive. Table 57–1 contains the

behaviour of Active and Passive mode DTEs.

Table 57–1—Active and passive mode behaviour

Capability Active DTE Passive DTE

Initiates OAM Discovery process Yes No

Reacts to OAM Discovery process initiation Yes Yes

Required to send Information OAMPDUs Yes Yes

Permitted to send Event Notification OAMPDUs Yes Yes

Permitted to send Variable Request OAMPDUs Yes No

Permitted to send Variable Response OAMPDUs Yes

Requires the peer DTE to be in Active mode.

Yes

Permitted to send Loopback Control OAMPDUs Yes No

Reacts to Loopback Control OAMPDUs Yes

Yes

Permitted to send Organization Specific OAMPDUs Yes Yes

IEEE

CSMA/CD Std 802.3-2005

57.2.9.1 Active mode

DTEs configured in Active mode initiate the exchange of Information OAMPDUs as defined by the

Discovery state diagram (see Figure 57–5). Once the Discovery process completes, Active DTEs are

permitted to send any OAMPDU while connected to a remote OAM peer entity in Active mode. Active

DTEs operate in a limited respect if the remote OAM entity is operating in Passive mode (see Table 57–1).

Active devices should not respond to OAM remote loopback commands and variable requests from a

Passive peer.

57.2.9.2 Passive mode

DTEs configured in Passive mode do not initiate the Discovery process. Passive DTEs react to the initiation

of the Discovery process by the remote DTE. This eliminates the possibility of passive to passive links.

Passive DTEs shall not send Variable Request or Loopback Control OAMPDUs.

57.2.10 OAM events

OAM defines a set of events that may impact link operation. OAM contains mechanisms to communicate

such events to the remote DTE. The following sections provide an overview of these events and

mechanisms.

57.2.10.1 Critical link events

Table 57–2 lists the defined critical link events. Critical link events are carried within the Flags field of each

OAMPDU. Refer to 57.4.2.1 for the definition and encoding of the Flags field.

57.2.10.2 Link events

Link events are signaled via Link Event TLVs that are defined in 57.5.3. Examples of link events include

Errored Symbol Period Event and Errored Frame Event.

57.2.10.3 Local event procedure

Local events are communicated to the remote DTE via one of two mechanisms described below:

a) Critical link events, defined in 57.2.10.1, are communicated to the OAM sublayer via the

OAM_CTL.request service primitive. The OAM sublayer shall respond to critical link events by

setting or clearing the appropriate bits within the Flags field on any subsequently generated

OAMPDUs of any type.

b) The OAM client sends an Event Notification OAMPDU (see 57.4.3.2) containing a Link Event TLV

(see Table 57–12) for every event not yet signaled to the remote DTE. The OAM client uses the

OAMPDU.request service primitive to send Event Notification OAMPDUs. The OAM client may

send duplicate Event Notification OAMPDUs to increase the probability of reception at the remote

DTE on deteriorating links.

Table 57–2—Critical link event

Critical link event Description

Link fault

The PHY has determined a fault has occurred in the receive direction of

the local DTE.

Dying gasp An unrecoverable local failure condition has occurred.

Critical event An unspecified critical event has occurred.

NOTE—The definition of the specific faults comprising the Critical Event, Dying Gasp, and Link Fault flags is

implementation specific and beyond the scope of this standard.

IEEE

Std 802.3-2005 REVISION OF IEEE Std 802.3:

57.2.10.4 Remote event procedure

Remote events are detected by the local OAM client via one of two mechanisms described below:

a) Critical link events, defined in 57.2.10.1, shall be detected by the local OAM sublayer via the Flags

field of any received OAMPDU. The OAM sublayer signals the Flags field to the OAM client using

the OAMPDU.indication service primitive. When receiving Information OAMPDUs indicating

Link Fault from the remote DTE, it is recommended that the local OAM client set the

local_link_status parameter in the OAM_CTL.request service primitive to OK. This avoids the

situation where both ends of a link are in a deadlock condition where neither DTE will be capable of

receiving frames.

b) All other link events shall be detected by the local OAM sublayer via the reception of an Event

Notification OAMPDU and the subsequent passing of the OAMPDU to the OAM client via the

OAMPDU.indication service primitive. The OAM client discards any duplicate received Event

Notification OAMPDU.

57.2.11 OAM remote loopback

OAM provides an optional data link layer frame-level loopback mode, which is controlled remotely. OAM

remote loopback can be used for fault localization and link performance testing. Statistics from both the

local and remote DTE can be queried and compared at any time while the remote DTE is in OAM remote

loopback mode. These queries can take place before, during or after loopback frames have been sent to the

remote DTE. In addition, an implementation may analyze loopback frames within the OAM sublayer to

determine additional information about the health of the link (i.e. determine which frames are being dropped

due to link errors). Figure 57–4 shows the path of frames traversing the layer stack of both the local and

remote DTEs.

57.2.11.1 Initiating OAM remote loopback

To initiate OAM remote loopback, the local OAM client sets its local_mux_action parameter to DISCARD

and the local_par_action parameter to DISCARD via the OAM_CTL.request service primitive. The local

OAM client sends a Loopback Control OAMPDU (see 57.4.3.5) with the Enable OAM Remote Loopback

command. After receiving the Loopback Control OAMPDU, the remote OAM client first sets its

local_par_action parameter to LB and its local_mux_action parameter to DISCARD via the

OAM_CTL.request service primitive, and then sends an Information OAMPDU with updated state

Figure 57–4—OAM remote loopback

MAC CONTROL (Optional)

MAC

OAM

PMA

PMD

PCS

MDI

MII

Medium

MAC client

Local

DTE

MAC CONTROL (Optional)

MAC

PMA

PMD

PCS

MDI

MII

Remote

DTE

OAM client MAC client OAM client

OAM

IEEE

CSMA/CD Std 802.3-2005

information reflecting its local_par_action set to LB and its local_mux_action parameter set to DISCARD.

On the reception of an Information OAMPDU from the remote OAM client with updated state information,

the local OAM client sets the local_mux_action to FWD.

If an OAM client has sent a Loopback Control OAMPDU and is waiting for the peer DTE to respond with

an Information OAMPDU that indicates it is in OAM remote loopback mode, and that OAM client receives

an OAM remote loopback command from the peer device, the following procedures are recommended:

a) If the local DTE has a higher source_address than the peer, it should enter OAM remote loopback

mode at the command of its peer.

b) If the local DTE has a lower source_address than the peer, it should ignore the OAM remote

loopback command from its peer and continue as if it were never received.

If OAM clients do not follow these guidelines, it may be possible for two OAM clients to issue simultaneous

OAM remote loopback commands with indeterminate results.

57.2.11.2 During OAM remote loopback

This section elaborates on Figure 57–4 and describes the flow of frames within the local and remote DTEs

and across the link during OAM remote loopback mode. While in OAM remote loopback mode:

a) The local DTE transmits frames from the MAC client and OAMPDUs from the local OAM client or

OAM sublayer.

b) Within the remote OAM sublayer entity, every non-OAMPDU, including other Slow Protocol

frames, is looped back without altering any field of the frame.

c) OAMPDUs received by the remote DTE are passed to the remote OAM client.

d) Both DTEs are required to send OAMPDUs to the peer DTE in order to keep the Discovery process

from re-starting. Both are also permitted to send other OAMPDUs to the peer DTE.

e) Frames received by the local DTE are parsed by the OAM sublayer. OAMPDUs are passed to the

OAM client and all other frames are discarded.

57.2.11.3 Exiting OAM remote loopback

When the local DTE wishes to end the OAM remote loopback test, the local OAM client sets its

local_mux_action parameter to DISCARD. The local OAM client then sends a Loopback Control

OAMPDU with the Disable OAM Remote Loopback command. After receiving a Loopback Control

OAMPDU with the Disable OAM Remote Loopback command, the remote OAM client first sets the

local_par_action and local_mux_action parameters to FWD via the OAM_CTL.request service primitive

and then sends an Information OAMPDU with updated state information reflecting the local_par_action and

local_mux_action parameters set to FWD. After receiving an Information OAMPDU with local_par_action

and local_mux_action set to FWD, the local OAM client sets its local_par_action and local_mux_action

parameters to FWD via the OAM_CTL.request service primitive. The remote Parser resumes passing

received non-OAMPDUs up to the MAC client and the local Multiplexer resumes forwarding any frames

sourced by the local MAC client.

57.2.11.4 Loss of OAMPDUs during OAM remote loopback

There is the possibility of OAMPDU loss before, during and after OAM remote loopback tests. Of particular

interest to the operation of OAM remote loopback is the loss of Loopback Control OAMPDUs and

Information OAMPDUs. The local OAM client is able to determine whether or not the remote OAM client

received Loopback Control OAMPDUs by examining all received Information OAMPDUs. Since

Information OAMPDUs are continually sent to keep the OAM Discovery process from re-starting, the

occasional loss of an Information OAMPDU should not adversely impact the operation of OAM remote

loopback mode.

IEEE

Std 802.3-2005 REVISION OF IEEE Std 802.3:

57.2.11.5 Loss of frames during OAM remote loopback

While the link is operating in OAM remote loopback mode, MAC client frames originating from the remote

DTE are not transmitted by the remote OAM sublayer entity. Depending upon the remote DTE’s

implementation of OAM remote loopback, not every frame received is guaranteed to be looped back to the

local DTE. Clock differences between the local and remote DTEs may also be a source of lost frames, as the

delta in the rate of frames transmitted and received may overrun buffers within either DTE. As always,

frames that incur errors during transit will be dropped by the MAC sublayer receiving the frame. Also,

OAMPDUs inserted by the remote DTE impacts the bandwidth available to loopback frames.

Implementations should take into account the topology (e.g., emulated point-to-point, asymmetrical links)

when determining the rate at which to send frames during OAM remote loopback. When a bidirectional link

has asymmetric data rates, frame loss may occur if the receive bandwidth is less than the transmit

bandwidth.

Loopback frames that are discarded by the OAM sublayer within the remote DTE are counted and, if

Clause 30 is present, are reflected in 30.3.6.1.46. This helps determine the health of the link by

distinguishing between frames discarded due to link errors and those discarded within the OAM sublayer.

57.2.11.6 Timing considerations for OAM remote loopback

For effective OAM remote loopback operation, it is necessary to place an upper bound on the response time

of the remote OAM client after receiving Loopback Control OAMPDUs.

To ensure correct operation, the OAM client needs to, within one second of receiving a Loopback Control

OAMPDU with the Enable OAM Remote Loopback command:

a) Set its local_par_action parameter to LB and the local_mux_action to DISCARD via the

OAM_CTL.request service primitive.

b) Send an Information OAMPDU.

To ensure correct operation, the OAM client needs to, within one second of receiving a Loopback Control

OAMPDU with the Disable OAM Remote Loopback command:

c) Set its local_par_action and local_mux_action parameters to FWD via the OAM_CTL.request

service primitive.

d) Send an Information OAMPDU.

It is possible for the remote MAC client to send frames before the remote OAM client can send the

Information OAMPDU instructing the local DTE to change its local_par_action variable. As a result these

remote MAC client frames will be discarded by the local DTE.

57.2.12 Unidirectional OAM operation

OAM provides an OAMPDU-based mechanism to notify the remote DTE when one direction of a link is

non-operational and therefore data transmission is disabled. The ability to operate a link in a unidirectional

mode for diagnostic purposes supports the maintenance objective of failure detection and notification.

Some physical layer devices support Unidirectional OAM operation (see 22.2.4.1.12, 22.2.4.2.8, and

Clause 66). When a link is operating in Unidirectional OAM mode, the OAM sublayer ensures that only

Information OAMPDUs with the Link Fault critical link event indication set and no Information TLVs are

sent once per second across the link.

57.3 Detailed functions and state diagrams

As depicted in Figure 57–3, the OAM sublayer comprises the following functions:

剩余416页未读，继续阅读

snow2535

粉丝: 25
资源: 2

IEEE 803.3-2005 第 5 章：以太网 subscriber access 网络标准

IEEE802.3-2005标准

IEEE802.3-2005.pdf

IEEE802.3-2005 section1~section5

IEEE Std 802.3-2018_IEEE802.3-2018_IEEE802.3_802.3_802.3-2018_IE

IEEE802.3-2005.rar

IEEE 802.3-2005.rar

ieee 802.3-2005 version

IEEE Std 802.3™-2008(Revision of IEEE Std 802.3-2005)Section 5

IEEE 802.3-2015-section4-6.zip

IEEE Std 802.3™-2008(Revision of IEEE Std 802.3-2005)Section 3

最新资源