An Alcatel-Lucent 1665 DMX network accepts Ethernet frames at an ingress port and transmits them out of one or more egress ports. The egress port(s) can be on the same network element or on a different network element. If it is on a different network element, Ethernet frames are transmitted over a SONET network. To transport an Ethernet frame across the SONET network, the Ethernet Frame is moved between a LAN port and the SONET network.
The following occurs to transport an Ethernet frame over a SONET network
Alcatel-Lucent 1665 DMX accepts an Ethernet Frame at an ingress LAN Port.
The Ethernet frame is accepted at an Ethernet switch's LAN port for switched services, processed, and then transmitted out one or more of its LAN and/or VCG (WAN) port(s). For Private Line circuit packs that support only non-switched services, the Ethernet frame is sent directly to the GFP mapper via a VCG port.
The generic framing procedure (GFP) mapper encapsulates the Ethernet frame into a GFP Frame.
The Virtual Concatenator maps the Ethernet stream into one or more SONET tributaries (time slots). This allows the network to carry traffic (Ethernet stream) at higher speeds than allowed by a single SONET tributaries (time slot). The group of virtually concatenated tributaries is referred to as a Virtual Concatenation Group (VCG).
The VCG is then placed on SONET tributaries and transmitted over the SONET network.
Generic Framing Procedure (GFP) is used to encapsulate Ethernet frames for transport over a SONET network. Alcatel-Lucent 1665 DMX uses frame-based GFP with the core header and no optional extension headers. The GFP Frame Check Sequence (FCS) is provisionable (on/off) on LNW63, LNW64, LNW87, LNW705 ports (ed-eport).
To encapsulate an Ethernet frame, the Ethernet preamble and Start of Frame Delimiter (SFD) fields are removed from the frame. A Type header and check (tHEC) is added to the Ethernet frame creating a GFP payload. The GFP payload is then scrambled and a Core header is added. The GFP frame is then sent to the Virtual Concatenator. The following figure shows the format of a GFP frame.
Section |
Field |
Description |
---|---|---|
Core Header |
Payload Indicator (PLI) |
Binary number representing the number of octets in the GFP payload. |
Core Header Error Control (cHEC) |
CRC-16 checksum that protects the integrity of the contents of the Core Header. | |
Payload Header |
Type |
The type of information contained in the Payload field. The value is 01hex. |
Type Header Error Control (tHEC) |
CRC-16 checksum that protects the integrity of the contents of the Type Field. | |
Payload |
The raw Ethernet Frame (that is, the original Ethernet Frame without the Preamble and SFD. |
In the opposite direction when the GFP Mapper receives a GFP frame from the Virtual Concatenator, it removes the Core Header and, using the cHEC field, performs a Header Error Check. If the header is correct, the payload area of the GFP is then unscrambled and the Type field and tHEC in the GFP header are checked for correctness. The Ethernet frame is extracted and the Preamble and SFD are added.
The GFP mapper at the far end of the network inserts idle GFP frames when there are no Ethernet frames to send. The near end GFP Mapper discards any idle GFP frames it receives over the SONET network. The idle GFP frames are not forwarded to the Ethernet Switch. (Private line packs do not contain an Ethernet switch.)
The GFP Mapper contains GFP queues that are used to store Ethernet frames while they are being processed.
The Generic Framing Procedure is defined in ITU-T G.7041/Y.1303 and ANSI T1X1.105 Sections 7.3.2 and 7.3.3.
Virtual Concatenation is a standard inverse multiplex scheme for transporting a payload using multiple channels each of which has a lower capacity than the payload to be transported. It allows finer granularity in allocating the transport bandwidth than is available in standard contiguous concatenation (STS-3c, STS-12c, STS-48c, STS-192c etc.). For example, an STS-1 tributary has a usable bandwidth of approximately 48.4 Mb/s. This is too slow for a 1 Gbits/s Ethernet stream. An STS-48c tributary has approximately 2.4 Gb/s which would waste 1.4 Gb/s of bandwidth if used to carry a 1 Gb/s Ethernet stream.
Using virtual concatenation, 21 STS-1 tributaries can be used providing an effective rate of approximately 1.02 Gb/s. Fewer STS-1 tributaries can be virtually concatenated to provide sub-rate (fractional rate) service.
The grouped SONET tributaries form a Virtual Concatenation Group (VCG). A VCG is treated as a single logical serial byte stream whose payload capacity equals that of the sum of the payload capacities of the constituent SONET tributaries. The following figure shows a virtual concatenation group.
Individual tributaries in the VCG are independently transported through the SONET network. Only the initial and final SONET nodes perform the Virtual Concatenation. Since the VCGs are invisible to the intermediate SONET nodes, the intermediate nodes only need to transport normal SONET traffic and do not need to understand VCGs. This allows the tributaries to be transported through equipment which does not handle VCGs.
Because the individual tributaries of a virtual concatenation group (VCAT) can take different paths through the SONET network, they may experience different delays through the network.
The table below provides the differential delay buffers for each of the Ethernet circuit packs.
Circuit Pack Name |
Delay (in milliseconds) |
---|---|
LNW63/64 |
100 ms |
LNW66 |
16 ms |
LNW73/73C |
120 ms |
LNW74 |
64 ms |
LNW87 |
100 ms |
LNW170 |
50 ms |
LNW705 1 |
32 ms |
See WDMX, tributary interface circuit packs for additional details about the LNW705.
Ethernet circuit packs contain LAN ports and VCG ports. The LAN ports connect to external Ethernet equipment. The VCG ports connect to the OLIUs via Generic Framing (GFP) Mappers and Virtual Concatenation Groups (VCGs).
The OLIUs contain the hardware that perform the SONET cross-connections and process traffic at the SONET tributary level. They do not know about the embedded Ethernet frames or Virtual Concatenation Groups.
Connections to the SONET network can be configured to provide SONET layer protection. Alcatel-Lucent 1665 DMX supports three types of SONET protection: Unidirectional Path Switched Rings (UPSRs), Bidirectional Line Switched Rings (BLSRs), and 1+1.
Alcatel-Lucent 1665 DMX supports transport of Ethernet frames on the following:
On protected tributaries, both rings carry the same traffic placed in the same tributaries (time slots), but in opposite directions in the case of UPSR. UPSR protected cross-connections are provisioned as one 1wayPR cross-connections and two 1way cross-connections. BLSR protected cross-connections are provisioned using 1way cross-connections only.
On LNW66 circuit packs, only the odd numbered VCG ports can be used for SONET protected cross-connections because some of the hardware associated with the even numbered VCG ports is used to protect the odd number ports.
On the LNW63, LNW64, LNW74, LNW87, and LNW170 circuit packs, all VCG ports can be used. For the LNW63, LNW64, LNW74, LNW87, and LNW170, circuit packs, all ports are supported regardless of STS mode. The picture above depicts the LNW170 in Private Line mode. The LNW170 can also function in switched mode. For figures depicting the LNW170 in switched mode, see Figure A-12, Multi-point cross-connections (unprotected) and/or Figure A-14, LNW170 Gigabit multipoint cross-connections (unprotected).
In the case of UPSR unprotected tributaries, the two sides of the ring carry different traffic. Each VCG is connected to only one side of the ring.
1-way unswitched cross-connections provide unprotected SONET connections to Ethernet circuit packs on a UPSR. On BLSR w/NUT, only 1way cross-connections are used. Each can be used to form two individual connections. One VCG is connected to MAIN 1 while the other VCG is connected to Main 2.
The following figure shows examples of the multipoint cross-connections provisioned by way of 1-way and 1-way unswitched cross-connects.
On the LNW66 and LNW74 circuit packs, the odd number VCGs are paired with the next higher number VCG (VCG 1 is paired with VCG 2, and VCG 3 is paired with VCG 4.) For example, VCG 2 must be connected to one OLIU when VCG 1 is provisioned to be connected to the other OLIU. Both cross-connections use the same SONET tributaries. The following figure shows an example of the VCG port pairing.
Multipoint cross-connections can either be used as two unprotected point-to-point connections or as part of a packet ring. If they are used as part of a packet ring, the Ethernet switch will process traffic received on one side of the packet ring before it is forwarded out the other side of the ring.
On the LNW63, LNW64, LNW74, LNW87, and LNW170, any VCG can be connected to any OLIU. Additionally, the pairing of VCG ports for multipoint applications is not fixed. As the figure below demonstrates, V1 and V2 are paired in the shelf on the left while V1 and V3 are paired in the shelf on the right.
A multipoint cross-connection is made up of multiple 1-way or 1-way unprotected cross-connections.
STS-1 Mode |
STS-3c Mode | ||
---|---|---|---|
Port |
Paired with Port... |
Port |
Paired with Port... |
1 |
13 |
1 |
9 |
2 |
14 |
2 |
10 |
3 |
15 |
3 |
11 |
4 |
16 |
4 |
12 |
5 |
17 |
5 |
13 |
6 |
18 |
6 |
14 |
7 |
19 |
7 |
15 |
8 |
20 |
8 |
16 |
9 |
21 |
9 |
1 |
10 |
22 |
10 |
2 |
11 |
23 |
11 |
3 |
12 |
24 |
12 |
4 |
13 |
1 |
13 |
5 |
14 |
2 |
14 |
6 |
15 |
3 |
15 |
7 |
16 |
4 |
16 |
8 |
17 |
5 |
||
18 |
6 |
||
19 |
7 |
||
20 |
8 |
||
21 |
9 |
||
22 |
10 |
||
23 |
11 |
||
24 |
12 |
Ethernet-to-Ethernet hairpin cross-connections are used to connect a circuit pack to another circuit pack within the same Alcatel-Lucent 1665 DMX. The cross-connection goes through either Main 1 or Main 2, but not over the SONET ring.
Hairpin cross-connections with an Ethernet circuit pack are used to either connect a VCG on that circuit pack with a VCG on another circuit pack or to connect a VCG with an OLIU located in a function or growth slot. Hairpin connections between VCG ports are used to combine Ethernet traffic from different cards before it is transmitted over a packet ring or out of a LAN port. The following figure shows examples of 1-way hairpin cross-connections between two Ethernet circuit packs.
The table below details the support of 1way cross-connections between Ethernet packs. For hairpins between packs on the same shelf, only 1way cross-connections are used.
From |
To |
---|---|
LNW63 |
LNW63, LNW64, LNW66, LNW74, LNW87, LNW170 |
LNW64 |
LNW63, LNW64, LNW66, LNW74, LNW87, LNW170 |
LNW66 |
LNW63, LNW64, LNW66, LNW87, LNW170 |
LNW73/73C |
LNW73/73C |
LNW74 |
LNW63, LNW64, LNW74, LNW87, LNW170 |
LNW87 |
LNW63, LNW64, LNW66, LNW74, LNW87, LNW170 |
LNW170 |
LNW63, LNW64, LNW66, LNW74, LNW87, LNW170 |
The Ethernet Switch, also referred to as a Media Access Control (802.1D MAC) bridge, processes the Ethernet frames and handles Virtual LANs, frame priority, frame forwarding, and switching functions. The ports on the customer's side of the switch are referred to as LAN ports, and the ports on the SONET side are referred to as VCG or WAN Ports.
Circuit pack |
Number of ports |
Maximum capacity of a VCG port | ||
---|---|---|---|---|
Name |
LAN port line rate |
LAN (Boundary) |
VCG (Interior) | |
LNW63 |
1 Gbps |
4 |
4 |
1 Gbps |
LNW64 |
1 Gbps |
8 |
8 |
1 Gbps |
LNW66 |
10/100 Mbps |
24 |
2 |
1 Gbps |
LNW74 |
10/100 Mbps |
24 |
24 |
100 Mbps |
LNW87 |
1 Gbps |
4 |
4 |
1 Gbps |
LNW170 1 |
1 Gbps and 100 Mbps |
8 |
8 (Private line mode) 32 (Switched mode) |
2.5 Gbps |
QoS provisioning on EoS VCGs in transparent mode allows LNW170 VCGs i transparent mode to be provisioned as either interior or boundary.
A virtual LAN (VLAN) is a logical grouping of LAN ports, possibly spread across multiple Alcatel-Lucent 1665 DMX nodes, that act as if they comprise a single LAN. Since a physical LAN can be associated with multiple virtual LANs, VLANs can be used to segregate traffic across a network. VLANs can be used to segregate different types of traffic for a single customer or to separate traffic belonging to multiple subscribers.
VLANs operate at the Ethernet (MAC) Layer. This allows different VLANs to be carried on the same physical media and hides the VLANs from higher-level protocols (for example, TCP and IP). The higher-level protocols treat each VLAN as if it was a separate physical LAN. VLAN-aware Ethernet Switches will forward VLAN traffic only on ports assigned to that VLAN. A port can be part of several VLANs and a VLAN can be assigned to several ports.
A frame's VLAN can be assigned either by the subscriber's equipment or by network equipment. User equipment specifies the VLAN by including a VLAN Tag in the frame. Alcatel-Lucent 1665 DMX determines a frame's VLAN either from the frame's existing VLAN Tag or by the default VLAN ID assigned to the frame's ingress port. Alcatel-Lucent 1665 DMX can be provisioned to drop frames that do not contain a tag.
VLAN Tags are located in the Ethernet Header. The following figure shows the format of Ethernet frames without a VLAN Tag, frames with a VLAN Tag, and the format of the VLAN Tag.
VLAN Tags can be generated by either user equipment or a switch. If a switch adds a VLAN Tag to a frame, it must also recalculate the frame's Checksum (FCS). Alcatel-Lucent 1665 DMX supports provisioning of 4093 VLAN IDs within the range of 1–4093. Additional information about VLAN tags can be found in IEEE 802.1Q.
In order to allow carriers to administer VLAN IDs independent of their subscribers, Alcatel-Lucent 1665 DMX can be provisioned to add a second VLAN Tag to Ethernet Frames. This tag, referred to as a Port Tag or Stacked VLAN Tag, can be used by the service provider to identify and segregate customer (subscriber) traffic. The following figure shows the format of an Ethernet frame that contains stacked VLAN tags.
The port tag is formatted according to IEEE 802.1Q except:
Alcatel-Lucent 1665 DMX is capable of handling frames with multiple layers of VLAN tags; ultimately the limit is that frames greater than the MTU size are rejected as too large. When processing VLAN tags, Alcatel-Lucent 1665 DMX only looks at the outermost tag (that is, the one that most closely follows the Source Address) that it recognizes. Recognition of a tag is based on the TPID value. In 802.1Q mode, the expected TPID value is 8100hex. In transparent mode, the expected TPID value is provisioned by the user, with the default value being FFFFhex. Legal provisioned values for TPID are between 0601hex and FFFFhex. These TPID values are also used to identify any tags inserted by Alcatel-Lucent 1665 DMX.
Based on provisioning at the network ingress and egress points, it is possible for an Ethernet frame to enter and leave the network with a different number of VLAN tags.
Each Ethernet frame is assigned a priority level. The priority level can be based on a field in a VLAN Tag or a default priority assigned to the frame's ingress port. If an ingress port is provisioned with a default priority, the default priority will take precedence over the priority field in the VLAN tag.
A VLAN Tag contains a three-bit user_priority field. This allows higher priority frames to be processed at a faster rate than lower priority frames. For the LNW66 packs, Alcatel-Lucent 1665 DMX maps the three-bit user priority field to two priority levels. These circuit packs contain two priority queues. Ethernet frames are processed using an 8:1 weighted round robin queue service algorithm. The LNW170 packs contains 4 priority queues. For more information about the LNW170, see QoS services (LNW170).
For tagged frames, the following table shows the mapping between values in the user priority field and the priority queues for all of the Ethernet packs except the LNW170. An Ethernet port can be provisioned to drop untagged frames, or add a VLAN tag containing the port’s default user priority field value of 0 (low) or 7 (high).
VLAN Tag User Priority Field Value |
Queues |
---|---|
0 |
Low |
1 |
Low |
2 |
Low |
3 |
Low |
4 |
High |
5 |
High |
6 |
High |
7 |
High |
For tagged frames, the following table shows the default mapping between values in the user priority field and the priority queues for the LNW170 when the pack is in no traffic management mode (NOTC).
VLAN Tag User Priority Field Value |
Queues(1=lowest --> 4=highest) |
---|---|
0 |
(2) |
1 |
(1) |
2 |
(1) |
3 |
(2) |
4 |
(3) |
5 |
(3) |
6 |
(4) |
7 |
(4) |
For more information about frame priority rules, see 802.1Q VLAN mode and QoS services (LNW170).
This section pertains to the LNW66 and LNW170.
An Ethernet bridge moves a frame from an ingress port to an egress port(s). It will not forward a frame if the frame contains errors or has the same source and destination addresses.
The bridge looks up the destination MAC address/VLAN ID combination in the address table. If the MAC address is found, the bridge sends the frame to the port(s) found in the address table. If the MAC address is not found, the bridge sends the frame to all ports associated with the VLAN ID (except the originating port).
All multicast and broadcast frames are broadcast, including spanning tree BPDUs.
The size of the address table is 8K entries for the LNW66. The size of the address table is 256K for the LNW170 packs. Each combination of MAC Address/VLAN ID is one entry. Entries are removed if they are not used within 300–600 seconds (5–10) minutes. During a topology change, they are deleted as soon as the change is detected.
The single physical Ethernet switch on an LNW66/170 Ethernet circuit pack can be logically divided into multiple virtual switches. A virtual switch, identified by an id number between 1 and 4095 (between 1 and 16 on LNW170), consists of a collection of LAN and VCG ports.
Any VLANs and spanning tree groups associated with the ports also become associated with the virtual switch. Each LAN port, VCG port, VLAN ID and spanning tree group id can only be associated with one virtual switch per Ethernet circuit pack. On the LNW66 each VLAN ID can only be associated with one virtual switch. On the LNW170, the same VLAN ID can be associated with many virtual switches and each virtual switch has its own VLAN ID. A minimum of one virtual switch must be created on the LNW66/170 Ethernet circuit pack in order to provision VLANs and spanning tree groups when in 802.1Q or Transparent Tagging mode. When a port is removed from a virtual switch it returns to its default parameters. Virtual switches are not used in Private Line mode or on LNW74 circuit packs.
The following figure shows one possible assignment of LAN ports and VCG ports into virtual switches. The figure shows one physical switch that is divided into two virtual switches. Virtual switch 1 supports a packet ring configuration encompassing LAN port 1 and VCG ports 1 and 2. Virtual Switch 2 supports a point-to-point configuration encompassing LAN port 2 and VCG ports 1 and 2. Ethernet traffic will not be allowed to cross between the virtual switches.
Spanning tree protocol (STP) provides a protection scheme for Ethernet packet transmission as a by-product of its primary function of eliminating loops in Ethernet networks. This protection is independent of any SONET-level protection mechanisms such as UPSR switching. In fact, undesirable interactions can occur if both protection mechanisms are used, so it is recommended that spanning tree protocol be used only in configurations with no SONET protection.
Loops can arise within Ethernet networks as a result of multiple paths between a source and a destination. The spanning tree protocol identifies links that must be blocked to ensure that no such multiple paths can exist. Any link failure in the resulting network triggers the spanning tree protocol to analyze the network and identify a new set of blocked links that provide full connectivity with no duplicated paths. It is this reconfiguration in response to failures that constitutes the packet layer protection mechanism.
Spanning tree works as follows:
Initially, every node in the group thinks it is the root node.
Configuration BPDUs are sent from each node to determine the most economical route from each node to the root node.
As information about the network becomes clear, one node is designated the root node; from this node, the distance to any point in the network may be measured.
Once the network has become clear, some ports are blocked so that there are no loops in the network and so that the network provides the most efficient paths from the root to the nodes. This effectively creates a tree structure for the network.
If an active link fails, the network is reconfigured so that previously blocked links can be used for traffic.
Important!
The configuration provides the least (most efficient) path from each node to the root. The configuration also provides only one path between any two nodes.
If one of the active links is broken, the network reconfigures to activate the inactive link. For example, if the link between 2 and 3 is broken, the link between 5 and 7 would be enabled.
The 802.1W rapid spanning tree protocol (RSTP) improves upon the 802.1D version of spanning tree protocol. The key improvements are:
Faster Failure Detection - Alcatel-Lucent 1665 DMX uses SONET-layer failure detection to trigger packet-layer (spanning tree) reconfiguration, so packet-layer reconfiguration starts within a few milliseconds after a failure rather than several seconds later.
IEEE 802.1W Rapid Reconfiguration - Alcatel-Lucent 1665 DMX supports standard packet-layer restoration protocol, which uses messages between spanning tree protocol entities to significantly reduce convergence time.
Spanning tree version interworking - Each Alcatel-Lucent 1665 DMX node will query its Ethernet link partners to determine if they are capable of running the 802.1W rapid spanning tree protocol. If so, the 802.1W protocol will be used. If not, Alcatel-Lucent 1665 DMX will fall back to running the 802.1D version of spanning tree protocol.
Enhanced STP configuration reports and controls - Together with 802.1W, these enable support for much larger networks than are supported with IEEE 802.1D Spanning Tree Protocol.
Alcatel-Lucent 1665 DMX supports spanning tree on the LAN (customer facing) ports. STP on LAN ports ensures that single LAN interconnects are protected. Because redundant LAN interconnects create loops, STP manages the loops. STP is supported on the LAN ports of the LNW170 only.
Both LAN ports and VCGs can belong to STP groups. A LAN port can belong to only one STP group at a time. The BDPU VLAN ID is provisionable on a per-port basis.
LAN based STP works exactly as described in the section above. The figure below depicts STP functioning on the customer side of an Alcatel-Lucent 1665 DMX with LNW170 circuit packs. The nodes marked A and B represent remote Ethernet switches or similar CPEs.
Alcatel-Lucent 1665 DMX supports link aggregation on any two LNW170 LAN ports of the same rate (i.e. 100 or 1000 Mbps), operating in switched mode. The LNW170 supports LAGs that span LNW170 packs.
Link aggregation can also be used for facility protection on LNW170 LAN ports. The LNW170 also provides support for equipment protection of function group pairs, using a mate interface.
Ordinarily, multiple Ethernet links between two bridges form loops (unless a spanning tree blocks all but one) so they can't be used to increase bandwidth. Link Aggregation causes defined groups of links to be treated as a single logical link, making multiple LAN ports appear as one. In this way, Bandwidth may be increased without requiring an upgrade to a higher rate link.
Link aggregation can also remove failed links automatically, thereby providing a means of facility protection. When a link fails, traffic is shifted to the remaining links in that Link Aggregation Group (LAG). More links than are needed can be added to the group and each is active until it fails (similar to utilizing LCAS protection for SONET tributaries). When two links are on different packs they can provide both, facility and equipment protection.
In Active/Standby LAG, one link of the LAG is designated as the protection link and the other is the working link. Only the working link carries MAC client traffic when none of the links fails. When the working link fails, the traffic switches to the protection link. The protection switching is bidirectional and revertive.
The LNW170 circuit pack can be provisioned for equipment protection, in which link aggregation plays a role. The LNW170 supports equipment protection of function group pairs (e.g. A1, A2) using an interpack interface. Only ports 1, 2, 5 and 6 are usable. Ports 3, 4, 7 and 8 cannot be used. Signals of all usable ports are fed to both LNW170 packs via the interpack interface, so that the same-numbered port of each pack belongs to a preset Link Aggregation Group. When a pair of LNW170s is used in equipment protection mode, both LNW170s are provisioned identically, except for certain physical layer parameters that remain independent. They send and receive the same signals across the backplane toward the Mains. The Mains select which of the pair is the ActiveWAN.
Equipment protection is supported on the LNW170 in shelves equipped with VLF or non-VLF main packs. In shelves with non-VLF main packs, the companion LNW170 in the slot-pair is alarmed when the protection state of the pack is not provisioned as protected (prot_state = PROT).
Link Aggregation is specified in IEEE 802.3 clause 43, formerly specified in 802.3ad. The LNW170 can be configured to either use this standard protocol to control link aggregation (which negotiates with the equipment at the other end of the link) or to simply force aggregation without a control protocol. Both ends should be provisioned to use the same protocol
Link aggregation, available for LAN ports on LNW170 packs, behaves along the following basic guidelines:
Maximum of 4 LAGs per pack, 2 ports per LAG, and 8 LAGs per function unit or growth group. There are 8 ports on each LNW170 pack.
All links in a LAG are in-service until they fail. Standby links, providing 1x1 SONET-style protection, are a future feature.
When a LAG is created, the attributes (VLAN, virtual switch, and other L2 provisioning) of the first port used to establish the LAG are transferred to the LAG. When the second port is added, it then inherits the L2, VLAN and Virtual Switch (VS) characteristics of the LAG for the time it remains a member. It can not be part of a VS or have any VLAN provisioning when added.
Both member ports can also be added simultaneously and Alcatel-Lucent 1665 DMX recognizes a parameter that distinguishes the "Lead Port". The LAG (and by association, the other port in the LAG) inherits the L2, VLAN, and VS attributes of the Lead Port.
When a port is removed from a particular LAG, it is no longer a member of a VS.
A port must have L2 and VS provisioning in order for a port to be used as the Lead port or to establish a LAG (VLAN provisioning not required). This information is then transferred to the LAG once it's created.
The last port/member of a LAG cannot be removed from the LAG; the LAG itself must be deleted. The last port/member of a the inherits the LAG's L2, VLAN, and VS attributes.
If the last member in the LAG was the first member added originally, and if there were no subsequent changes to L2 and VLAN attributes, the port will effectively revert to its original state when the LAG is deleted.
If the last member/port in the LAG was not the first added initially it will inherit the characteristics of the LAG rather than reverting to its original state.
The figure below depicts link aggregation on two LNW170 LAN ports functioning at 100Mbps. The top portion of the figure shows two ports receiving separate 100 Mbps inbound flows. The bottom portion depicts the same two flows being equally split across the two outbound ports in the LAG. In this example, no failure has occurred and both ports comprising the LAG are in-service.
Traffic entering incoming ports is aggregated into a LAG. While both ports are in-service, outgoing traffic is split between working ports.
The instance pictured above represents the ideal case, in which there are at least 2 flows, each a maximum of 100Mbps. In this case they can be equally split over the two ports comprising the LAG. The ability to split the two flows across multiple ports also depends on the distribution of MAC/IP addresses.
Link aggregation employs an algorithm that assigns traffic to member ports to prevent misreading. A given flow can be assigned to only one port and cannot be split across multiple ports in the same LAG. To increase flexibility, Alcatel-Lucent 1665 DMX allows a flow to be defined by either a MAC source and destination address pair or an IP source and address pair. The algorithm uses the XOR of the least significant bits of the address pairs to assign a port/link. Therefore, the actual load balancing achieved depends on the distribution of MAC/IP addresses.
Link aggregation allows multiple physical links between Ethernet switches to be treated as a single link. This provides for more bandwidth between the switches than can be transmitted over a single Ethernet port and it can provide protection from a cable, Ethernet port, or Ethernet circuit pack failure.
The Alcatel-Lucent 1665 DMX supports link aggregation transparency, as shown in the following figure. This allows the attached equipment to use link aggregation without participation by the Alcatel-Lucent 1665 DMX provisioning.
The figure shows two Ethernet devices running link aggregation interconnected via Ethernet circuit packs and a SONET Network. The Alcatel-Lucent 1665 DMX shelves and the SONET network are invisible to the two Ethernet devices. The Ethernet traffic is transparently transferred between the external devices. Link aggregation is typically implemented using two dedicated unprotected point-to-point links (Ethernet Private Line Service) for each pair of external ports.
Link aggregation transparency requires a default VLAN ID tag or port tag in 802.1Q and Transparent Tagging mode. If a default VLAN or port tag is not specified at the port, the link aggregation messages are dropped.
This section describes how Alcatel-Lucent 1665 DMX controls the flow of Ethernet traffic. Alcatel-Lucent 1665 DMX supports the following types of flow control:
Prior to Release 9.1, the software sets the buffer size and flow control thresholds based on the MTU and flow control provisioning (enable or disable/drop.) Beginning in Release 9.1, the automatic buffer size provisioning is decoupled from the MTU and flow control provisioning on the LNW63, LNW74 and LNW70/170 (private line applications only). Using the existing queue size parameters (qsz), in the ED-EPORT and ED-VCG commands, the user can optionally provision the buffer size independently of the mtu size (mtu_size) and flow control mode (fcmd).
Beginning in Release 9.1, ports on the LNW63 and LNW74 support the following values for total queue size. These values also apply to the LNW70/170 VCGs when in private line mode.
NA (default) Not Applicable. The ingress queue size is automatically set as a function of mtu_size and fcmd, consistent with releases prior to Release 9.1
128 The ingress queue size is 128 Kbytes. This value is supported for FE ports only.
512 The ingress queue size is 512 Kbytes. This value is supported for GE ports only.
If the external equipment delivers Ethernet frames to the Ethernet circuit pack faster than they can be delivered across the network, the data buffers in the Ethernet circuit pack fill up. When the data buffers reach the flow control threshold, the Ethernet circuit pack initiates flow control. On full duplex links, the Ethernet circuit pack issues a flow control request to the external equipment, requesting that the flow of frames be suspended. On half duplex links, the JAM signal is used to stop all traffic. The flow control request is repeated periodically, or the JAM signal continuously generated until the buffers empty sufficiently.
Note that this local flow control mechanism is concerned only with congestion (full packet buffers) at the local Alcatel-Lucent 1665 DMX. If the Alcatel-Lucent 1665 DMX at the other end of the SONET network is unable to deliver the Ethernet frames to the attached external equipment due to flow control conditions there, that does not directly affect the local flow control operation at the ingress Alcatel-Lucent 1665 DMX.
If the local Ethernet circuit pack attempts to deliver Ethernet frames to the attached external equipment faster than the external equipment can accept them, the external equipment may initiate flow control. On full duplex links, the external equipment issues a flow control request to the Ethernet circuit pack requesting that the flow of frames be suspended. On half duplex links, the JAM signal is used to stop all traffic.
This causes the Ethernet circuit pack to stop sending Ethernet frames to the external equipment for the time requested in the flow control request. During this time, Ethernet frames accumulate in the packet buffers in the Ethernet circuit pack. Once these buffers fill completely, further Ethernet frames arriving from the SONET network for the egress Ethernet port are dropped.
If the external equipment at the destination of an Ethernet connection cannot handle the rate of traffic being sent to it, it may be desirable to apply back pressure across the network to slow down the external source of the Ethernet traffic. This cross-network back pressure can only work well, however, when the source of the traffic can be identified unambiguously. Only the Ethernet Private Line Service offers this opportunity; thus, it is the only service that supports End-to-End Flow Control.
With end-to-end flow control, flow control requests that are received by the LNW66 Ethernet circuit packs at the egress point of the network, are regenerated during congested conditions by the Ethernet circuit pack at the ingress point of the network and transmitted to the originating external equipment.
While waiting for the originating external equipment to receive and process the flow control request, the destination Ethernet circuit pack buffers Ethernet frames received over the SONET network. If the buffer fills before the frame flow stops, the excess frames are discarded.
Important!
In the LNW66 if the ingress traffic sent to a VCG port is less than 1 Gbps, but greater than the SONET bandwidth available, packets are dropped without being counted.
The LNW63/170 circuit pack implements the following changes intended to improve the frame loss behavior of end-to-end flow control.
When provisioned for end-to-end flow control, the LNW63/170 circuit pack sends a flow control request across the SONET network immediately upon receiving a flow control request from external equipment.
The LNW63/170 circuit pack contains large latency buffers to hold data while waiting for far-end equipment to respond to end-to-end flow control requests.
After a flow control request is received, the LNW63/170 circuit pack buffers frames instead of sending them to the equipment that generated the flow control request. Each port has its own latency buffer. A latency buffer can store 16ms of traffic that allows the equipment to be about 1000 miles apart (2000 miles round trip).
The LNW64/74/87 circuit pack implements the following changes intended to improve the frame loss behavior of end-to-end flow control.
When provisioned for end-to-end flow control, the LNW64/74/87 circuit pack sends a flow control request across the SONET network immediately upon receiving a flow control request from external equipment.
The LNW64/74/87 circuit pack does not buffer data while waiting for far-end equipment to respond to end-to-end flow control requests. Data is transmitted to the client, as shown in the following figure.
A combination of flow control settings on the LNW66 circuit pack LAN ports and VCGs determine how flow control operates.
The following table shows the flow control settings for the LNW66 circuit packs.
LAN Port Flow Control State |
VCG Flow Control Provisioned Value |
Flow Control Status |
Use/Comments |
---|---|---|---|
Disabled |
Don't Care |
Disabled |
Flow control is disabled for that port/link. Flow control requests are ignored and discarded. |
Enabled |
Transparent |
End-to-End Mode Enabled |
The LAN port responds to flow control requests by stopping frame transmission. Flow control requests are generated and sent to far end Alcatel-Lucent 1665 DMX based on congestion. Frames are dropped once the egress buffer is full. LAN port generates flow control requests due to congestion from the far end Alcatel-Lucent 1665 DMX. For Ethernet Private Line Full Rate Service (Point-to-Point). |
Local |
Local Mode Enabled |
The LAN port responds to flow control requests by stopping frame transmission. No flow control requests are sent to far end Alcatel-Lucent 1665 DMX. LAN port generates flow control requests for fractional service. For Ethernet Private Line Fractional (Partial) Rate Service and Packet Ring Services. | |
None (Disabled) |
Disabled |
The LAN port responds to flow control requests by stopping frame transmission. No flow control requests are sent to the far end Alcatel-Lucent 1665 DMX. LAN port does not generate flow control requests. |
The LNW63/64/74/87/170 circuit pack automatically provides both local and end-to-end flow control if flow control is enabled for a LAN port. Similarly, disabling flow control for an LAN port disables both forms of flow control.
The following table shows the flow control settings for the LNW63/64/74/87/170 circuit pack.
LAN Port Flow Control State |
Flow Control Status |
Use/Comments |
---|---|---|
Disabled |
Disabled |
Alcatel-Lucent 1665 DMX does not participate in flow control. The LAN port does not respond to flow control requests. The LAN port does not generate flow control requests due to congestion. Flow control requests are transported when received. |
Enabled |
Enabled |
The LAN port generates flow control requests for fractional service. For LNW170/63 the LAN port responds to flow control requests by stopping frame transmission. Flow control requests are sent to the far end Alcatel-Lucent 1665 DMX. Frames are stored in the Latency buffer for loss-less transmission. For LNW74/64 flow control requests are sent to the far-end Alcatel-Lucent 1665 DMX. |
Drop |
Drop |
Disables Network-element controlled flow control and drops end-to-end flow control messages. |
Each Ethernet circuit pack contains a transceiver that implements the physical interface for that circuit pack's line type. For the 10/100 Mbps circuit packs, this physical interface must be provisioned to or auto-negotiate to the proper line rate and duplex mode in order to communicate successfully with the connected equipment. Gigabit Ethernet interfaces only support the 1000 Mbps line rate and full duplex mode, so this is not an issue for these circuit packs. All optical 100BASE-X interfaces support the 100 Mbps line rate only.
At the physical layer, many types of LANs can be used for multiple line rates and duplex modes. For example the LAN port on most PCs can be connected to a 10BASE-T (10 Mbps) or a 100BASE-T (100 Mbps) LAN. Before data traffic can be transmitted onto a LAN, all ports connected to the LAN must operate with the same line rate and duplex mode. LAN ports can either be provisioned with these values or provisioned to automatically negotiate (auto-negotiate) the values.
In the auto-negotiation process, a LAN port advertises its acceptable parameters, compares these with the advertised parameters of its link partner, and then agrees upon a set of parameters with the link partner. IEEE 802.3 allows the line rate, duplex mode, and flow control mode to be auto-negotiated. A LAN port not configured to support auto-negotiation will use provisioned values for these parameters. A LAN port configured for auto-negotiation that is connected to a LAN port not configured for auto-negotiation will follow prescribed rules for parameter settings.
On connected Gigabit Ethernet ports with auto-negotiation enabled, if transmission is interrupted in one direction of transmission on a Gigabit Ethernet port, then transmission is disabled in the other direction. For example, if one fiber in the transmit/receive pair is cut, then one-way transmission on the other fiber is maintained only if auto-negotiate is disabled and the link state is forced good at the transmit source equipment.
The following table summarizes line rate operation for the LNW66 and LNW74 Ethernet circuit packs.
LAN Port Rate Provisioning |
Connected Equipment Provisioning |
Ethernet Link Rate (Note 1) | |
---|---|---|---|
Auto-Negotiation |
Advertised/Set at | ||
10 |
Disabled |
10 |
10 |
Disabled |
100 |
No Link | |
Enabled |
10 |
10 | |
Enabled |
100 |
No Link | |
Enabled |
10/100 |
10 | |
100 |
Disabled |
10 |
No Link |
Disabled |
100 |
100 | |
Enabled |
10 |
No Link | |
Enabled |
100 |
100 | |
Enabled |
10/100 |
100 | |
Auto |
Disabled |
10 |
10 |
Disabled |
100 |
100 | |
Enabled |
10 |
10 | |
Enabled |
100 |
100 | |
Enabled |
10/100 |
100 |
Both the Alcatel-Lucent 1665 DMX and the connected equipment will try to determine a common line rate. The link will not come up if both ends have auto-negotiation enabled and advertise incompatible duplex modes.
The following table summarizes duplex mode operation for the LNW66 Ethernet circuit packs.
LAN Port Provisioning |
Connected Equipment Provisioning |
Duplex Mode State |
Bidirectional Traffic (Link Rate must be resolved) | |||
---|---|---|---|---|---|---|
Duplex Mode |
Auto-Negotiation State 1 |
Auto-Negotiation |
Advertised/Set at |
DMX 2 |
Connected Equipment | |
Auto |
Enabled |
Disabled |
Full |
Half |
Full |
No |
Disabled |
Half |
Half |
Half |
Yes | ||
Enabled |
Full |
Full |
Full |
Yes | ||
Enabled |
Half |
Half |
Half |
Yes | ||
Enabled |
Half/Full |
Full |
Full |
Yes | ||
Full |
Enabled |
Disabled |
Full |
Unavailable |
Full |
No |
Disabled |
Half |
Unavailable |
Half |
No | ||
Enabled |
Full |
Full |
Full |
Yes | ||
Enabled |
Half |
Full |
No | |||
Enabled |
Half/Full |
Full |
Full |
Yes | ||
Disabled |
Disabled |
Full |
Full |
Full |
Yes | |
Disabled |
Half |
Full |
Half |
No | ||
Enabled |
Full |
Unavailable |
No 4 | |||
Enabled |
Half |
Full |
Half |
No | ||
Enabled |
Half/Full |
Full |
Half |
No | ||
Half |
Enabled |
Disabled |
Full |
Half |
Full |
No |
Disabled |
Half |
Half |
Half |
Yes | ||
Enabled |
Full |
Unavailable |
No | |||
Enabled |
Half |
Half |
Half |
Yes | ||
Enabled |
Half/Full |
Half |
Half |
Yes | ||
Half |
Disabled |
Disabled |
Full |
Half |
Full |
No |
Disabled |
Half |
Half |
Half |
Yes | ||
Enabled |
Full |
Half |
No 4 | |||
Enabled |
Half |
Half |
Half |
Yes | ||
Enabled |
Half/Full |
Half |
Half |
Yes |
Auto-negotiation is enabled if Line Rate or Duplex Mode or Flow Control is provisioned for auto-negotiation.
Duplex mode is reported as unavailable if the link could not be established.
The link will not come up because the duplex mode could not be established.
According to IEEE 802.3, the connected equipment should default to half duplex. Because that equipment doesn't support half duplex the link may be prevented from coming up. If it does come up, bidirectional traffic will not be supported.
The following table summarizes flow control operation for the LNW66 and LNW74 Ethernet circuit packs.
LAN Port Provisioning |
Connected Equipment Provisioning |
Duplex Mode State |
Comments 4 | |||
---|---|---|---|---|---|---|
Flow Control |
Auto-Negotiation State 1 |
Auto-Negotiation |
Advertised/ Set at 2 |
DMX 3 |
Connected Equipment | |
Auto |
Enabled |
Disabled |
Disabled |
Enabled |
Disabled |
Inconsistent Provisioning |
Enabled |
Enabled |
Enabled |
Inconsistent Provisioning | |||
Enabled |
Disabled |
Disabled |
||||
Enabled |
Enabled |
|||||
Enabled |
Enabled |
Disabled |
Disabled |
Enabled |
Disabled |
Inconsistent Provisioning |
Enabled |
Enabled |
Enabled |
Inconsistent Provisioning | |||
Enabled |
Disabled |
Enabled |
Disabled |
|||
Enabled |
Enabled |
Enabled |
||||
Disabled |
Disabled |
Disabled |
Enabled |
Disabled |
Inconsistent Provisioning | |
Enabled |
Enabled |
Enabled |
||||
Enabled |
Disabled |
Enabled |
Unknown |
Inconsistent Provisioning | ||
Enabled |
Enabled |
Unknown |
Inconsistent Provisioning | |||
Disabled |
Enabled |
Disabled |
Disabled |
Disabled |
Disabled |
Inconsistent Provisioning |
Enabled |
Disabled |
Enabled |
Inconsistent Provisioning | |||
Enabled |
Disabled |
Disabled |
Disabled |
|||
Enabled |
Disabled |
Disabled |
||||
Disabled |
Disabled |
Disabled |
Disabled |
Disabled |
||
Enabled |
Disabled |
Enabled |
Inconsistent Provisioning | |||
Enabled |
Disabled |
Disabled |
Unknown |
Inconsistent Provisioning | ||
Enabled |
Disabled |
Unknown |
Inconsistent Provisioning |
Auto-negotiation is enabled on the LNW66 LAN port if Line Rate or Duplex Mode or Flow Control is provisioned for auto-negotiation.
Flow control will only be enabled if the connected equipment is capable of Symmetric Flow Control.
IEEE 802.3 does not define flow control states for half duplex links or when only one side of a link is provisioned for auto-negotiation. This is the expected behavior of the connected equipment.
IEEE 802.3 recommends that equipment be configured for auto-negotiation to avoid inconsistent provisioning.
On LNW66 LAN ports, flow control is enabled if the duplex mode is provisioned for half duplex and disabled if the duplex mode is provisioned for full duplex or auto-negotiate.
On LNW66 LAN ports, flow control is enabled if the duplex mode is provisioned for full duplex, or auto-negotiates to full duplex, or is provisioned for half duplex. It is disabled on LNW66 LAN ports if the duplex mode auto-negotiates to half duplex.
Important!
Flow control on all optical Fast Ethernet ports must be provisioned manually.
The following table summarizes 100BASE-X flow control operation for the LNW170 Ethernet circuit packs.
LAN Port Flow Control Provisioning |
Connected Equipment Provisioning |
Flow Control State |
Comments 3 | ||
---|---|---|---|---|---|
Auto-Negotiation |
Advertised/ Set at 2 |
DMX 2 |
Connected Equipment | ||
Auto |
Disabled |
Disabled |
Enabled |
Disabled |
Inconsistent Provisioning |
Enabled |
Enabled |
Enabled |
Inconsistent Provisioning | ||
Enabled |
Disabled |
Disabled |
Disabled |
||
Enabled |
Enabled |
Enabled |
|||
Enabled |
Disabled |
Disabled |
Enabled |
Disabled |
Inconsistent Provisioning |
Enabled |
Enabled |
Enabled |
|||
Enabled |
Disabled |
Enabled |
Unknown |
Inconsistent Provisioning | |
Enabled |
Enabled |
Unknown |
Inconsistent Provisioning | ||
Disabled (Drop on LNW170 only) |
Disabled |
Disabled |
Disabled |
Disabled |
|
Enabled |
Disabled |
Enabled |
Inconsistent Provisioning | ||
Enabled |
Disabled |
Disabled |
Unknown |
Inconsistent Provisioning | |
Enabled |
Disabled |
Unknown |
Inconsistent Provisioning |
The link will not be operational if the connected equipment is not configured for 1 Gbps and full duplex mode.
Flow control will only be enabled if the connected equipment is capable of Symmetric Flow Control.
IEEE 802.3 recommends that equipment be configured to avoid inconsistent provisioning.
Ethernet circuit packs contain small buffer pools that provide storage of Ethernet frames for brief periods of congestion or until flow control requests can be honored. These small buffer pools are associated with the Ethernet switch and the Generic Framing Procedure (GFP) mechanism. The GFP mechanism is described further in Generic framing procedure (GFP). A larger buffer pool designed to handle different path lengths for individual STS-1s is associated with the virtual concatenation process. Its function is described in more detail in Virtual concatenation. Two priority-based queues are provided on the LNW66 to allow high priority traffic to be forwarded ahead of low priority traffic. The LNW170 provides 4 priority queues. For more information, see Metering (CIR and PIR).
The Ethernet switches on LNW66 circuit packs contain ingress (input) and egress (output) buffers. The following figure shows the LNW66 circuit pack queue and buffer architecture.
High and low priority queues are provided for packets leaving the Ethernet switch in the direction of either the SONET network or a customer port. Each LAN and VCG port has one ingress and two egress queues. Ingress queues buffer Ethernet frames going into the Ethernet switch and egress queues buffer Ethernet frames leaving the Ethernet switch. One egress queue is for high priority Ethernet frames and the other egress queue is for low priority Ethernet frames.
On the LNW66 circuit pack, the LAN ports are divided into groups of eight. The groups consist of LAN ports 1–8, 9–16, and 17–24. Each group of eight LAN ports shares a set of 128 frame buffers. In the egress direction, each LAN port can buffer up to 31 Ethernet frames which can be placed in a high or low priority queue. Each LNW66 circuit pack VCG port can buffer 40 Ethernet frames in the ingress queue and a total of 37 Ethernet frames across the high and low priority egress queues.
All frame buffers are sized to handle the maximum frame size (1536 bytes). The buffer pool sizes described above are independent of frame size (that is, they do not increase if the Ethernet traffic consists of small frames).
In Private Line Mode, the Ethernet frame buffers are all associated with the Generic Framing Procedure (GFP) and virtual concatenation mechanisms. The following figure shows the LNW63/64/74/170 circuit pack buffer architecture.
Note:
In switched mode, the LNW170 buffers are provisionable up to 256 K. Each port buffer accommodates four CoS queues
The LNW63/64/74/170 circuit pack provides larger buffer pools to allow for longer response times to flow control requests. In addition, buffer storage can be flexibly assigned to Ethernet frames, allowing maximal usage of the memory available.
Note:
For additional information on differential delay buffers, see Differential delay buffers.
As an Ethernet frame arrives from the SONET network destined for a customer LAN port on LNW66 circuit packs, it is placed in the egress queue associated with the destination LAN port(s). If that queue is full, the VCG port on which the packet arrived could hold the packet until space is available, but that would stop the incoming flow of all packets arriving on that VCG port, even those destined for uncongested LAN ports. This situation is known as Head-of-Line (HOL) blocking.
To avoid Head-of-Line (HOL) blocking, the LNW66 circuit packs support the discarding of packets received on a VCG port destined for a LAN port with a full egress queue. Broadcast frames, multicast frames, and frames with unknown destination addresses are not discarded but are forwarded only to those LAN ports that are accepting traffic. Frames dropped due to HOL blocking prevention are not reported as dropped in the performance monitoring statistics.
HOL blocking prevention is used in the 802.1Q and transparent modes. These modes are described in Tagging Modes.
November 2011 | Copyright © 2011 Alcatel-Lucent. All rights reserved. |