96x1H-IPI.5.1.100: Ethernet line interface and secondary Ethernet interface operation
Approved
The Ethernet line interface
Approved
will operate as a DTE (an MDI without crossover function, see Clause 14.5 of IEEE 802.3 [7.2-1]) and
Approved
will be set to the appropriate operational mode as follows, based on the parameter PHY1STAT:
“1” will set the Ethernet line interface to auto-negotiate the speed and duplex,
“2” will set 10Mbps half-duplex operation, “3” will set 10Mbps full-duplex operation,
“4” will set 100Mbps half-duplex operation, “5” will set 100Mbps full-duplex operation, and
“6” will set 1000Mbps full-duplex operation if supported by the hardware, otherwise it will set the Ethernet line interface to auto-negotiate the speed and duplex (the value of PHY1STAT will not be changed).
Approved
Automatic MDI/MDI-X Configuration (Auto-MDIX, see Clause 40.4.4 of IEEE 802.3 [7.2-1]) will be enabled on the Ethernet line interface.
Approved
Telephones that have a secondary Ethernet interface will deactivate the secondary Ethernet interface if PHY2STAT is set to “0” (see 96x1H-IPI.2.1.1100 and 96x1LA.6.2.1000 in [7.1-5]).
Telephones that have a secondary Ethernet interface will activate the secondary Ethernet interface
Approved
as a DCE (an MDI with crossover function, see Clause 14.5 of IEEE 802.3 [7.2-1])
Approved
in the appropriate mode if the parameter PHY2STAT is greater than “0”, as follows:
“1” will set the secondary Ethernet interface to auto-negotiate the speed and duplex,
“2” will set 10Mbps half-duplex operation, “3” will set 10Mbps full-duplex operation,
“4” will set 100Mbps half-duplex operation, “5” will set 100Mbps full-duplex operation, and
“6” will set 1000Mbps full-duplex operation if supported by the hardware, otherwise it will set the secondary Ethernet interface to auto-negotiate the speed and duplex (the value of PHY2STAT will not be changed).
Approved
Telephones that have a secondary Ethernet interface will enable Auto-MDIX on the secondary Ethernet interface
Approved
for R6.3+
if and only if the value of PHY2_AUTOMDIX_ENABLED is “1”.
Note:
If Auto-MDIX is disabled on PHY2 while a link is active to a device on which Auto-MDIX is also disabled, PHY2 will be configured to operate as a DCE (MDI-X) only, and the link will be dropped if
the interface on the other device is also configured as a DCE (MDI-X) and they are connected by a “straight-through” cord, or
the interface on the other device is configured as a DTE (MDI) and they are connected by a “cross-over” cord.
If Auto-MDIX is enabled on PHY2 while no link is active due to an incompatible combination of interface configuration and cord type to a device on which Auto-MDIX is disabled, a link will be established if the speed and duplex configurations are also compatible.
Note:
Two types of cords are used with twisted-pair Ethernet – a “straight-through” cord is normally used to connect an endpoint (DTE) to a network switch (DCE), and a “cross-over” cord is normally used to connect two DTEs (such as two PCs) or two DCEs (such as two network switches). Auto-MDIX allows a PHY to work with either type of interface using either type of cord.
Note:
Auto-Negotiation is specified in Clause 28 and Annex 28B of IEEE 802.3.
Note:
Both ends of an Ethernet connection should be configured to operate the same way – either both should be configured to operate at the same fixed speed and duplex, or both should be configured to auto-negotiate. Connecting devices that are not configured the same way usually causes problems; see http://www.cites.illinois.edu/network/advanced/autosense.html However, for Gigabit Ethernet, even using a fixed speed and duplex can cause problems, so auto-negotiation is preferred; see http://etherealmind.com/ethernet-autonegotiation-works-why-how-standard-should-be-set/ or http://www.homelabnetwork.com/learning/do-not-force-gigabit-ethernet-auto-negotiation-to-1000full/
Note:
The following diagram illustrates the distinction between the telephone, the internal Ethernet switch, the Ethernet line interface and the secondary Ethernet interface:
96x1H-IPI.5.1.200: MAC frame format and Link Layer Control (LLC)
Approved
Ethernet frame format will be supported, as specified in Ethernet Data Link Layer and Physical Layer Specifications [7.2-0b]. Transmission of IP datagrams (see 96x1H-IPI.5.1.304) and ARP requests and replies (see 96x1H-IPI.5.1.700) will also be as specified in IETF STD 41 (RFC 894) [7.3-17] and as clarified by IETF STD 3 (RFC 1122) Section 2.3.3 [7.3-3a].
The MAC frame structure will be supported as specified in IEEE Std 802.3, clause 3 [7.2-1].
Only received frames that contain the telephone’s MAC address,
the broadcast address (FF-FF-FF-FF-FF-FF, see Section 3.2.3.1 of [7.2-1]), or
the PAUSE multicast address (01-80-C2-00-00-01, see Annex 31B of [7.2-1] or Table 7-9 of [7.2-4])
as the destination address will be processed by the telephone.
Only broadcast frames containing an ARP REQUEST will be processed (per 96x1H-IPI.5.1.700);
all other received broadcast frames will be discarded.
Multicast group addresses will only be supported as explicitly specified.
Media access control will be as specified in clause 4 of [7.2-1].
During full-duplex operation, flow control will be supported for transmit and receive via PAUSE frames as specified in clause 31 and Annex 31B of [7.2-1]. During half-duplex operation, flow control will be supported via transmission of frame preambles.
All telephones that have an internal Ethernet switch will operate as specified in ISO/IEC 15802-3 (IEEE 802.1D) [7.2-4], clause 7 (except that a Bridge Protocol Entity, the Spanning Tree Protocol and the Generic Attribute Registration Protocol (GARP) will not be supported), IEEE 802.1H [7.2-5], and IEEE 802.1t-2001 [7.2-4a].
Note:
Compliance with IEEE 802.1D and 802.1H also provides compliance with UCR 2008 Change 3 [7.8-1d] Section 5.3.5.4.6 requirement 12.5: “If the product supports a subtended appliance behind it, the product shall ensure that the IP address assignment process of the subtended appliance is transparent to the UC components of the product and does not cause the product to attempt to change its IP address.
NOTE: An example is a PC that is connected to the LAN through the hub or switch interface on a phone. The address assignment process of the PC should be transparent to the EI and should not cause the phone to attempt to change its IP address.”
Approved
All frames generated by the telephone will be forwarded to the high-priority transmit (egress) queue of the Ethernet line interface and/or the secondary Ethernet interface, as appropriate. All frames received on the Ethernet line interface will be forwarded to the high-priority transmit queue of the telephone and/or the secondary Ethernet interface, as appropriate. All frames received on the secondary Ethernet interface will be forwarded to the low-priority transmit queue of the telephone and/or the Ethernet line interface port, as appropriate. Frames in the high-priority egress queue will always be transmitted before frames in the low-priority queue.
All telephones that have an internal Ethernet switch will forward all frames received on the Ethernet line interface or on the secondary Ethernet interface with the Bridge group multicast address (01-80-C2-00-00-00, see Section 7.12.6 of [7.2-4]) as the destination address to the other Ethernet interface. The telephone will ignore these frames.
Approved
for R6.2.2+
All telephones that have an internal Ethernet switch will support a port mirroring mode that is disabled by default, but when it is enabled, all frames that are forwarded from the Ethernet line interface to the telephone, and all frames that are forwarded from the telephone to the Ethernet line interface, will also be forwarded to the secondary Ethernet interface. If port mirroring is enabled, it will remain enabled through a reset, but if the telephone loses power, port mirroring will be disabled.
Note:
Port mirroring can be enabled and disabled from the Debug procedure on the craft menu, as specified by 96x1LA.6.2.800 in [7.1-5].
Note:
Layer 2 MAC frames have the following format (after the 8-octet preamble/start frame delimiter is removed):
Destination MAC Address
(6 octets)
Source
MAC Address
(6 octets)
Length/ Type
(2 octets)
Data/LLC
(46-1500 octets)
Frame Check Sequence
(4 octets)
A MAC address whose first bit (the least significant bit, since Ethernet is “little endian”) is set to ‘1’ is a Group Address (see Section 3.2.3 of [7.2-1]), which includes the Broadcast (all 1’s) Address and Multicast-Group Addresses. Reserved Multicast-Group Addresses include the following:
Bridge Group Address (Bridge Protocol Data Units: BPDUs)
IEEE Std. 802.1D clause 7.12.3
01-80-C2-00-00-01
MAC Control (Full Duplex PAUSE operation)
IEEE Std. 802.3 Annex 31B
01-80-C2-00-00-03
EAPOL (Extensible Authentication Protocol Over LAN: 802.1X)
IEEE Std. 802.1X clause 7.8
01-80-C2-00-00-0E
LLDP (Link Layer Discovery Protocol)
IEEE Std. 802.1AB clause 8.1
Rationale:
Although frames addressed to reserved multicast-group addresses are not supposed to be forwarded by an 802.1D-compliant MAC Bridge (see Section 7.12.6 of [7.2-4]), the standard assumes that the Ethernet switch has a Bridge Protocol Entity that processes such frames. However, if Bridge Protocol Data Units (BPDUs) are not forwarded by the internal Ethernet switch, the Spanning Tree Protocol used by the network switches will not be able to detect a loop if the phone’s secondary Ethernet interface is connected to another network port, which can cause broadcast storms. Since the telephone’s internal Ethernet switch does not have a Bridge Protocol Entity, it seems consistent to forward such frames.
Note:
If the value of the length/type field is less than 1536 decimal (06-00 hex), it is a length field of an IEEE 802 frame (see IEEE Std 802.3 [7.2-1], Sections 3.2.6 and 4.2.7.1, and ISO/IEC 8802-2:1988 [7.2-2]), which are not supported.
If the value of the length/type field is greater than or equal to 1536 decimal (06-00 hex), it is an Ethernet-format frame, in which case the value of the field is interpreted as an Ethernet protocol type (“EtherType”) identifier (see below), not a length.
Ethernet Protocol Types (EtherTypes)
Protocol
Reference(s)
decimal
hex
2048
08-00
IPv4
RFC 1700 p.168, RFC 1042 p.5, RFC 894 p.1
2054
08-06
ARP
RFC 1700 p.168, RFC 1042 p.5
33,024
81-00
IEEE 802.1Q
IEEE Std. 802.1Q clause 9.3.1
34,525
86-DD
IPv6
RFC 2464 section 3
34,824
88-08
MAC Control (PAUSE)
IEEE Std. 802.3 clause 31.4.1.3
34,958
88-8E
IEEE 802.1X (EAPOL)
IEEE Std. 802.1X clause 7.8
35,020
88-CC
IEEE 802.1AB (LLDP)
IEEE Std. 802.1AB clause 8.3
There is no EtherType for BPDUs because they are always sent using IEEE 802.2 Type 1 procedures (with a DSAP and an SSAP of 42 hex), so the Length/Type field contains the length of the frame.
Note:
IETF STD 3 (RFC 1122: Requirements for Internet Hosts -- Communication Layers) section 2.3.3 states: “Every Internet host connected to a 10Mbps Ethernet cable: MUST be able to send and receive packets using RFC-894 encapsulation;” (Ethernet frame format) “SHOULD be able to receive RFC-1042 packets,” (IEEE 802.3 frame format) “intermixed with RFC-894 packets; and MAY be able to send packets using RFC-1042 encapsulation. An Internet host that implements sending both the RFC-894 and the RFC-1042 encapsulations MUST provide a configuration switch to select which is sent, and this switch MUST default to RFC-894.”
Note:
Since Ethernet was originally designed for operation on shared media, it is possible that an endpoint will receive frames addressed to other endpoints. However, all “well-behaved” endpoints (except diagnostic tools that monitor network traffic) are expected to operate in “non-promiscuous mode”, in which all received frames with a unicast destination address different from the device’s own MAC address, and all multicast frames that the endpoint does not support, are ignored.
Rationale:
The Ethernet frame format was chosen because it is the de facto standard in use by LAN devices and because it is more efficient than the frame format specified by ISO/IEC 8802-2 and IEEE802.2, which wastes 8 octets on the SNAP SAP.
Transmission of frame preambles to flow control an interface during half-duplex operation (back pressure) is not part of the 802.3 standard, but it is very commonly implemented and is effective.
Conformance with IEEE Std 802.1w [7.2-4b] (MAC Bridge Rapid Reconfiguration) is not required because the Spanning Tree Protocol is not supported.
Frames generated by the telephone are always given high priority in telephones with an internal Ethernet switch because the default for 802.1Q tagging (see 96x1H-IPI.5.1.220) is off, and this ensures that frames generated by the telephone are always given priority on the line interface over any frames generated by a device on the secondary Ethernet interface.
