Ethernet Muxponders

Ethernet Muxponders/II

Technical Description10xGbE/10GbE Ethernet MuxPonder-II (GBE10-EMXP10/II R1)22xGbE/10GbE Ethernet MuxPonder-II (GBE22-EMXP10/II R1)4x10GbE Ethernet MuxPonder-II (EMXP40G/II R1)8x10GbE Ethernet MuxPonder-II (EMXP80G/II R1)

TD-EMXPII

Rev F | 2012-04-10

Technical Description

TM-Series

The specifications and informationwithin this manual are subject to change without further notice. All statements,information and recommendations are believed to be accurate but are presented without warranty of any kind. Usersmust take full responsibility for their application of any products.

In no event shall Transmode Systems AB be liable for any indirect, special, consequential or incidental damages,including, without limitation, lost profits or loss or damage to data arising from the use or inability to use this manual,even if Transmode or its suppliers have been advised of the possibility of such damages.

© 2012 Transmode Systems AB. All rights reserved. No part of this document may be reproduced without the writtenpermission of the copyright holder.

TD-EMXPII Rev F | 2012-04-10 II

CONTENTS

TD-EMXPII Rev F | 2012-04-10 III

Contents1 Introduction.........................................................................................................................1

1.1 Document Revision History.........................................................................................11.2 Glossary and Definitions .............................................................................................1

2 Applications ........................................................................................................................52.1 Ethernet Aggregation .................................................................................................52.2 MEF Services ............................................................................................................5

2.2.1 MEF E-Line Service ..........................................................................................62.2.2 MEF E-LAN Service..........................................................................................62.2.3 MEF E-Tree Service..........................................................................................6

2.3 Ethernet rings ............................................................................................................72.4 Multicast....................................................................................................................8

2.4.1 IGMP Snooping................................................................................................82.5 MPLS Transport Profile.............................................................................................102.6 System Restrictions ................................................................................................. 11

2.6.1 Only CU-SFP ................................................................................................. 112.6.2 Traffic affecting reboot..................................................................................... 11

3 EMXP II Platform...............................................................................................................123.1 Functional EMXP/II cards .........................................................................................13

4 Ports ................................................................................................................................144.1 Analogue data .........................................................................................................14

4.1.1 Loop-back......................................................................................................154.1.2 ALS...............................................................................................................154.1.3 Alarms...........................................................................................................15

4.2 Transmission Performance .......................................................................................154.3 Interfaces ................................................................................................................17

4.3.1 Optics............................................................................................................174.3.2 Mirroring ........................................................................................................174.3.3 MTU Size.......................................................................................................174.3.4 Flow Control...................................................................................................18

4.4 Management VLAN..................................................................................................184.4.1 10G Boards....................................................................................................18

5 Switch Core ......................................................................................................................195.1 Main Switch Design..................................................................................................19

5.1.1 Performance ..................................................................................................205.1.2 Testing at 100% load.......................................................................................215.1.3 Bridging .........................................................................................................22

5.2 Policy Framework ....................................................................................................225.2.1 Classifications ................................................................................................225.2.2 Actions ..........................................................................................................24

5.3 Traffic Manager........................................................................................................255.3.1 Bandwidth profiles ..........................................................................................255.3.2 Ethernet Color Coding.....................................................................................275.3.3 Class of Service Scheduling ............................................................................285.3.4 Scheduling.....................................................................................................295.3.5 Shaping .........................................................................................................295.3.6 Active queue management ..............................................................................30

5.4 Ethernet OAM..........................................................................................................305.4.1 Maintenance Entity .........................................................................................305.4.2 Maintenance Endpoint ....................................................................................315.4.3 IEEE 802.1ag Continuity Check .......................................................................335.4.4 IEEE 802.1ag Loopback..................................................................................34

6 Synchronization Solution....................................................................................................356.1 Synchronization Design............................................................................................356.2 TM Synchronization solution .....................................................................................36

6.2.1 Synchronization Group....................................................................................366.2.2 Synchronization Domains................................................................................366.2.3 Synchronization Buses....................................................................................376.2.4 Synchronization Source Selection....................................................................37

CONTENTS

TD-EMXPII Rev F | 2012-04-10 IV

6.2.5 Synchronization Status Messaging...................................................................396.2.6 Network Synchronization.................................................................................40

6.3 Synchronization Performance Example......................................................................417 Functional Descriptions......................................................................................................44

7.1 UNI, Service Multiplexed UNI and NNI .......................................................................447.1.1 User-Network Interface (UNI)...........................................................................447.1.2 Service Multiplexed User-Network Interface (UniMux)........................................457.1.3 Network-Network Interface (NNI)......................................................................457.1.4 Native VLAN ..................................................................................................467.1.5 Service VLANs and Customer VLANs ..............................................................467.1.6 Service Transparency .....................................................................................46

7.2 Port Trust ................................................................................................................477.3 Link Aggregation......................................................................................................47

7.3.1 Load distribution .............................................................................................477.4 Ethernet Rings Protection Switching ..........................................................................48

7.4.1 OAM signal fail detection.................................................................................497.4.2 Multiple Rings.................................................................................................51

7.5 IP Version 4 Multicast ...............................................................................................517.5.1 IGMP control plane forwarding.........................................................................527.5.2 Multicast Forwarding Rules..............................................................................527.5.3 Special considerations for IP multicast forwarding .............................................527.5.4 Recommendations for high performancemulticast networks...............................53

7.6 MPLS-TP ................................................................................................................537.6.1 MPLS-TP and Ethernet Interworking ................................................................537.6.2 MPLS-TP Label Switched Path ........................................................................537.6.3 MPLS-TP Provider Edge and Provider Nodes ...................................................547.6.4 MPLS-TP Tunnels ..........................................................................................547.6.5 MPLS-TP Linear Protection .............................................................................557.6.6 MPLS-TP OAM ..............................................................................................567.6.7 Pseudowire (PW)............................................................................................577.6.8 MPLS label space...........................................................................................587.6.9 MPLS-TP Interface .........................................................................................587.6.10 MPLS-TP Service .........................................................................................60

7.7 Example MPLS-TP E-LINE service............................................................................607.7.1 Pseudowire NIPI-GAR-ACME..........................................................................607.7.2 MPLS-TP Tunnel NIPI-GAR-501–p3 ................................................................617.7.3 MPLS-TP LSP NIPI-MONT-3...........................................................................627.7.4 MPLS-TP transit LSP NIPI-GAR-MONT-3.........................................................637.7.5 MPLS-TP resources used for the Acme service.................................................647.7.6 Resilient MPLS-TP service ..............................................................................647.7.7 MPLS-TP OAM ..............................................................................................65

8 Mechanical Layout.............................................................................................................678.1 SFP Interfaces.........................................................................................................688.2 XFP Interfaces.........................................................................................................69

9 Technical Data ..................................................................................................................7010 References .....................................................................................................................71

INTRODUCTION

1 IntroductionThis manual provides an overview of the Ethernet Muxponder II family.The following trafficunits are described:

• 10xGbE/10GbE Ethernet Muxponder-II, GBE10-EMXP10/II

• 22xGbE/10GbE Ethernet Muxponder-II, GBE22-EMXP10/II

• 8x10GbE Ethernet Muxponder-II,EMXP80G/II

• 4x10GbE Ethernet Muxponder-II,EMXP40G/II

1.1 Document Revision History

Table 1 Document Revision History

Revision Date Descriptionof changes

A 2010-06-24 First released revision.

B 2010-10-04 Corrected STS LED description in chapter Clarifications on LAG restrictions. Edi-torial updates,

C 2010-12-15 Updated with R16 contents.

D 2011-06-21 Updated with R17 contents.

E 2011-12-19 Updated with R18 contents.

F 2012-03-30 Updated with R19 contents

1.2 Glossary and Definitions

Table 2 Glossary and Definitions

Acronym Interpretation Notes

AC Attachment Circuit

ALS Automatic Laser Shutdown

BA Behavior Aggregate Diff-Serve term

BFD Bidirectional Forwarding Detection MPLS

BWP Bandwidth Profile

CBS Committed Burst Size

CC Continuity Check

CCM Continuity Check messages

CFI Canonical Format Indicator

CFM Connectivity Fault Management

CIR Committed InformationRate

CM Color Mode

TD-EMXPII Rev F | 2012-04-10 1 (72)

INTRODUCTION

Table 2 Glossary and Definitions (cont’d.)


CoS Class of service

CRC Cyclic Redundancy Check

CU Control Unit TM term

CWDM Coarse wavelength division multiplexing

CV Continuity Verification

CVLAN Customer VLAN

DA Destination Address Assumes Ethernet

DCN Data communications Network

DEI Drop Eligibility Indicator

DNS Domain Name System

Dst Destination Assumes IPv4

DWDM Dense wavelength division multiplexing

EBS Excess Burst Size

ECN Explicit Congestion Notification

EEC Ethernet Equipment Clocks

EIR Excess InformationRate

E-LAN Ethernet LAN Service MEF Term

E-Line Ethernet Line Service MEF Term

EMXP Ethernet MuxPonder

ENM Embedded Node Manager TM-series node mgmt SW

EPL Ethernet Private Line MEF Term

ERP Ethernet Ring Protection a.k.a ERPS

ESMC Ethernet Synchronization Messaging Channel

EVC Ethernet Virtual Connection

EVPL Ethernet Virtual Private Line MEF Term

FPGA Field-Programmable Gate Array

G-Ach Generic Associated Channel MPLS-TP

GAL Generic Associated Channel Label MPLS-TP

GbE Gigabit Ethernet 1000Mb/s Ethernet

GUI Graphical User Interface

I2C Inter-Integrated Circuit "two-wire interface"

ICC ITU Carrier Codes

IQ Input queued

LACP Link Aggregataion Control Protocol

TD-EMXPII Rev F | 2012-04-10 2 (72)

INTRODUCTION



LAG Link Aggregation

LAN Local Area Network

LBM Loopback Messages

LED Light Emitting Diode

LER Label Edge Router Not necessarily a “router”

LOS Loss Of Signal

LSP Label Switched Path

LSR Label Switch Router Not necessarily a “router”

MAC Media Access Control

ME Maintenance Entity

MEF Metro Ethernet Forum

MEG Maintenance Entity Group

MEP Maintenance End Points

MIP Maintenance Intermediate Points

MP2MP Multipoint-to-Multipoint

MPLS Multiprotocol label switching

MPLS-TP MPLS Transport Profile

MTIE Maximum Time Interval Error Sync Term

NE Network Element

NNI Network Network Interface

OAM Operation and Maintenance

OQ Output queued

OUI Organizationally Unique Identifier

QoS Quality of Service

P2P Point-to-Point

PCP Priority Code Point 3-bit priority

PE Provider Edge MPLS

PM Performance Monitoring

PoP Point of Presence

PRC Primary Reference Clock

PSN Packed Switched Network

PW Pseudowire

RAN Radio Access Network

TD-EMXPII Rev F | 2012-04-10 3 (72)

INTRODUCTION



R-APS Ring Automatic Protection Switching ERPS signalling

RDI Remote Defect Indication

RHE Regional Headend

RPL Ring Protection Link ERPS Term

SA Source Address Assumes Ethernet

SDH Synchronous Digital Hierarchy

SF Signal Failure

SFP Small form-factor pluggable transceiver

SLA Service Level Agreement

SNMP Simple Network Management Protocol

SOAM Service OAM

SONET Synchronous Optical Network

Src Source Assumes IPv4

SSM Source Specific Multicast

STP Spanning Tree Protocol

SVLAN Service VLAN

TC Traffic Class EXP bits in MPLS

TE Traffic Engineering

TNM Transmode Network Manager Transmodes Network mgmtSW

TPID Tag Protocool Identifier Ethertype

TrTCM Two Rate Three Color Marker

TU Traffic Unit General term for active board

UNI User Network Interfaces

VID VLAN ID

VLAN Virtual LAN

VPN Virtual private network

VPWS Virtual PrivateWire Service MPLS

WRED Weighted Random early detection

WTR Wait to restore

XFP 10 Gigabit Small Form Factor Pluggable)

TD-EMXPII Rev F | 2012-04-10 4 (72)

APPLICATIONS

2 ApplicationsThis section list some of the applications where the Ethernet Muxponder Traffic Unit can beused.

2.1 Ethernet AggregationThe common application is Ethernet aggregation. In the case with mobile backhaul, severalsub rate GbE signals are presented to the EMXP hub. The access network often consists ofpassive TG filters connected over one fiber. Each cell site has one unique direct connectionwith the hub EMXP to provide an access network without jitter, congestion or delay.

Alternatively the access aggregation could be done using an EMXP10. Often are only 2 or 4GbE connections sued as uplinks. These 2 or 4 x GbE could be transported over one wave-length using iWDM.

Fig. 1 Aggregation in Mobile Backhaul Applications

The traffic is then aggregated onto a 10G uplink. The aggregation network then provides alter-nate paths through the network to two PE routers on the core network.

2.2 MEF ServicesEthernet Service Types can be used to create various Subscriber services. Common for theservices is that they provide a transparent transport between the UNIs.

A MEF Ethernet Service consists of an Ethernet Service Type (E-Line/E-LAN/E-Tree) and isassociated with one or more Bandwidth Profiles and supports one or more Classes of Service.A service also defines the transparency to L2 Control Protocols and how they should behandled.

In addition to this, the service should have the possibility to apply Service OAM (SOAM) andProtection.

More than one Ethernet Service is defined for each of the three Ethernet Service types. Theseare differentiated by the method for service identification used at the UNIs. Services usingport-based UNI are referred to as ‘Private’, while services using UNIs that are that are VLAN-

TD-EMXPII Rev F | 2012-04-10 5 (72)

APPLICATIONS

based, are referred to as ‘Virtual Private’. E.g. a E-Line service that’s port based is referred toas Ethernet Private Line (EPL).

2.2.1 MEF E-Line Service

E-Line service types require Point-to-Point (P2P) connectivity. In a Point-to-Point Ethernet Vir-tual Connection (EVC), exactly two User Network Interfaces (UNI) must be associated witheach other. An Ingress Service Frame to the EVC at one UNI can only result in an egress Serv-ice Frame at the associated UNI.

Fig. 2 Point-to-Point EVCs

2.2.2 MEF E-LAN Service

E-LAN service types require Multipoint-to-Multipoint (MP2MP) connectivity. In a MultipointEVC, two or more UNIs are associated with one another. An ingress Service Frame mapped tothe EVC at one of the UNIs can only result in an egress Service Frame at one or more of theassociated UNIs.

Fig. 3 Multipoint-to-Multipoint EVC

An E-LAN service is provisioned by a VLAN with MAC address learning turned on. That meansthat the Multipoint-to-Multipoint EVC will learn which end-stations that are behind each UNIand only send the traffic destined for those endstations to the correct UNI.

2.2.3 MEF E-Tree Service

E-Tree service types require Rooted-Multipoint connectivity. In a Rooted-Multipoint EVC, oneor more of the UNIs must be designated as a Root and each of the other UNIs must be desig-nated as a Leaf. A single root has connectivity to all the leaves. An ingress Service Framemapped to the EVC at a Root UNI may be delivered to one or more of the associated UNIs

TD-EMXPII Rev F | 2012-04-10 6 (72)

APPLICATIONS

(either Root or Leaf) in the EVC. An ingress Service Frame mapped to the EVC at a Leaf UNIcan only result in an egress Service Frame at one, some or all of the Root UNIs.

Fig. 4 Rooted-Multipoint EVC

An E-Tree service is provisioned by a VLAN with learning turned on and with trust between theleaf ports and the root ports (but not between the leaf ports). The trust relationship makes surethat traffic is only forwarded in the root-to-leaf and leaf-to-root direction, not between leafs.

2.3 Ethernet ringsA very common network configuration is ring networks. A service may be setup between twonodes in a ring, from any node to and any other node in the ring. Services are only defined bytheir endpoints, UNI’s in MEF terminology, where bandwidth profiles may be applied. TheEthernet ring itself may very well have QoS enabled, so if there is congestion somewhere onthe ring, it is the traffic with low priority that is discarded.

Fig. 5 Point-to-point services in an Ethernet ring

The services are protected using Ethernet Ring Protection so that any break in the ring con-nectivity causes re-routing in the ring.

Fig. 6 Point-to-point services in an Ethernet ring

It is also common to create multipoint-to-multipoint services in a ring configuration. E.g. a serv-ice between all nodes in a ring, where any node may communicate with any other node. Nor-mally this service has protection enabled so that traffic interruption is prevented in case of abreak or node failure.

TD-EMXPII Rev F | 2012-04-10 7 (72)

APPLICATIONS

Fig. 7 Multipoint-to-Multipoint Service in an Ethernet Ring

2.4 MulticastThe communication flow is normally between two hosts. It allows a host to send packets to an-other single host (unicast transmission). There is also the option of broadcasting information toall hosts (broadcast transmission). Multicast provides a third possibility: allowing a host to sendpackets to a subset of all hosts as a group transmission.

Fig. 8 Communication flows within a service

The EMXP/II family supports IPv4 multicast traffic forwarding through the IGMP-snooping func-tionality. Layer 2 multicast that is not recognized as IP multicast are broadcasted within theservice. This is for example valid for some IP and L2CP protocols. Specifically the reservedIPv4 multicast range 224.0.0.X is forwarded by default.

2.4.1 IGMP Snooping

IGMP snooping allows a layer 2 switch to listen in on the layer 3 IGMP conversation betweenhosts and multicast routers. By listening to these conversations the switch maintains a map ofwhich links need which IP multicast streams.

IGMP snooping is designed to prevent hosts on a local network from receiving traffic for a mul-ticast group they have not explicitly joined. A switch like EMXP/II will, by default without IGMPsnooping, flood multicast traffic to all the ports in a broadcast domain (or the VLAN equivalent).

TD-EMXPII Rev F | 2012-04-10 8 (72)

APPLICATIONS

Fig. 9 Broadcast of traffic to E-QAMs

Using multicast in this way can cause unnecessary load on links by transporting traffic withoutlisteners. IGMP snooping is not a defined standard, the implementation varies with vendor butsome advice is found in [RFC4541]

Activating IGMP snooping allows the EMXP/II to only forward multicast traffic to the links thathave solicited them.

Fig. 10 IGMP and multicast traffic

The EMXP/II IP multicast support supports snooping of the IGMPv2 and IGMPv3 protocolsand static configured multicast forwarding, seamlessly mixed.

2.4.1.1 Source Specific Multicast

Source-specific multicast (SSM) is a method of delivering multicast packets in which the onlypackets that are delivered to a receiver are those originating from a specific source address re-quested by the receiver.

SSM [RFC4647] requires that the receiver specify the source address, which is possible onlyin IGMPv3 [RFC3376].

The IP multicast forwarding function on the EMXP/II traffic units supports Any-Source Multicast(ASM) and Source-Specific Multicast (SSM). SSM is an IGMPv3 feature only.

TD-EMXPII Rev F | 2012-04-10 9 (72)

APPLICATIONS

The IGMPv3 snooping implementation on EMXP/II supports full IGMPv3 snooping, which pro-vides constrained flooding based on the (S, G) information in the IGMPv3 reports. This source-based filtering enables the device to constrain multicast traffic to a set of ports based on thesource that sends traffic to the multicast group.

2.5 MPLS Transport ProfileMPLS-TP is a way to simplify Carrier Ethernet by adding support for connection oriented serv-ices over a range of packet-based networking technologies including Ethernet and OTN.MPLS-TP contains technology enhancements to existing MPLS standards to extend MPLSwith tools to include support for traditional transport operational models.

It takes advantage of MPLS for getting more flexibility and network manageability than Ether-net technologies do in order to obtain that.

Fig. 11 An MPLS network scales over large networks with different topologies

MPLS-TP provides the transport layer functions to support the MEF services such as UNI[MEF13]. The actual Ethernet services are then carried in MPLS-TP Single-segment Pseudo-wires. MPLS-TP packet encapsulation and data plane architecture for pseudowires is thesame as for general MPLS data plane architecture described in [RFC3031] and [RFC3032].

The MPLS Generic Associated Channel (G-ACh) mechanism as specified in [RFC5586] is anintegral part of MPLS-TP. The G-ACh provides an auxiliary logical data channel associatedwith MPLS-TP LSPs in the data plane. This enables fate-sharing OAM traffic inband for MPLS-TP which will be added in a future release.

In the MPLS-TP LSP there are pseudowires carrying actual Ethernet data traffic. The referencearchitecture is according to [MPLS Forum 12.0.1] specification.

MPLS-TP does not rely on an MPLS control plane. Instead MPLS-TP enables a network man-agement system, like the TNM, to set up LSPs. This makes network provisioning more like tra-ditional transport network provisioning and provides total operator control of the traffic routes.This makes it easier for transport integration and thus removes the need to carry MPLS on ex-pensive router platforms.

TD-EMXPII Rev F | 2012-04-10 10 (72)

APPLICATIONS

TM series supports currently point–to–point Virtual Private Wire Service (VPWS) and single-segment pseudowires.

2.6 System Restrictions

2.6.1 Only CU-SFP

The GBE10-EMXP10/II, GBE22-EMXP10/II and EMXP80G/II MUST be used together with aCU-SFP or CU-SFP/II if used in a CU environment. The GBE10-EMXP10/II, GBE22-EMXP10/II and EMXP80G/II can not be used together with any of the older CU, CUOSC, CUOSC/1470/1490 or CUOSC/1510/1510.

The GBE10-EMXP10/II and EMXP40G/II can be used in a CU-less TM-101/102 chassis, whilethe GBE22-EMXP10/II and EMXP80G/II GBE22-EMXP10/II cannot (they are dual slot units).

2.6.2 Traffic affecting reboot

A reboot of the CU is not affecting traffic.

Nipissing::> swu reboot cu1.1 Reboot orderedWe are done

When rebooting the CU from the ENM GUI a warning pop-up is displayed. In the case of re-starting the main CU, this warning can be ignored (click OK).

If a reboot is made with a new configuration file, then the reboot of the CU is traffic affecting onthe EMXP/II. This includes the case when a reboot is made with unsaved changes. Allchanges must be saved before rebooting.

[1]Nipissing[unsaved]::> swu reboot cuThere is unsaved data. Do you want to reboot anyway?(yes/no) [no] no[1]Nipissing[unsaved]::> savesaving to Nipissing.xmlFile exists, overwrite? (yes or no) (no) yes........................................................................................................................................................................................................................Saving backup on central unit.Invalidating backup copies on traffic units.Slot 3:.............doneTransferring backup to traffic units.Slot 3:.............doneTransferring additional persistent files to traffic unitsSlot 3:.............snmpd.conf passwd doneNipissing::> swu reboot cu1.1 Reboot orderedWe are done

If the EMXP/II itself is restarted, the traffic will be affected. There is a warning both in the com-mand line interface and ENM GUI. These warnings shall not be ignored, a reboot of the trafficunit is traffic affecting.

TD-EMXPII Rev F | 2012-04-10 11 (72)

EMXP II PLATFORM

3 EMXP II PlatformThe entire EMXP/II platform consist of a common design. EMXP/II 10 and EMXP/II 22 share acommon main board and the EMXP/II 80 have a slightly larger switch core. The software andfeatures are the same for all boards within the EMXP/II platform. The GUI features and configu-ration options is the same.

Table 3 EMXP II Platform features

EMXP/II 10

• Single slot board with dual 10G interfaces.

• Used in installations where a lower port density isneeded or deployment where services areuncontended.

• Fits in the smaller 1U TM-101/102 chassis for edgedeployments or where are 10G access is needed.

EMXP/II 22

• Dual slot board with dual 10G interfaces and 22 xGbE interfaces.

• Used in installations where a higher port is neededor deployment where the services are aggregated.

• Most used board for Fast Ethernet (FE) services. Inthese cases, the 10G ports are unused and 1 or 2 ofthe GbE ports are used as uplinks.

EMXP/II 40

• Single slot board with 4 x 10G interfaces.

• Only possible to use in the TM-102 chassi as a 10Gacess.

• One 1 GbE port which can be used as extension portor as connection to lower speed networking.

EMXP/II 80

• Dual slot board with 8 x 10G interfaces. Targeted forhub configurations and handover points to core orProvider Edge (PE) routers. It is also used where10G switching or 10G aggregation is needed.

• One 1 GbE port which is intended as a an extensionport or as connection to lower speed networking forexample management traffic.

TD-EMXPII Rev F | 2012-04-10 12 (72)

EMXP II PLATFORM

3.1 Functional EMXP/II cardsEMXPII share a common main board design. There are slight differencies in switch core ca-pacity and size.

The functional blocks in Fig. 12 EMXP/II functional diagram is common across the platform.Besides the functional blocks there are connectors and other features present on the boards.For example, a FPGA for specialized functions and I2C buses between blocks. For efficiency,some of the features are also combined in the same silicon.

The left side represents the traffic connectors, the right side represents the backplane.

Fig. 12 EMXP/II functional diagram

The following sections describes the internal subsystems.

TD-EMXPII Rev F | 2012-04-10 13 (72)

PORTS

4 Ports

4.1 Analogue dataAnalogue data is retrieved from ports equipped with optical SFP’s or XFP’s. The following mainareas are available.

• Received optical power level

• Laser Bias current

• Laser output power

• Laser temperature

The available data is dependent on SFP or XFP type. A CWDM or MM SFP will not provide la-ser temperature, a DWDM SFP will.

Fig. 13 Port (L1) tab

TD-EMXPII Rev F | 2012-04-10 14 (72)

PORTS

4.1.1 Loop-back

Loopback of ingress traffic are provided on both GbE and 10G interfaces (Near end loopback),

Fig. 14 Near End Loopback

All traffic that are received are then looped back unaffected and without touching the switch.

4.1.2 ALS

The Ethernet Muxponder has Automatic Laser Shutdown (ALS) for laser safety.

4.1.3 Alarms

Any generated alarms are collected by the Control Unit and accessible via the node managerENM or network manager Transmode TNM. The status LED (STS-LED) on the board front in-dicates the severity of the active alarms.

The STS-LED will generate a red flash indication to assist replacement of a faulty unit whensupport personnel are at the site.

Alarms are described in the Alarm Overview document within the “Operation & Maintenance”volume.

4.2 Transmission PerformancePerformance Management is based on CRC on all interfaces and presented according toG.784/G.826.

A number of history PM reports are logged in zipped XML format in the node:

- Up to 96, 15-minute reports

- Up to 40, 24-hour reports

These reports are located in the node and can be uploaded to Transmode TNM or other higherlayer management systems.

TD-EMXPII Rev F | 2012-04-10 15 (72)

PORTS

Fig. 15 PM (L1) tab

TD-EMXPII Rev F | 2012-04-10 16 (72)

PORTS

4.3 Interfaces

4.3.1 Optics

The interfaces on the EMXP/II could be plugged with various SFPs and XFPs.

• 10/100/1000 BASE-TElectrical SFP’s are supported to provide electrical interfaces for 10 MBps, Fast Ethernetand Gigabit Ethernet interfaces.

• Uncolored opticsUncolored interfaces are supported for both SFP and XFP interfaces. On both single modeand multimode interfaces.

• CWDMCWDM SFPs are available in 8 or 16 channels up to 100 km. CWDM XFPs are available in8 channels up to 70 km.

• DWDMDWDM SFPs are available in 40 channels 100GHz spacing C-band up to 180 km. DWDMXFPs are available in 40 channels 100GHz spacing C-band up to 80 km.

• Tunable DWDMThe new 80-channel tunable DWDM 10G XFP modules are possible to use with the EMXP/II. These modules allow greater flexibility in planning, ordering, deployment and later net-work reconfiguration due to the ability of the modules to tune to any of the 80 DWDM wave-lengths supported by the TM-series.Additionally, these modules allow operators that hold inventory or spare part pools to keep asmaller number of modules as they no longer need to hold a large number of wavelengthspecific plug-in modules, therefore reducing cost.

4.3.2 Mirroring

Mirroring is when traffic on one port is mirrored to another port. The case supported is whenthe monitored ports are all located on the same EMXP/II as the destination port.

The mirrored traffic is normally sent to an external analyzer, e.g. a laptop running an analyzersoftware like Wireshark, an instrument (Ixia, Spirent) etc. EMXP/II can do ingress and egressmirroring, individually and at the same time.

Ingress mirroring is when all received traffic (ingress) is sent to a specific port. There are noVLAN member checks or trusted port member checks for a mirrored port, the ingress mirroredtraffic is sent unmodified. There can only be one mirrored port allowed per EMXP/II. The pack-ets do pass the egress pipe, so care should be taken so that there are no egress rules appliedto the output mirror port.

Egress mirroring is when all transmitted traffic (egress) is sent to a specific port.

4.3.3 MTU Size

The MTU size is configurable from 1518 to 10248 bytes. The MTU size should be set so thatthe desired traffic can be transported. The default MTU size is the maximum permissible value.The value is for untagged packets, i.e. MTU of 1518 means that a untagged packet can bemaximum 1518 long. A 802.1q tagged packet could be 1522 long.

TD-EMXPII Rev F | 2012-04-10 17 (72)

PORTS

4.3.4 Flow Control

Ethernet flow control is a mechanism for temporarily stopping the transmission of data on anEthernet network. A situation may arise where a sending station may be transmitting data fast-er than some other part of the network can accept it. The overwhelmed switch will then send aPAUSE frame, which halts the transmission of the sender for a specified period of time.

EMXP/II has head of line blocking prevention and will never send any pause frames. EMXP/IIdoes not have/need any input queues, thus the egress queues cannot create internal backpressure to ingress to create pause frames.

The EMXP/II can be configured to respect PAUSE frames and act on them. The pause quantain the pause frame determines the XOFF time. The EMXPII can therefore act towards switchesthat uses PAUSE mechanisms to achieve subrate transmit rates.

4.4 Management VLANOn the EMXP/II It is possible to enable Management VLAN. This is simply a tagged VLAN thatis bridged over to the Central Units internal bridge. It is possible to add either a C-tag or an S-tag and select which VLAN id the management shall use.

It is important that the interface with the management VLAN is configured as a NNI so that indi-vidual VLANs can be handled independently. For details regarding the setup and definition onManagement VLANs, please read the “Designing DCN Network Plans” [IC_Des_DCN].

A private VLAN function is included so that switch ports that cannot communicate with eachother can still access another network. These ports are normally called private ports. Each pri-vate VLAN contains one or more private ports, and one or more uplink ports. The uplink portsare defined as public ports, these can communicate with all other ports, both private and pub-lic. The private VLAN is implemented in the traffic board’s software bridge, which removes thebridging of client ports and it implements private VLAN in the Central Unit’s internal switchwhich removes the bridging between boards.

4.4.1 10G Boards

The EMXPII 40 and EMXPII 80 have one GbE port in addition to the 10G ports. This port usethe same internal switching resources as the Management VLAN. Either a board has the exter-nal GbE port enabled, or the Management VLAN capability enabled. It’s not possible to haveboth.

The EMXPII 40 board has the management VLAN capability enabled by default. To enable theexternal GbE port, the ability to performManagement VLAN has to be disabled. The EMXPII80 card does in R18 NOTcontain the ability for Management VLAN.

Fig. 16 PM (L1) tab

TD-EMXPII Rev F | 2012-04-10 18 (72)

SWITCH CORE

5 Switch Core

5.1 Main Switch DesignOutput queued (OQ) switches offer the best switching performance characteristics in terms ofdelay and throughput. In an output queued switch, every arriving packet will be transported toIt is output queue immediately and enqueued at that queue. Unlike input queued (IQ) switchesor combinations of input queued, midstage and output queued switches, no additional switch-ing delay is seen. In terms of performance, an output queued switch offers

• Lowest switch delays

• Lowest switch delay variation

• Highest switch throughput

• Simplest QoS implementation

In a standard output queue design, each output queue has It is own memory resource and it isassumed that resources associated with each queue isn’t very large. The standard outputqueue approach is limited by its burst absorption capability. During times of transient conges-tion, individual output queues may be temporarily overrun, resulting in packet drops. Standardoutput queues provides very inefficient memory efficiency.

The shared memory technology is a lot more efficient. A shared memory switch is a switchwhere all memory (in this case, only output queues) for all ports share a common pool of bufferresources. Pooling these buffer resources significantly increases the amount of buffering avail-able to any port. This dramatically improves burst absorption. It however, puts very high de-mands on buffer management to not create unfair buffer management and poor throughputisolation.

The EMXP/II is implemented using an output queue design, with shared memory buffers and adynamic thresholding technique. The dynamic thresholding policy is aimed at detecting switchcongestion and using this information to adapt the buffer management policy. The exact detailsof dynamic thresholding are internal.

The EMXP/II, using output queued switch with the described advanced buffer managementhave the following characteristics.

• Good bursts absorption. During times of mild congestion, the discard thresholds are prettyhigh, offering excellent burst absorption.

• Fair buffer access. The scheme, recognizing the current use of buffer resources, is by de-sign fair. The unallocated buffer space will minimize port starvation during transience whilestill maintaining good buffer utilization. .

• Port throughput isolation. Case studies shows that fairness also guarantees port isolation.Well behaving flows will have no or very low losses. Measurements on the EMXP/II indi-cates very good throughput isolation.

• Traffic independent performance. As the buffer algorithm is adaptive and changing to loadcondition, the steady state performance is optimal and independent of traffic scenario. Thisis the reason why the EMXP/II shows significantly better jitter performance than other com-parable high performance switches.

The EMXPII10 and EMXPII22 are equipped with 2 MB of common on-chip packet buffer. TheEMXPII80 has 4 MB of common on-chip packet buffer. A Transport Ethernet profile is achievedwithout large buffering delays and delay variation and with very stable and predictableperformance.

TD-EMXPII Rev F | 2012-04-10 19 (72)

SWITCH CORE

5.1.1 Performance

The performance has been verified in a test setup. The test setup in this example involves ahigh precision test instrument from Innocor and an EMXP/II10 using the two 10G ports.

Fig. 17 Test Setup with Innocor

The measurements show the latency for a frame that has passed the EMXP/II twice. The pre-sented values are therefore a two-way latency through the DUT. For one-way latency the val-ues shall be divided by two.

The Innocor Store and Forward metric is a calculated latency. The instrument has removed thestore and forward value once. However the store and forward value has to be removed twiceso the time for receiving the packet has been subtracted once more to get the values shownbelow.

Fig. 18 10G NNI<->NNI measured latency and Fig. 19 10G NNI<->NNI measured latencyshows an overview of the test results.

The EMXP/II performs exceptionally well in these tests. It outperforms everything found on themarket in regards to latency.

Note that almost all other switches have notable variation on max and min delay, i.e. jitter. TheEMXP/II has very low jitter on 10G speeds, and about 0.1us jitter on GbE speed. These param-eters will become increasingly important in LTE network and in networks with 1588v2 timing.

The results are published in a separate test report [TRM-2010:0043] together with all sourcedata. For more information regarding the test and test results, contact Transmode.

TD-EMXPII Rev F | 2012-04-10 20 (72)

SWITCH CORE

Fig. 18 10G NNI<->NNI measured latency

Fig. 19 10G NNI<->NNI measured latency

5.1.2 Testing at 100% load

When testing throughput on Ethernet it is important to be aware that small differences in linerates could introduce unwanted packet loss in the test and that can easily cause confusionwhen analyzing the test results.

Ethernet Networks require Synchronous Ethernet operation to have a distributed clock. IfSync-E is not enabled, ethernet line rate clock frequency is typically defined with an accuracyof +/- 100 parts per million (ppm).

The EMXP/II clock in free-running operation is about +/- 5 ppm. In a worst case scenario, theline rate frequency of the various tester is 100 ppm above the nominal frequency while the linerate frequency of the some EMXP/II in the network is 5 ppm below the nominal frequency, a to-tal difference of 105 ppm. In practice, the difference in nominal clock frequencies is typicallymuch lower, but since even the smallest differences in clock frequencies will cause unwantedpacket loss and/or packet buffering when testing a maximum load.

TD-EMXPII Rev F | 2012-04-10 21 (72)

SWITCH CORE

Since the EMXP/II have the Sync-E option, the easiest way to guarantee 100% line rate is tosynchronize the clock in the network. In a test situation, the clocks of the network should besynchronized against the test source.

The other option, is to reduce the clock on the test source is normally what is advised and rec-ommended. Further information and guidelines for line rate testing of Ethernet could be foundfrom various test instruments vendors.

5.1.3 Bridging

MAC address learning is a service that characterizes a learning bridge, in which the sourceMAC address of each received packet is stored so that future packets destined for that addresscan be forwarded only to the interface on which that address is located. Packets destined forunrecognized addresses are forwarded out on every port on the VLAN.

The MAC address table is 32,768 entries. The EMXP/II uses independent learning, so theMAC addresses are separate for each VLAN. Learning of unicast MAC addresses are doneautomatically by the hardware in wire speed. Aging is done in hardware. L2 Port bridging (orhair-pinning), where a frame can be forwarded on the same port as it was received is notallowed.

5.2 Policy FrameworkThe policy framework is mainly intended to be used together with Ethernet switching. However,parts of the policy framework also applies for MPLS-TP LERs.

The Policy Framework consists of two main parts, classification and processing. Ethernet Mux-ponder/II Installation Guide contains detailed information about applying the policy framework.

5.2.1 Classifications

A policy classification is created by defining one or more fields in the frame to classify on. Fig.20 and Fig. 21 shows a list of the L1 and L2 allowed policy classifications. It is possible to com-bine all types of classifications.

Fig. 20 Ingress Classifications

TD-EMXPII Rev F | 2012-04-10 22 (72)

SWITCH CORE

Each of the classifiers also gets precedence, so that collisions may be resolved and a kind ofprioritization is created amongst classifiers. Classifiers may be applied on ingress or egress.On egress there are slightly fewer options to classify on.

Fig. 21 Egress Classifications

TD-EMXPII Rev F | 2012-04-10 23 (72)

SWITCH CORE

5.2.2 Actions

Policy actions are added to the policy classification object. It is possible to add several policyactions to the same policy classification. The below example illustrates some possibilities.

Fig. 22 Policy Action

It is configurable to either drop the traffic or let it pass. It is possible to override the QoS queueassignment if the traffic is classified as green or yellow.

A number of VLAN policy actions can be selected, such as push a new outer VLAN tag whilekeeping any already existing tags in the VLAN stack or swap the outer VLAN tag.

An existing PCP can be copied to the SVLAN or you may decide to explicitly set the PCP ofthe SVLAN.

The actions pop, push or swap can be applied on an inner tag.

Bandwidth profiles (MEF policer) can be enforced on a classified traffic flow.

TD-EMXPII Rev F | 2012-04-10 24 (72)

SWITCH CORE

Fig. 23 Policy Example

In Fig. 23 Policy Example the flexible tag rules are used in order to handoff a uniform set ofVLAN IDs at the NNI interface at Nipissing, despite that a non.uniform and even overlappingVLAN numbering in the ingress interfaces.

5.3 Traffic ManagerQuality of service (QoS) is the ability to provide different priority to different applications, users,or data flows, or to guarantee a certain level of performance to a data flow. For example, a re-quired bit rate, delay, jitter or packet dropping probability.

Quality of service guarantees are important if the network capacity is insufficient, especially forreal-time streaming multimedia applications such as voice over IP and IP-TV, since these oftenrequire fixed bit rate and are delay and loss sensitive. In the absence of network congestion,QoS mechanisms are not required.

QoS is implemented entirely in the hardware and supports full wirespeed making it possible todeploy QoS features without adversely affecting packet switching performance.

5.3.1 Bandwidth profiles

Bandwidth profiles are also referred to as policing or rate limiting. Bandwidth profiles allowService Providers to offer services to users in increments lower than physical ports speeds. Al-so, it provides a possibility to engineer a network and make sure than certain parts of a networkare provisioned according to plan.

The bandwidth profile is expressed in Two Rate Three Color Marker (TrTCM) as defined in[RFC2698] and [MEF10.2] and are called “MEF Policers”.

TD-EMXPII Rev F | 2012-04-10 25 (72)

SWITCH CORE

Fig. 24 Two Rate Three Color Marker (TrTCM)

The Bandwidth Profiles takes the following four traffic parameters:

• Committed Information Rate (CIR) expressed as bits per second.

• Committed Burst Size (CBS) expressed as bytes.

• Excess Information Rate (EIR) expressed as bits per second.

• Excess Burst Size (EBS) expressed as bytes.

• Color Mode (CM) which has one of two possible values, “color-blind” and “color-aware.”

There is also a simpler bandwidth profile (or policer) defined, which only takes the two trafficparameters:

• Rate, expressed as bits per second.

• Burst Size expressed as bytes.

The bandwidth profile rate scales linearly from zero to line rate with a resolution of 8 kb/s. Therate is expressed in data rate. This means that the effective line rate is higher, especially forsmaller packets, since the interframe gap and preamble is included in the line rate.

The burst size is often hard to define. There are two ways to calculate burst size - relating tothe MTU of the traffic on the interface.

You should minimally support the MTU on the link. If it’s 1500B it could be wise to at least sup-port a number frames back-to-back, which could mean a burst size of Nx1500.

More often you want to support a burst of a given time at the maximum allowed bandwidth. Afrequently used value is to allow the burst size equal to 100 ms. With a service of 100 Mbpsthe calculated burst size would be 100.000 kbps x 100 ms / 8 bits = 1250 kB.

TD-EMXPII Rev F | 2012-04-10 26 (72)

SWITCH CORE

Fig. 25 MEF Policer

5.3.2 Ethernet Color Coding

Information about the color, i.e. if a frame is ‘yellow’ (drop eligible) can either be carried in theCFI/DEI bit or be coded on the PCP. Detailed information about PCP color coding can be foundin [IEEE 802.1ad-2005]

The color coding is done per port by assigning one of four separate configurable QoS profiles.

Fig. 26 User defined Color coding

TD-EMXPII Rev F | 2012-04-10 27 (72)

SWITCH CORE

If both color decoding and encoding is disabled the frames are passed through the switchtransparently, i.e. the PCP and CFI/DEI is not re-marked.

5.3.2.1 Color decoding

For color decoding on the ingress path it is possible to either select DEI decoding or PCP de-coding. The decoding schemes are exclusive, only one can be selected.

• DEI DecodeWith DEI decode enabled the color is decode from DEI (Drop Eligibility Indicator) bit in theVLAN tag for Service VLAN. For Customer VLAN the corresponding bit is called CFI (Can-onical Format Indicator) and will be interpreted by EMXP/II in the same way as DEI. If theDEI or CFI bit is set the frame will be tagged as Yellow or drop eligible.

• PCP DecodeWith PCP coding the color is superimposed on the PCP values, i.e. one or more PCP val-ues are used to carry color information instead of priority. EMXP/II supports four pre-definedcoding schemes:

• 8P0D : 8 priority values and 0 values for drop eligibility, i.e. straight one toone mapping of priority and no color information.

• 7P1D : 7 priority values and 1 value for drop eligibility



5.3.2.2 Color encoding

For color encoding on the egress path it is possible to either select DEI encoding or PCP en-coding. The decoding schemes are exclusive, only one can be selected. If any PCP encodingis enabled the DEI / CFI bit will be set to zero.

• DEI EncodeWith DEI encoding enabled, the frames which are marked yellow, either transparentlypassed through the switched or been marked in the policer, will have the CFI/DEI bit set toone.

• PCP EncodeOn the egress it is possible to select either the coding schemes described for PCP decodeor a user defined mapping.

5.3.3 Class of Service Scheduling

When a network experiences congestion and delay, some packets must be dropped or de-layed. The EMXP/II Class of service (CoS) support allows you to divide traffic into classes andoffer various levels of throughput and packet loss if or when congestion occurs.

Ethernet frames are differentiated based on their Class of Service marking. Class of Service(CoS) or 802.1p is a 3 bit field within an Ethernet frame header when using 802.1Q tagging.There are 8 different CoS priorities, 0 being the lowest (best effort) and 7 being the highest (pri-ority real-time data).

MPLS-TP traffic are differentiated based on their Traffic Class marking [RFC3270] and[RFC5462]. It’s a 3 bit field within an MPLS header. There are 8 different Traffic Class priorities,0 being the lowest (best effort) and 7 being the highest (priority real-time data).

The EMXP/II has 8 CoS queues per port. These 8 queues are serviced by a scheduler.

Mapping to a specific queue can be done in three different ways:

TD-EMXPII Rev F | 2012-04-10 28 (72)

SWITCH CORE

1. Classification on packet priority (PCP) to a specific queue. This is achieved by assigning amapping from packet priority to a priority on each ingress ports. Each ingress port is mappedto a profile. This is also described in the section on Color Coding.

2. Classification on a VLAN to a specific queue (“VLAN queue assignment”). This is achievedwith a rule in ingress pipeline which assigns the corresponding internal priority to the VLANwhich override the “CoS map” function. 256 rules are currently supported.

3. Classification of untagged frames results in assigning the native VLAN ID and priority, wherethe priority assigned is identical to the internal priority. The CoS map cannot be applied tountagged frames (as they don’t have a PCP field to classify on)

4. Classification of a MPLS-TP Traffic Class field to a specific queue. This is defined strictly bythe LSP traffic class.

5.3.4 Scheduling

The EXMP/II supports three different scheduling configurations for emptying the eight egressqueues. The three scheduling configurations are:

• StrictThe strict priority scheduler mode provides a strict priority access to the egress ports acrossthe queues from the highest priority Queue 8 to the lowest priority Queue 1. The main pur-pose for the strict priority scheduler is to provide low latency service to the higher CoSclasses and guaranteed bandwidth.

• Round Robin (RR)The scheduler provides round robin arbitration among the queues, serving one frame ineach non-empty queue at the time in a fair manner. This could be used to provide a fair ac-cess to port bandwidth on a frame level.

• Weighted Round Robin (WRR)The WRR scheduler provides a weighted access to the egress port bandwidth. In WRRmode, the scheduler provides access in a round robin order, when it serves a configurablenumber of back-to-back frames (if there are sufficient numbers in the queue). This is calledweights and is in the range from 1 to 127 per queue.

The value 0 is a special case setting which is used to designate that a particular queue ispart of the “Mixed Strict and WRR mode”.

• Mixed Strict and WRR modeThis the weights associated with a particular Queue is set to 0, that queue is considered tobe in a strict priority mode even though the main mode is WRR. This means that the sched-uler treats the set of queues with a weight of 0 as strict priority queues. These are servicesfirst in the order of their numbering.

5.3.5 Shaping

Traffic shaping is the control network traffic in order to optimize or guarantee performance, low-er latency, and/or increase usable bandwidth by delaying packets that meet certain criteria’s. Itis done by imposing additional delay on some packets such that the traffic conforms to a givenbandwidth profile. Traffic shaping provides a means to control the volume of traffic being sent

TD-EMXPII Rev F | 2012-04-10 29 (72)

SWITCH CORE

out on an interface in a specified period (bandwidth throttling), the maximum rate at which thetraffic is sent (rate limiting).

A Shaper is defined by its max bandwidth and it’s maximum allowed burst size. Traffic will belet out on the interface according to these parameters.

The cost is increased latency and jitter, but the gain could be better throughout since the trafficcharacteristic is better. Instead of dropping traffic in a policer, it’s better to shape the traffic tomake sure no frames are lost (or at least as few as possible), if the one queue is filled up, thenof course there is no alternative except dropping the frame.

Minimum bandwidth shaping is very useful when making sure that higher priority flows doesnot starve out the lower priority flows.

5.3.6 Active queuemanagement

WRED could be enabled or disabled for TCP flows. The default value is to have it enabled.Weighted Random early detection (WRED), also known as weighted random early discard isan active queue management algorithm. It is also a congestion avoidance algorithm. It moni-tors the average queue size and drops (or marks when used in conjunction with Explicit Con-gestion Notification ECN) packets based on statistical probabilities.

If the buffer is almost empty, all incoming packets are accepted. As the queue grows, the prob-ability for dropping an incoming packet grows too. When the buffer is full, the probability hasreached 1 and all incoming packets are dropped. Early detection helps avoid TCP globalsynchronization.

5.4 Ethernet OAMFor an Ethernet Service, or a part of an Ethernet Service, Ethernet OAM can be configured inorder to provide Connection Fault Management. Ethernet OAM is specified in [IEEE 802.1ag]and [Y.1731].

All OAM (except the UP MEPs) are entirely performed in hardware. There can currently be amaximum of 512 OAM sessions simultaneously enabled on one EMXP/II.

5.4.1 MaintenanceEntity

To determine the application of OAM flows, OAM Maintenance Entity (ME) is used, where aME represents an OAM entity that requires management. A Maintenance Entity Group (MEG)consists of the MEs that belong to the same service inside a common OAM domain.

TD-EMXPII Rev F | 2012-04-10 30 (72)

SWITCH CORE

Fig. 27 MEGs at ETH Layer [MEF 17]

Fig. 27MEGs at ETH Layer [MEF 17] is an example of MEGs typically involved in differentOAM domains. A MEG is essentially an association between two maintenance end points(MEP) within an OAM Domain; where each maintenance end point corresponds to a provi-sioned reference point that requires management.

In case MEGs are nested, the OAM flow of each MEG has to be clearly identifiable and sepa-rable from the OAM flows of the other MEGs. Therefore, MEG levels needs to be defined. EightMEG Levels are available which normally are used like below.

• Customer role is assigned three MEG Levels: 7, 6, and 5

• Provider role is assigned two MEG Levels: 4 and 3

• Operator role is assigned three MEG Levels: 2, 1, and 0

Fig. 27 includes some sample MEGs

• UNI and NNI MEGs at level 1.To monitor the service handoff between operators or betweenthe service provider and the subscribers. In this example they are defined at level 1.

• Operator A and Operator B MEGs at level 2. Keeping track of the service offered within theoperator domain.

• Service Provider MEG at level 4. These goes “over” the operator MEGs and monitors theservice across the entire service provider domain.

• Subscriber MEG at level 6. This is transparent for the service provider and the subscribersuse it to monitor the service offered by the service provider.

A MEG is defined by the Maintenance Domain and Maintenance Association. The EMXP/IIsupports all IEEE 802.1ag MD formats (DNS name, MAC address, Character string and“None”) and all IEEE 802.1ag and ITU-T Y.1731 MA formats (Primary VID, Character string,Two octet integer,RFC 2865, VPN ID and ICC).

The EMXP/II does not support Maintenance Intermediate Points (MIP).

5.4.2 MaintenanceEndpoint

The Maintenance endpoints (MEPs) are added to the MEG. In a simple point-to-pont service,two MEPs are added. In a multipoint-service more MEPs could be specified. On each EMXP/IIa local MEP should be defined, and also the remote MEP should be defined. Each with aunique MEPID within the MEP.

TD-EMXPII Rev F | 2012-04-10 31 (72)

SWITCH CORE

Fig. 28 MEG with 2 MEPs in a E-LINE

In a multipoint-service more MEPs could be specified. For a Multipoint-to-Multipoint E-LAN of“n” UNIs, a MEG normally contains “n*(n-1)/2”MEs

Fig. 29 MEG with 4 MEPs in a E-LAN

The EMXP/II supports both Up MEP and Down MEP. A Down MEPs always point from theEMXP/II, towards the fiber. An Up MEP point inwards, towards the switch.

Fig. 30 Up MEP and Down MEP

TD-EMXPII Rev F | 2012-04-10 32 (72)

SWITCH CORE

An example is Ethernet OAM on a protected service. Down MEPs monitor each protected leg,while an Up MEP monitors the entire protected service.

Fig. 31 Ethernet OAM on a protected Service

Down MEPs are maintained in Hardware. There could be 256 MEPs defined, each possible ofhaving a high frequency CCM session.

Up MEPs are maintained in software. There are a limited amount of Up MEPs available. Theavailable UP MEPs depend on currently available resources and are shown in GUI.

Fig. 32 Ethernet Up MEP and Down MEP

The UP MEPs support sequence numbers which makes it possible for the EDU to enableEthernet CFM based Packet loss and Availability measurements.

5.4.3 IEEE 802.1ag Continuity Check

Continuity Check messages (CCM) are "heart beat" messages for CFM. The Continuity CheckMessage provides a means to detect connectivity failures in an MA. CCMs are multicast mes-sages. CCMs are confined to a domain (MD). These messages are unidirectional and do notsolicit a response. Each MEP transmits a periodic multicast Continuity Check Message inwardtowards the other MEPs

EMXP/II supports all transmission intervals defined in the 802.1ag standard (3.33 ms, 10 ms,100 ms, 1 s, 10 s, 1 min and 10 min). There can be a maximum of 512 CCM sessionsconfigured.

TD-EMXPII Rev F | 2012-04-10 33 (72)

SWITCH CORE

5.4.4 IEEE 802.1ag Loopback

The EMXP/II has support for IEEE 802.1ag Loopback This is both to support the native loop-back testing as used on Ethernet network, but also to support the EDU’s RFC2544 tests. Thismeans that a G.802.1ag Loopback Responder functionality is present in a EMXP/II MEP.

The Loopback Responder receives Loopback Messages (LBM) at the MEG Level of the MEPonly, validates and filters them and transmits Loopback Replies (LBR) in response. Since therecould be more MEPs and sessions defined than there are loopback responders available inhardware, each loopback responder is enabled on a MEP. There could be a maximum of 256LBRs active per EMXP/II board.

An OAM loopback message at the correct MEG level with the destination address correspond-ing to Eth0 of the EMXP/II, which ingress on the correct port will be responded to with an OAMloopback response message.

There can only be ONE Loopback responder enabled MEP per VLAN. Also note that EMXP/IIonly supports down MEPs, so that the MEP with LBR is always located on the ingressinterface.

Fig. 33 One LBR per VLAN

There are currently no way to initiate a Loopback test in the EMXP/II.

TD-EMXPII Rev F | 2012-04-10 34 (72)

SYNCHRONIZATION SOLUTION

6 SynchronizationSolutionSynchronous Ethernet uses the physical layer to synchronize all nodes in a network to thesame frequency. In Synchronous Ethernet, the link frequency is linked to a traceable primaryreference source.

Fig. 34 Cell site synchronization

The ITU-T Synchronous Ethernet specifications, [G.8262] and others, are supported for jitterand wander tolerances, supported frequencies, clock specifications as specified for Synchro-nous Ethernet Equipment Clocks (EEC). The EMXP/II is also compatible with [ITU-T G.823] re-garding clock selection logic, possible clock quality levels, noise tolerances, noise generationand transfer limits, holdover performance etc.

SSM (Synchronization status messages) is used to provide traceability of the synchronizationsource. The Node shall be able to do automatic sync source selection. Network level SSM isdefined in [ITU-T G.781], The Ethernet Synchronization Messaging Channel (ESMC) is a com-munication channel for the SSM. It is described in [ITU-T G.8264].

Synchronous Ethernet are entirely run on physical Ethernet level. Whither the traffic forwardinguses MPLS-TP Label Switch Paths or Ethernet SVLANs does not at all affect timing andESMC. An Ethernet port with a MPLS Interface will forward Synchronous Ethernet in the samewas as a Ethernet port with a Ethernet UNI or NNI.

6.1 Synchronization DesignThe Precision Clock Synthesizer is a low loop bandwidth, jitter-attenuating clock multiplier. Itprovides frequency synthesis and jitter attenuation.

The Precision Clock Synthesizer implements hitless switching between the two clocks se-lected on the clock mux. This greatly minimizes the propagation of phase transients to theclock outputs during an input clock transition.

The Precision Clock Synthesizer provides a digital hold capability (Holdover) that allows thedevice to continue generation of a stable output clock when the selected input reference is lost.During digital hold, the Synthesizer generates an output frequency based on a historical aver-age frequency that existed some time before the error event occurred.

Primary and secondary sources could be selected from the input GbE or 10G ports, or thebackplane syncbus from another EMXP/II card.

TD-EMXPII Rev F | 2012-04-10 35 (72)


6.2 TM Synchronization solutionIn the TM Synchronization solution there are Synchronization domains, Synchronization busesand Synchronization sources.

There are a multistream synchronization-bus provided in all TM-chassis, TM-3000, TM-301and TM-101/102, that transfers synchronization between boards. This bus is used to transfersynchronization between EMXP/II boards.

Fig. 35 Sample Primary Sync Configuration

6.2.1 SynchronizationGroup

A Synchronization group is a board with it’s sources. Sources are the internal oscillator, theEthernet interfaces and the sync bus.

6.2.2 SynchronizationDomains

The EMXP/II TUs can also share information on the quality of the signal on subrack synchroni-zation buses. The board that is driving a sync bus reports the quality of its currently selectedsource. In order to do this, the board and the synchronization bus must be part of the same log-ical synchronization domain. In the above example, the Synchronization Groups sg:1:2,sg:1:3, sg:1:4 and sg:1:8 are part of sync domain 1.

TD-EMXPII Rev F | 2012-04-10 36 (72)


Fig. 36 Sync Domain 1

6.2.3 SynchronizationBuses

The EMXP/II can be configured to share synchronization signals via subrack synchronizationbuses. A EMXP/II can be configured to either extract a synchronization signal from the twosubrack sync buses or drive the same subrack sync buses. It is not possible to both listen toand drive the a bus at the same time. When a board drives a sync bus, it uses the synchroniza-tion signal derived from its currently selected source.

In Fig. 35 Sample Primary Sync Configuration, the Synchronization Bus A are part of sync do-main 1.

Fig. 37 Sync Bus A

6.2.4 SynchronizationSource Selection

Change of synch source can be manual or automatic. The EMXP/II performs hitless switchingbetween two synchronous input clocks in that greatly minimizes the propagation of phase tran-sients to the clock outputs during an input clock transition. The switching is done without affect-ing the traffic signals.

TD-EMXPII Rev F | 2012-04-10 37 (72)


6.2.4.1 Manual SynchronizationMode

When the synchronization function is in Manual mode the user can select which source to usefor synchronization. If the selected synchronization source is unavailable the internal synchro-nization source is used.

If the selected synch source is lost, an automatic switch to Digital Hold Mode is done.

6.2.4.2 Automatic SynchronizationMode

From R17.0, the synchronization function supports Sync quality signaling via ESMC/SSM asdefined in [ITU-T G.8264] and sync selection algorithm according to [ITU-T G.781].

Since ESMC/SSMmessages are link level messages only valid between two adjacent networknodes, the EMXP boards will only handle and send untagged ESMC frames. If an incomingESMC message is VLAN tagged, it will be regarded as a regular data frame and forwarded ac-cording to configured data plane rules.

The automatic synchronization function can be run in 2 modes:

• Quality level selection enabled

• Quality level selection disabled (default)

The operating mode of the synchronization process is configured on synch domain level, seeEthernet Muxponder/II Installation Guide

When the operating mode is Quality Level selection enabled, the system selects which syn-chronization source to use based on the following criteria:

1. Sync source nominated

2. Priority

In quality level selection enabled mode, the system selects which synchronization source touse based on the following criteria:

1. Sync source nominated

2. Sync Source Quality Level

3. Priority

A synch source is nominated for automatic sync selection if it is configured in mode enabledand is in state normal, see Ethernet Muxponder/II Installation Guide.

If two or more nominated sources have the same sync quality the function selects the sourcewith the highest priority. The priority is a value between 1 and 16 where 1 has the highestpriority.

If two or more nominated sources attain the same quality and priority and one of them is cur-rently selected, the selected source will remain selected. If no source was previously selected,a random source is selected.

A fallback to hold over mode is made if all sync sources fail.

TD-EMXPII Rev F | 2012-04-10 38 (72)


Fig. 38 Sample sync configuration with source selection

In Fig. 38 Sample sync configuration with source selection the primary source of synchroniza-tion for for the domain is port 1-2 on board in slot 8. Secondary source is port 9-10 on board inslot 10.

The way to configure this is make sure that Quality level selection is enabled and then let eachboard with sync sources drive one bus. See the above example where the master for Bus A isslot 8 and the master for Bus B is slot 10.

In the normal case, Synchronization Groups sg:1:2, sg:1:3, sg:1:4, sg:1:8, sg:1:10 and sg:1:12have bus A as the selected sync source. In case the port 1-2 on the board in slot 8 fails or gets“Do Not Use” for some reason, then Bus A will be deselected and sync source will be Bus Binstead.

6.2.5 SynchronizationStatus Messaging

Just as in SDH and SONET there is a synchronization signaling system in Synchronous Ether-net known as the Synchronization Status Message. It carries information about the quality levelof the source clock from clock to clock along the branches of the synchronization distributiontree. The source clock is either the PRC (normal condition) or in a failure conditions anotherclock in holdover mode. There are a number of pre-defined quality levels (QL) correspondingto existing clock specifications 0-16. Zero is unknown quality, 1 or 2 is the best and 15 means“Do Not Use‟. This signaling system is used for controlling protection switching in case of linkor clock failures.

TD-EMXPII Rev F | 2012-04-10 39 (72)


Fig. 39 Synchronization with Prim PRC Source Clock

Ethernet Synchronization Messaging Channel (ESMC) makes sure that there is always atraceable clock. In the above system both cell site A and cell site B will use the Prim PRC.

If however Prim PRC fails, or the communication between “EMXP 1” and Prim PRC fails thenEMXP 1 goes to holdover. The EMXPs (EMXP 4 and EMXP 6) in the Synchronous WDMMENwill notice that EMXP 2 provides a better traceable clock and switch to that one as reference.Both cell site A and cell site B will now use the Sec PRC instead as clock reference.

Fig. 40 Synchronization with Sec PRC Source Clock

6.2.6 Network Synchronization

It’s essential to avoid synchronization loops. The Ethernet Synchronization Messaging Chan-nel (ESMC) provides a way to automate sync source selection. ESMC is however not a routingprotocol, it only propagates the quality of the traceable clock.

TD-EMXPII Rev F | 2012-04-10 40 (72)


Fig. 41 Synchronization Loops at “A”

Very careful planning must be made to make sure that synchronization loops are not formed inerror cases. The EMXP/II supports “poisoned reverse” by always sending “Do not use” in thereverse direction, but sync loops could anyway be formed if the planning is poor.

If a sync loop is formed, then the clocks could drift away so that the interface looses timing withother interfaces and lead to traffic loss and loss of link.

6.3 Synchronization Performance ExampleThe test set up shown below, is very close to a real network that is considered to be deployed.It represents a fairly large network for layer 2 mobile backhaul transport.

Fig. 42 Sync measurement testbed

Both spans contains amplifiers and dispersion compensation. The sync report contains thespecifics of the test setup.

The measurement for the MTIE 1000 seconds exceeds the standards in orders of magnitude.One explanation for the good performance is that in contrast to SDH or SONET, there are nopointer processors.

TD-EMXPII Rev F | 2012-04-10 41 (72)


Fig. 43 MTIE 1000s

Fig. 44 TIE 12000s

The reason for the slope in Fig. 44 TIE 12000s is that small temperature changes will changethe latency of the fiber. As a thumb of rule, 1000 km of fiber would typically have a latencychange of 40 ns per degree C. The 4 ns shift could therefore correspond to at temperaturechange of about 0.3 degrees C. The fibers were kept in a room, without air conditioning and aclosed door.

During holdover, the phase will drift as there is no input frequency, so the internal board oscilla-tor will control the frequency. The holdover in Fig. 45 Holdover measured for 1000s was cre-ated by disconnecting the fiber to the first EMXP/II80 in the sync chain.

TD-EMXPII Rev F | 2012-04-10 42 (72)


Fig. 45 Holdover measured for 1000s

The figure shows holdover for 1000 s. As can be seen, the long time average frequency erroris less than 1 ppb.

The G.8262 document specifies hold over performance at constant temperature in Figure 11 inthe G.8262 document. According to Figure 11 in G.8262 the phase drift should be less than ap-proximately 50000 ns after 1000 s of measurement, and as the drift is only about 700 ns, themargin to the standard is more about 70 times.

For more information regarding hold over performance refer to[G.8262]

TD-EMXPII Rev F | 2012-04-10 43 (72)

FUNCTIONAL DESCRIPTIONS

7 Functional Descriptions

7.1 UNI, Service MultiplexedUNI and NNIA port on an EMXP/II can be setup in 3 modes. As a UNI (User Network Interface), a UniMux(Service Multiplexed UNI) or a NNI (Network Network Interface). The difference is how the traf-fic on the interface are grouped into services.

UNI All incoming traffic on a UNI port are mapped to one originating serviceand then transported through the network as one Service VLAN

UniMux There are several services originating on a port. Incoming traffic aremapped to the different services with tag-rules and then transportedthrough the network as several Service VLAN. Each Service VLAN arerouted independently through the network.

NNI Services are neither originated or terminated on the interface, they aretransported through the interface as Service VLANs and/or CustomerVLANs.

Fig. 46 Port Mode

In Fig. 46 Port Mode, Customer VLANs (C-VLAN) are mapped into Service VLANs (S-VLAN).Normally a Customer VLAN uses a C-VLAN Tag Protocol Identifier (TPID) 0x8100, and a Serv-ice VLAN uses S-VLAN TPID 0x88a8. For some reasons other combinations of VLANs andTPID may be used, for example a Service VLAN might use TPID 0x8100. This is configurableper VLAN

7.1.1 User-Network Interface (UNI)

The User-Network Interface (UNI) is designed to what MEF define as all to one bundling. Thismakes the UNI bundle all incoming traffic to a certain VLAN. The policy framework with classi-fier actions and VLAN rules block can only be configured to do the corresponding all to onebundling rules on the UNI interface.

The UNI is VLAN-unaware. That makes the port treat all of the incoming frames as customerdata which should be encapsulated in a service VLAN and tunneled transparently through thenetwork.

The VLAN unawareness of the UNI makes the tag status decoder tag all frames as untagged.This limits the possibility to use policies and VLAN rules to frames that enter a UNI.

TD-EMXPII Rev F | 2012-04-10 44 (72)


On egress a UNI always removes the outer VLAN tag to provide transparency between twoUNIs in the network.

On Ingress the UNI always pushes on a new outer VLAN tag which normally is the nativeVLAN ID of the port.

The UNI accepts all kinds of tag statuses and tagged traffic. It will however ignore any VLANtags in a frame.

The UNI can map between TPID domains. When pushing on additional tags the port willchoose the TPID that is configured in the VLAN map entry for the specific VLAN ID the portshould push to.

7.1.2 Service MultiplexedUser-Network Interface (UniMux)

A service multiplexed User-Network Interface (UniMux) is an interface that realizes many-to-many bundling according to MEF. The UniMux allows for more flexibility than the UNI since it isC-VLAN aware and can map traffic flows very dynamically through the use of the policy frame-work and VLAN rules.

The UniMux is designed to handle the cases where the end user has several different uniquedata streams that each need to be handled differently by the network. A good example is triple-play, where IP-telephony requires low latency and a guaranteed bandwidth and TCP/IP datausually does not have the same real-time demands. A UniMux can map these two datastreams into different service VLANs with different CoS throughout the network.

The UniMux is C-VLAN aware. Note that a UNIMUX will treat frames with an outer S-VLAN tagas untagged frames.

AVLAN translation has to be configured in order for a UniMux to forward traffic. This is done toseparate customer traffic VLAN IDs from service provider VLAN IDs. AVLAN translation suit-able to configure on a UniMux interface is normally a push operation.

On egress the UNIMUX always removes the outermost VLAN tag to provide transparency be-tween two UNIMUX interfaces in a network.

The UNIMUX can map between TPID domains. When pushing on additional tags the port willchoose the TPID that is configured in the VLAN map entry for the specific VLAN ID the portshould push to.

7.1.3 Network-Network Interface (NNI)

The Network-Network Interface (NNI) is designed to interface two network elements. The NNIis also designed to comply with the MEF standard with one addition. The NNI can be config-ured to allow untagged frames for increased flexibility and ease of interfacing against 3rd partyhardware.

The NNI is fully VLAN aware and thereby supports the full flexibility of the policy frameworkand the VLAN rules.

To use an interface for MPLS-TP, it MUST be set in NNI mode.

The NNI is used to interface between different networks nodes. This means that it does notmap between customer and service TPID domains because it is designed not to switch trafficbetween the service network and a customer network. This makes the NNI incapable of push-ing outer tags with any other TPID than the TPID of the outer VLAN tag of a frame the opera-tion is being performed on.

TD-EMXPII Rev F | 2012-04-10 45 (72)


7.1.4 Native VLAN

Port modes have two significant attributes: native VLAN ID and native VLAN priority. These at-tributes decide how to treat untagged traffic. The untagged traffic will be tagged with the nativeVLAN ID and a CoS value corresponding to the native VLAN priority. How the TPID is assigneddiffers between the port modes.

7.1.5 Service VLANs and Customer VLANs

The EMXP supports the full range of VLAN IDs, 4094 per EMXP board. Each of those couldbe either C-VLAN or S-VLAN. It is possible to have a C-VLAN 2039 next to a S-VLAN 165 with-out limitation, but it is not possible to have both a C-VLAN 235 and S-VLAN 235 on the sameboard simultaneously.

When adding VLAN 100, with a native VLAN, a policy or a rule, the TPID of that VLAN100 isdefined in the VLAN definition.

7.1.6 Service Transparency

A UNI port is normally setup to transport everything transparently. This means that the incom-ing traffic may be a MPLS frame, a doubletagged frame, a service frame or almost any otherkind of Ethernet frame. Most traffic except PAUSE frames are transparent.

The following Layer 2 Control protocol frames are examples of traffic that are transparentlytransported by the Service VLAN.

• IEEE Std 802.1D Bridge Group Address 01-80-C2-00-00-00, used for example by STP andRSTP.

• Link Aggregation Control Protocol (LACP) and Ethernet in the first mile (IEEE 802.3ahEFM) using IEEE Std 802.3 Slow Protocols multicast address 01-80-C2-00-00-02.

• IEEE 802.1x port authentication using reserved MAC address 01-80-C2-00-00-03.

• Multiple Registration Protocol (MRP) using 01-80-C2-00-00-20 to 01-80-C2-00-00-2F. E.g.Generic Attribute Registration Protocol (GARP) .

According to [MEF 13] a UNI SHOULD discard 802.3x PAUSE frames if these are not handledlocally. It means that these are NOT transported into a SVLAN. They are either dropped orhandled locally, depending on port PAUSE configuration.

• IEEE 802.3x PAUSE - The 802.3x MAC control frames have destination MAC address 01-80-C2-00-00-01

Some frames are also terminated because the service is part of the network. This includes forexample Synchronous Ethernet or Ethernet CFM.

• Ethernet Synchronization Messaging Channel (ESMC). Uses Ethernet Slow protocol MACaddress 01-80-C2-00-00-02 with ethertype 0x8809. If Quality Level selection is activated,then Ethernet Synchronization Messaging Channel (ESMC) handled locally.

• Ethernet Connectivity Fault Management (CFM) uses well known MAC addresses from therange 01-80-C2-00-00-30 to 01-80-C2-00-00-3F. If Ethernet OAM is configured in the Net-work, then some traffic is handled locally depending on MEG levels used. For more informa-tion on Ethernet OAM transparence, see 5.4 Ethernet OAM.

TD-EMXPII Rev F | 2012-04-10 46 (72)


7.2 Port TrustTrusted port defines which other port members are trusted with this port. A frame received onthis ingress port can only egress to the members defined in the list of trusted ports. This cre-ates private vlan members, so that no traffic is “leaked” between client ports in a private vlan.

For an E-TREE service, a root port may communicate with all leaf ports, but leaf ports can onlycommunicate with a root port. These are defined so that all leaf ports are trusted with the rootport. The root port is trusted with all the leaf ports. This is also the way a private VLAN serviceis defined, leaf ports cannot communicate with other leaf ports.

A broadcast service is setup so that all leaf ports are trusted in the root port, but no ports aretrusted by the leaf ports. In this way traffic only flows in the direction from the root to the leafports.

It is also possible to use the port trust to segment a SVLAN in two or more parts, using a “split-horizon” kind of feature. Traffic in one part of the same VLAN isn’t forwarded to other parts ofthe same VLAN, or traffic from one part of the VLAN may only flow in one direction to anotherpart of the VLAN.

7.3 Link AggregationLink Aggregation or trunking is a method of combining physical network links into a single logi-cal link for increased bandwidth and/or resilience. With Link aggregation it is possible to in-crease the capacity and availability of the communications channel. A set of multiple parallelphysical links between two devices is grouped together to form a single logical link. Link Aggre-gation provides load balancing where the traffic distributed across several links in a trunk.

It is possible to define a link aggregate consisting of up to 8 ports. All ports in a link aggregatemust have the same port speed.

Most implementations of LAG now conform to what used to be clause 43 of [IEEE 802.3-2008]Ethernet standard, informally referred to as "802.3ad". This includes the EMXP/II which hasbeen interoperability tested against several other vendor solutions.

You may define VLAN rules for retagging or QoS classification on a Link Aggregate and youcould define bandwidth profiles on a Link Aggregate. Although it’s possible to use a Link Ag-gregate as any UNI or NNI interface there are certain restrictions on a Link Aggregates. Not allthe features are available on a Link Aggregate that is normally available on an interface.It isnot possible to:

• define a MEP on a link Aggregate.

• setup ERP on a link Aggregate.

The EMXP/II support static IEEE 802.3ad Link Aggregation. This means that Link AggregationControl Protocol (LACP) is not supported.

7.3.1 Load distribution

Link Aggregation provides a even distribution of traffic on the interfaces in the Link Aggregate.However, to avoid packet reordering, it is important that all traffic pertaining to the same

TD-EMXPII Rev F | 2012-04-10 47 (72)


dataflow are kept on the same interface, and not spread over several interfaces. The EMXP/IIsupport 3 definitions of flows, Layer 2, Layer 3 or one Ethernet Service.

• MAC— Default the hash is made on the layer 2 flows, on a per DA/SA/VLAN/TPID/Port.

• IP — It is possible to configure the hash on IP flows, the IP Src/Dst and TCP/UDP src/dstport.

• VLAN— There are support to do load sharing based on 802.1q vlan, i.e. VLAN ID andTPID. This is to support the MEF requirements on packet reorder on an EVC. And also tosupport the scenarios where maintained IP flows are not enough.

The hash definition is valid for all Link Aggregates on the same board, the setting is not sepa-rate for each Link Aggregate.

Although link aggregation combines ports, it's not necessarily the case that throughput willscale linearly with port count. Fairness, or the uniformity of flow distribution across members ofa link aggregation group (LAG), is always a concern.

The EMXP/II has an advanced and very wide hash algorithm to provide the best possible distri-bution. Additionally it could include L4 port information to improve the load distribution. The en-gine searches for the fields 2 tags down so that encapsulation headers won't hide the hashfields.

However, if the fields to separate flows are buried to far down, e.g. using several mpls transportand pseudowire tags, or if the traffic consists of only a few flows generated by a test instru-ment, then the distribution could be very poor or even not distributed at all.

If there are only a few flows, then the probability that the distribution is going to be poor is great-er. There is no mechanism to improve the random distribution of flows so that it becomes morebalanced.

7.4 Ethernet Rings Protection SwitchingEthernet Rings Protection Switching (ERPS), as defined in [ITU-T G.8032], provides sub-50msprotection for Ethernet traffic in a ring topology and at the same time ensuring that there are noloops formed at the Ethernet layer.

The Ethernet ring protection works at the physical level. The ring protection operates at the in-terface (port) level and not at the VLAN level. This means that traffic is blocked for ALLVLANson the Ring Protection Link, RPL. ERPS works best when learning is activated, but alsoVLANs without learning are protected.

An Ethernet ring is made of two or more nodes which are connected via links. Each node hastwo ring links connected to other nodes. To avoid loops, one link in the ring must always beblocked. The link that is blocked under normal conditions is called ring protection link or RPL.One of the nodes connected to this link is called the RPL owner and is responsible to controlthe status of the RPL. In the example below the link between node C and node D are the RPLand the node C are the RPL Owner.

TD-EMXPII Rev F | 2012-04-10 48 (72)


Fig. 47 ERP in action

When a failure is detected in the ring, the RPL owner is responsible for un-blocking the RPL fortraffic. A link failure is detected by link down events or OAM defects e.g. continuity check.

When a failure has been detected, the ring is said to be in a ‘Signal Failure’ (SF) state. Thenode detecting the SF condition will block the traffic on the failed link and inform the other ringnodes. When the ring nodes are informed about a ring failure, the learned MAC addresses areflushed.

In Fig. 47 ERP in action the nodes in the ring will re-learn the destinations MAC of the stationsparticipating in the blue flow and traffic will flow over the unblocked RPL

The ring protection is always revertive, i.e. when the failure is cleared the ring reverts back tothe initial state where the RPL is blocked. To avoid unnecessary switching because of intermit-tent failures, the ring first enters a ‘Wait to restore’ (WTR) state when the failure is cleared. Afterthe WTR time expires, the RPL owner blocks the RPL and requests the previously failed link tobe un-blocked.

The default state, where there are no failures in the ring and only the RPL is blocked, is calledthe Idle state.

7.4.1 OAM signal fail detection

It is recommended to configure Ethernet OAM for the ring and also utilize OAM events for sig-nal fail detection. When this is enabled it is possible to detect fail for signals going through sev-eral other nodes in between two ring nodes. At a 3.33ms CCM interval, the fault detection isbelow 15 ms.

TD-EMXPII Rev F | 2012-04-10 49 (72)


Fig. 48 Sample ERPOAMSetup

If Ethernet OAM is NOTused in a ERP ring, there is no way for an ERP node to know that theneighbor node is up except that the interface that is defined has link up signal. If there is a linkbreak, and for example a test instrument is connected on the failing interface, this could be in-terpreted as the link is ok again and the node will signal ok condition. This could have fatal re-sult in the ring.

In rings that have a combination of direct fiber, WDM lambdas and leased lines, there MUSTbe Ethernet OAM fault detection on the links that passed other leased lines. There might bedisturbances that are not cached by normal LOS detection by the nodes.

Fig. 49 ERP OAM setup over leased line

In the above case, it’s necessary to configure a MEG supervision at least on the leased line.The MEG levels used for the ERP and for the Ethernet OAM must be configured so that theleased line is transparent. See 5.4.1Maintenance Entity for further details on MEG leveltransparency.

TD-EMXPII Rev F | 2012-04-10 50 (72)


7.4.2 Multiple Rings

It is possible to define several rings on one EMXP/II. This is rings separated from each otherand not interconnected rings or sub-rings.

Fig. 50 Several rings per EMXP/II

Limitations on support for multiple independent rings:

• Only one ring node can be shared between two rings. If more nodes are shared there is arisk for loops when the same VLAN identity exists in both rings. One port may only be as-signed to one ring.

• The VLAN identity used for the R-APS channel must be unique to a ring.

• It is possible to configure a maximum of four rings per board.

7.5 IP Version 4 MulticastThe EMXP/II family supports IPv4 multicast traffic forwarding through the IGMP-snooping func-tionality. By snooping the IGMP control plane traffic between multicast routers and multicast cli-ents the EMXP/II is building IP multicast membership and forwarding tables. A member of amulticast group (a client that subscribes to a specific IP multicast stream), is represented by anentry in the multicast membership table.

The IP multicast support comprehends snooping of the IGMPv2 and IGMPv3 protocols andstatic configured multicast forwarding, seamlessly mixed if so desired.

The IP multicast forwarding function on the EMXP/II traffic units supports Any-Source Multicast(ASM) and Source-Specific Multicast (SSM) [RFC4607]. SSM is an IGMPv3 feature only.

The membership table holds members that are represented by their IP address, joined multi-cast group, multicast source, uptime and age-out timer. Uptime is defines how long the mem-bership subscription has been configured. The age-out timer defines the time until thesubscription is dropped if not renewed.

The EMXP/II family support explicit host tracking. Explicit host tracking means that the EMXP/II does keep track of multicast group subscriptions from multicast hosts independently. Thisfunctionality is required to achieve low join/leave latencies in environments where many hostsare connected to the same port.

The forwarding table which keeps information on how the IP multicast streams should be for-warded. The forwarding table entries are defined by a multicast source IP, a multicast group IP,a VLAN and finally a port list. The port list defines which ports that the multicast group shouldbe forwarded to.

The EMXP/II family does support limited tagging and untagging operations on multicaststreams while operating in IGMP snooping mode. Supported and unsupported tagging opera-tions can be found in 7.5.3 Special considerations for IP multicast forwarding

TD-EMXPII Rev F | 2012-04-10 51 (72)


7.5.1 IGMP control plane forwarding

Ports that are not IGMP enabled are transparent to IGMP queries and IGMP membership re-ports and forwarding is done according to the VLAN map and trust settings.

The IGMP control plane messages are forwarded according to the recommendations in[RFC4541] on IGMP enabled ports.

All IGMP control plane messages obey trust and VLAN map configurations.

The ports connected to multicast routers needs to be configured as router enabled in order toproperly forward IGMP control plane messages.

IGMP Queries are forwarded to all IGMP enabled ports that are that are members of the cor-rect VLAN map and are trusted by a router enabled ingress port. IGMP queries that ingress ona non router enabled and IGMP enabled port are dropped.

IGMP Membership Reports are forwarded to all router enabled IGMP ports that are membersof the correct VLAN map and are trusted by the IGMP enabled ingress port.

7.5.2 Multicast ForwardingRules

The following forwarding rules are only applicable if the ingress port is IGMP enabled.

Multicast traffic always obeys trust and VLAN map settings.

Layer 2 multicast that is not recognized as IP multicast is flooded according to the VLAN mapand trust settings.

Layer 2 multicast that is also recognized as IP multicast is forwarded according to the IP multi-cast forwarding table, if there are no entry for that multicast group in the forwarding table theframe will be dropped.

Multicast traffic is always flooded to trusted and IGMP enabled ERP ports on the VLAN.

Reserved IPv4 multicast range 224.0.0.X is forwarded by default, optionally reserved rangeforwarding can be turned off.

The IGMP control plane is always forwarded despite that reserved range forwarding is turnedoff.

7.5.3 Special considerations for IP multicast forwarding

IGMP snooping functionality is only supported on ports in NNI mode, where the native VLANtagging gives tagging flexibility.

The policy framework functions or the VLAN rules are unsupported in conjunction with IP mul-ticast traffic forwarding and IGMP control plane traffic.

Members are never dynamically learned through IGMP snooping on ERP ports but all multicastis flooded to the ERP ring(s).

When multicast forwarding is enabled on the EMXP/II TUs stricter checks for valid source IPaddress checks are made in hardware since multicast forwarding is a layer three feature. Thestricter IP check results in packets with a source IP equal to 0.0.0.0 will be dropped on multi-cast enabled ingress ports.

In the EMXP/II multicast forwarding table SSM entries has precedence over ASM entries. Thismeans that the SSM entry port list will be used for multicast forwarding if there is a conflict.

TD-EMXPII Rev F | 2012-04-10 52 (72)


7.5.4 Recommendations for high performancemulticast networks

To fully utilize the performance of IGMP snooping capabilities with swift join and leave latency,Transmode recommends setting the query response interval higher than or equal to 5 secondsfor IGMP queriers in the network. The recommendation is valid both for IGMPv3 and IGMPv2environments and in networks with a high degree of utilization of the multicast membershiptable.

7.6 MPLS-TPMultiprotocol Label Switching (MPLS) is a technique that allows the forwarding of packetsbased on labels. In a Transport Ethernet network, the frames are switched based on theSVLAN tags. In an MPLS network, the packets are switched based on labels.

MPLS provides mechanisms for Quality of Service (QoS) [RFC3270] and IP traffic engineering(TE) that are slightly different and separate from the Class of Service (CoS) mechanisms usedfor Ethernet forwarding.

MPLS-TP enables MPLS to support packet transport services with a operational proceduresand Service monitoring that is similar to the existing Ethernet transport networks [RFC5921].

7.6.1 MPLS-TP and Ethernet Interworking

Both Ethernet and MPLS have their own benefits and it is in most cases beneficial to supportservices on both technologies. For instance multicast services are often more suited for de-ployment directly over Service VLANs on Ethernet, whereas protected monitored point-to-pointtrunking benefits more from the MPLS-TP features.

In the TM-series, Ethernet and MPLS can co-exist in the same system and on the same EMXPboards. It is possible to run MPLS selective per port or separate MPLS traffic based on MACaddress and VLAN within the same port. This allows seamless migration and co-existence withthe two protocols running independently side by side.

In order to deploy MPLS in a production network, MPLS can be introduced either as an overlayto the existing Ethernet or incremental to as an evolutionary build-out in parallel on the samenetworking hardware. Transmode believes that a smooth evolution, provided by “Ships in theNight” capability with Ethernet and MPLS in parallel as independent non-interfering protocolsin the same system.

7.6.2 MPLS-TP Label Switched Path

An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses the earlier describedfeatures in MPLS-TP in order to meet the requirements of an MPLS transport network in aPacket switched Network (PSN).

The characteristics of an MPLS-TP LSP are primarily that it:

• supports 1:1 protection functions.

• has fate sharing Service OAM

• is traffic engineered.

• does not rely on any control plane. It is established and maintained via the managementplane.

is co-routed bidirectional and point-to-point and the intermediate nodes are aware of theirassociation.

TD-EMXPII Rev F | 2012-04-10 53 (72)


7.6.3 MPLS-TP Provider Edge and Provider Nodes

An MPLS-TP Provider Edge (PE) is an MPLS-TP switching node that adapts client traffic andencapsulates it to be transported over an MPLS-TP LSP. Encapsulation is normally a PW, butcould just pushing a label.

An MPLS-TP Provider (P) is an MPLS-TP switching node that does not provide MPLS-TP PEfunctionality for a given LSP. An MPLS-TP P node switches LSPs that carry client traffic, butdoes not adapt client traffic and encapsulate it to be carried over an MPLS-TP LSP.

The term Provider Edge (router) and Provider (router) refers to the node's role within a providenetwork. A provider edge resides at the edge of a given MPLS-TP network domain, in whichcase it has links to another MPLS-TP network domain, an MPLS domain or to a CE. A providernode does not have links to other network domains.

Note that the use of the term "router" in this context is historic and neither requires nor pre-cludes the ability to perform IP forwarding. It’s sometimes used in MPLS context instead of“node”.

Fig. 51 MPLS-TP Framework

An MPLS-TP Label Switching Router (LSR) is either an MPLS-TP Provider Edge (PE) Switchor an MPLS-TP Provider (P) Switch for a given LSP. The terms Label Switching Router (LSR)and Label Edge Router (LER) describe logical functions, a specific node may undertake onlyone of these roles on a given LSP.

An MPLS-TP Label Edge Router (LER) is an LSR that exists at the endpoints of an LSP andtherefore pushes or pops the LSP label, i.e., does not perform a label swap on the particularLSP under consideration.

In Fig. 51MPLS-TP Framework, switch A, C and D are MPLS-TP PE nodes. Switch B is aMPLS-TP P nodes since it does not have any connectivity towards other network domains.

Switch A and C acts as LERs for LSP 1, while switch D acts as LSR for LSP 2 and LER forLSP 3.

7.6.4 MPLS-TP Tunnels

An MPLS-TP tunnel is a MPLS-TP transport path from the source Label Edge Router (LER) tothe destination LER. An MPLS-TP Tunnel could be protected or unprotected.

TD-EMXPII Rev F | 2012-04-10 54 (72)


Fig. 52 ProtectedMPLS-TP Tunnel

The MPLS-TP Tunnel always have a working LSP that defines the primary path. It may alsohave a protect LSP which define a recovery path.

7.6.5 MPLS-TP Linear Protection

In MPLS-TP, protection is accomplished by pre-establishing a working LSP and a protect LSPthat support the same MPLS-TP tunnel in the network. These LSPs are configured via the net-work management system, but switch-over is done autonomously in the nodes without any de-pendency on control plane or network management systems.

Protection switching can be triggered from either a local or remote fault, a fault detected by theOAM sessions or by manual commands e.g for planned maintenance. The EMXP supports 1:1linear protection as specified by [RFC6372]. With MPLS linear protection it is possible to con-figure protected paths for all common topologies including rings, mesh and partial meshes.

Traffic switchover time from working LSP to protect LSP and vice versa depends largely on thedetection times for the fault. If the fault is detectable by any of the LER on the protected MPLS-TP tunnel then the MPLS-TP Linear Protection State Control protocol[RFC6378] will ensurethat protection state change occurs within 50 ms. The MPLS-TP Linear Protection State Con-trol is however a dynamic protocol and the exact time for individual session recovery varieswith deployments. If the fault requires MPLS-TP OAM to be detectable, then the recovery timewill be dependant on the fault discovery time.

The manual commands is provided for manual control of the protection-switching operation ac-cording to [RFC6378] and [RFC4427]. These commands apply to a protection group:

Lockout Results in the recovery LSP being temporarily unavailable to transport traf-fic (either normal or extra traffic).

Forced Switch Forces a switch of normal data traffic to the recovery LSP.

Manual Switch Forces a switch of data traffic to the recovery LSP only when there is nodefect in the recovery LSP.

The OAM functions belong to the MPLS–TP data plane and are independent from the controlplane routing and signaling protocols. This means that a control plane failure does not impactthe data plane. The OAMmessages are forwarded along path of the specified LSP or Pseudo-wire in a specific management channel on G-Ach per [RFC5586].

The OAMmessages are used for fault management, connection verification, continuity check,and other functions. The MPLS-TO OAM Framework are described in [RFC6371]. The MPLS-TP OAM is based on Bidirectional Forwarding Detection (BFD) as defined in [RFC5880] and[RFC5884].

TD-EMXPII Rev F | 2012-04-10 55 (72)


7.6.6 MPLS-TP OAM

The methods for proactive Continuity Check, Continuity Verification, and Remote Defect Indi-cation for MPLS-TP Label Switched Paths is be based on the extensions to Bidirectional For-warding Detection (BFD) as described in [RFC6428].

The MPLS-TP Continuity Check (CC) is a function to enable an End Point to monitor the liven-ess of an LSP, The monitoring is explicitly configured by defining a BFD Session, then themonitoring is performed proactively. The Remote Defect Indication (RDI) function is included inthe MPLS-TP Continuity Check to report any a fault or defect condition that it detects on theLSP remote end.

The MPLS-TP Continuity Verification (CV) is a function to enable an End Point to determinewhether or not it is connected to specific End Point(s) by means of the expected LSP. Themonitoring is explicitly configured by defining the MPLS-TP Continuity Check with the BFDSession and the monitoring is performed proactively in that session.

Fig. 53 ProtectedMPLS-TP Tunnel, BFD Session

In the example in Fig. 53, an MPLS-TP OAM session is required for the Protect LSP for theprotection to work properly. Any fault that occurs between LSR “D” and LSR “E” are not de-tected by the MPLS-TP Tunnel LERs and therefore a BFD session between LER “A” and LER“C” on the protect LSP are required to monitor and verify the connectivity and liveliness of theprotect LSP.

Fault occurring that affects the working LSP are likely to be detected by the MPLS-TP TunnelLERs and propagated using the MPLS-TP Linear Protection State Control protocol. However,a monitoring BFD session is recommended also for the working LSP, for example to catch in-ternal forwarding problems in the LSR ”B”.

The encapsulations used in the MPLS-TP OAM is the MPLS-TP Generic Associated ChannelLabel (GAL) / Generic Associated Channel (G-ACh) encapsulation with codepoints 0x0022 forMPLS-TP CC messages and 0x0023 for MPLS-TP CV messages. Poll/Final discipline is usedto initiate the periodicity of control message exchange to the desired rates according to[RFC6428].

Information regarding configuration of MPLS-TP MEP-ID for LSP, Global ID, Node ID, TunnelID and LSP ID can be found in Ethernet Muxponder/II Installation Guide. The definitions arealigned according to [RFC6370].

The BFD mode that is used is asynchronous and BFD sessions run in the coordinated mode.

TD-EMXPII Rev F | 2012-04-10 56 (72)


7.6.7 Pseudowire (PW)

In the MPLS-TP LSP there are PW carrying actual data traffic. The data plane architectures forpseudowires [RFC3985] are used in MPLS-TP. Data plane processing procedures for Ethernetpseudowires are defined in [RFC4448].

Fig. 54 MPLS-TP Tunnel and PW

A pseudowire (PW) is an emulation of a Layer 2 point-to-point, connection-oriented serviceover a packet-switching network (PSN), from Attachment circuit (AC) to AC. The pseudowire(PW) is a tunnel established between two MPLS-TP Provider Edge (PE) across the MPLS-TPtunnel with the AC Layer 2 frames encapsulated as MPLS data.

Fig. 55 Ethernet over MPLS Encapsulation

Fig. 56 PW FEC

When defining an Attachment Circuit, this is done by classifying a Forwarding EquivalenceClass (FEC) to a Pseudowire.

Ethernet Raw Mode [RFC4448] is used all the time, where no Attachment Ciruit tags are re-moved or added by default. This is even the case when there are VLAN FECs defined. The en-tire frame is forwarded and the tags are not considered to be service delimiting.

TD-EMXPII Rev F | 2012-04-10 57 (72)


7.6.8 MPLS label space

MPLS uses labels from either the platform label space or the interface label space. In the EMX-PII the LSP uses interface labels and PW uses platform labels.

The label spaces can never overlap. The platform label space is a large pool of labels that canbe shared by all PW on the node. PW label are forwarded over the MPLS-TP Tunnels so thatthe per PW per platform label space essentially are shared in the entire network and used byall MPLS-TP PE switches.

By contrast, interface labels are a smaller set, well defined, and aligned between peer interfa-ces. Each label from the interface label space only has local significance on that particular link.This enables you to use the same label on different interfaces without conflict.

This should be administered before starting to setup LSP so that a network wide templatecould be used.

7.6.9 MPLS-TP Interface

Ethernet and MPLS-TP can co-exist in the same system and on the same EMXP boards. It ispossible to run MPLS selective per port or separate MPLS traffic based on MAC address andVLAN within the same port. This allows seamless migration and co-existence with the two pro-tocols running independently side by side. All VLANs except the VLAN used as BackboneVLAN will be handled as Transport Ethernet SVLANs.

Fig. 57 MPLS Interface definition

In the case with an Attachment Circuit, then all VLANS that does not have a Forwarding Equiv-alence Class (FEC) defined will be handled as Transport Ethernet SVLANs.

7.6.9.1 MPLS-TP and Ethernet SVLAN Interworking

In order to deploy MPLS-TP in a production network, MPLS can be introduced either as anoverlay to the existing Ethernet transport or incremental to it as an evolutionary build-out.

a) Directly Connected

TD-EMXPII Rev F | 2012-04-10 58 (72)


Fig. 58 Directly Connected

Each node in the path has MPLS enabled and MPLS interfaces defined on all involvedinterfaces.

b) Connected over Backbone VLAN

Fig. 59 Connected over Backbone VLAN

There are intermediate nodes in the network that are switching the backbone VLAN.

c) Several MPLS interfaces on one physical interface

Fig. 60 Several MPLS interfaces on one physical interface

There are intermediate nodes in the network that are switching the backbone VLAN. This couldbe a whole network of EMXP/II

7.6.9.2 Quality of Service

MPLS-TP LSPs data plane Quality of Service capabilities are according to normal MPLS Dif-ferentiated Services (Diffserv) architecture [RFC3270]. The frames are classified on the TrafficClass [RFC5462] on the MPLS-TP LSPs.

Edge LSPs are defined with a specific Traffic Class. All traffic inside that LSP is considered asa Behavior Aggregate (BA) and is scheduled according to QOS configuration.

If there are more than one LSP service (working and protect) within one MPLS-TP Tunnel thenthese LSPs must have the same Traffic Class. Transit LSPs in LSRs have a Traffic Classmarking, but this is just for informational purpose. No remarking or checking of the traffic classon the LSP is performed in an LSR.

TD-EMXPII Rev F | 2012-04-10 59 (72)


7.6.10 MPLS-TP Service

A service runs between two Attachment circuits. The Forwarding Equivalence Class (FEC) as-sociates a Pseudowire (PW) with the service. The service is carried in that pseudowire.

The PW travels through the network in an MPLS-TP Tunnel. The MPLS-TP tunnel is mappedto at least one LSP, the active LSP.

Fig. 61 MPLS Service

7.7 Example MPLS-TP E-LINE serviceThe customer Acme requires a connection from headoffice in Nipissing to the office in Garcon.The service provider sets up a port based E-LINE service from a dedicated port 7-8 in the Ni-pissing Node to a port in the Garcon node.

Fig. 62 Acme E-LINE service

7.7.1 Pseudowire NIPI-GAR-ACME

A pseudowire (PW) needs to be defined to provide the service through the network. The PW isdefined with FEC port 7-8 onto the PW “NIPI-GAR-ACME”.

Fig. 63 NIPI-GAR-ACME PW

TD-EMXPII Rev F | 2012-04-10 60 (72)


The PW has some properties; specifically it needs to use a PW label. This label is internal tothe service provider network. This example uses labels 40215 from the platform PW labelspace to provide the service.

Fig. 64 PW NIPI-GAR-ACME labels

Normally the transport LSPs are already setup providing Traffic Engineered paths through thenetwork. So, to provide an E-LINE service for the customer Acme would only mean to setupthe pseudowire to provide the connectivity and a BW profile to define the service. In this casethe Acme service is initially a 500 Mbps service. The BW profile is defined on the associatedport.

Fig. 65 ACME Service Bandwidth Profile

7.7.2 MPLS-TP Tunnel NIPI-GAR-501–p3

The PW is carried from Nipissing to Garcon in a transport tunnel. In this example the PW runsin a MPLS-TP Tunnel. The tunnel used is tunnel 501 from Nipissing to Garcon which has thenecessary properties to provide the service and runs with Traffic Class 3.

TD-EMXPII Rev F | 2012-04-10 61 (72)


Fig. 66 PW NIPI-GAR-501-p3 tunnel

7.7.3 MPLS-TP LSP NIPI-MONT-3

The MPLS-TP LSP NIPI-MONT-3 tunnel is just a logical transport entity. The MPLS-TP tunnelis non-redundant so it is implemented using a single active MPLS-TP LSP through the net-work. In this case the LSP “NIPI-GAR-MONT-3” from Nipissing to Garcon via Montreal.

Fig. 67 MPLS-TP Tunnel NIPI-GAR-501-p3

That LSP is originating in the Nipissing node, and is using the interface towards the Montrealnode as egress interface.

Fig. 68 LSP State

The state of the tunnel is up because the supporting LSP state is up.

TD-EMXPII Rev F | 2012-04-10 62 (72)


Fig. 69 MPLS-TP LSP NIPI-GAR-MONT-3

The LSP supporting the tunnel runs from the Nipissing node to the Garcon node via the Mon-treal node. It is currently up because it is supervised using a BFD session. The priority is 1 indi-cating that it is a primary LSP. It is a LSP edge, and uses the in and outgoing label 2255. TheTraffic class for the LSP is 3.

7.7.4 MPLS-TP transit LSP NIPI-GAR-MONT-3

In the Montreal node the LSP only transits. It means that the Montreal node is used as an LSRfor the NIPI-GAR-MONT-3 LSP.

Fig. 70 NIPI-GAR-MONT-3 in Montreal

A transit LSP is defined with labels allocated. The labels have link local significance. The labelshave link local significance. The labels used as incoming/outgoing on the link towards Nipiss-ing is of course the same as the ones used as outgoing/incoming on the Nipissing node to-wards Montreal.

TD-EMXPII Rev F | 2012-04-10 63 (72)


Fig. 71 MPLS-TP LSP NIPI-GAR-MONT-3

7.7.5 MPLS-TP resources used for the Acme service

That gives the complete overview of the MPLS-TP resources used for the Acme E-LINEservice.

Fig. 72 Complete ACME service

7.7.6 Resilient MPLS-TP service

There are also services that require resiliency. Then a second LSP is associated with thetunnel.

TD-EMXPII Rev F | 2012-04-10 64 (72)


Fig. 73 Resilient MPLS-TP Tunnel

In the service provider example above, the NIPI-GAR-501-p3 tunnel is made resilient by asso-ciating a second LSP.

Fig. 74 Resilient MPLS-TP Tunnel NIPI-GAR-501-p3

This automatically adds line protection functionality without adding further configuration. AllPseudowires using this tunnel are then protected.

Fig. 75 MPLS-TP Tunnel NIPI-GAR-501-p3 protection

7.7.7 MPLS-TP OAM

In the example, MPLS-TP OAM is enabled on the MPLS-TP LSPs. This adds extra securityand verification.

TD-EMXPII Rev F | 2012-04-10 65 (72)


Fig. 76 MPLS-TP LSP OAM

Enabling BFD sessions on LSPs is an option when creating LSP. The session is created withthe selected BFD template. In the example the MEP ID data such as Global ID, Node ID, Tun-nel ID and LSP ID are defined so connection verification is enabled.

TD-EMXPII Rev F | 2012-04-10 66 (72)

MECHANICAL LAYOUT

8 Mechanical Layout

Fig. 77 GBE22–EMXP 10/II

Any interface can be used as client or line interfaces.

TD-EMXPII Rev F | 2012-04-10 67 (72)

MECHANICAL LAYOUT

8.1 SFP InterfacesThe unit has 1,10 or 22 SFP interfaces depending on model. The SFP-port are used for optical100/1000Base-X or electrical 10/100/1000Base-Tsignals of different flavors.

The rate can be configured manually or automatically set via autonegotiation.

Fig. 78 SFP Interfaces

Table 4 LED Indicators SFP

LED Sp Speed Indicator Tx Transmit Indicator Rx Activity Indicator

Yellow 100 Mb/s Laser is off Link is down

Green 1000 Mb/s Laser is on Link is up

Flashing Green Activity

TD-EMXPII Rev F | 2012-04-10 68 (72)

MECHANICAL LAYOUT

8.2 XFP InterfacesThe units have 2 or 8 XFP-based line interfaces for 10GBase-X signals.

Fig. 79 XFP Interface

Two LED indicators are used per Line port.

Table 5 LED Indicators XFP

LED Tx Transmit Indicator Rx Activity Indicator

No Light Laser is off Link is down

Green Laser is on Link is up

Flashing Green Activity

TD-EMXPII Rev F | 2012-04-10 69 (72)

TECHNICAL DATA

9 Technical DataTable 6 Technical Data

Parameter Value10G interfaces (XFP) UncoloredMultimode and Singlemode.

CWDM up to 8 channels,DWDM up to 40 channels or Tunable XFP up to 80 channels.

GE/FE interfaces(SFP)

UncoloredMultimode and Singlemode.,CWDM up to 16 channels or DWDM up to 40 channelsSingle-strand fiber solution.Electrical 10/100/1000BASE-T

Resilience ITU-T G.8032 Ethernet Ring ProtectionIEEE 802.3ad Link Aggregation

Ethernet Services E-LINE (EPL and EVPL),E-LAN (EP-LAN and EVP-LAN)E-TREE (EP-Tree)UNI / Service Multiplexed UNI and NNI portsMEF 9+14 Certification

Quality of Service Policing using TrTCM Bandwidth profilesStraight CFI or COS, alt 8P0D, 7P1D, 6P2D and 5P3D Color coding8 Strict/WRR priority queues per port (in any mix)Three drop precedence colors,Min and Max Shaping (bandwidth guarantee)Color aware (drop precedence) WREDFlexible classification, e.g. based on DSCP, CoS, port and inner/outer VLAN

Performance 1.9 μs delay for all packet sizes using RFC1242 store and forwardmetricFrame Delay variation below 0.05 μsFull wirespeed forwarding on all port on all loads and with all traffic types

Performance Monitor-ing & OAM

IEEE 802.1ag Continuity CheckIEEE 802.1ag LoopbackY.1731 ME/MEG/MEP. Both up and down MEP.Port MirroringPort LoopbackG.826 Performance MonitoringManagement VLAN for inband managementPort isolation using Private VLAN technique

Synchronous Ethernet ITU-T G.8262 Ethernet Equipment Slave Clock (EEC)ITU-T G.8264 Ethernet Synchronization Messaging ChannelITU-T G.781 Synchronization Status Messages (SSM)

Switching Selectable learning enabled per VLANIndependent learning per VLAN32K MAC-addresses, 4.094 VLAN IDsMulticast and broadcast Storm ControlIEEE 802.1ad Q-in-Q SVLANFlexible tag handling (pop, push, swap, pop-swap), P-bit set or transferJumbo Frames upto >10kBP-bit set or transfer

Multicast RFC4607 Source-Specific Multicast for IPRFC4541 IGMP SnoopingRFC2236 IGMPv2RFC3376 IGMPv3

MPLS-TP RFC3985 PseudoWire Emulation Edge-to-Edge (PWE3) ArchitectureRFC4448 Encapsulation for Transport of Ethernet over MPLS NetworksRFC5921 A Framework for MPLS in Transport NetworksRFC5884 Bidirectional ForwardingDetection (BFD) for MPLS LSPsRFC6378MPLS Transport Profile (MPLS-TP) Linear Protection

Power Consumtion Max 30W (including optics) for EMXPII 10Max 45W (including optics) for EMXPII 22Max 55W (including optics) for EMXPII 40Max 65W (including optics) for EMXPII 80

TD-EMXPII Rev F | 2012-04-10 70 (72)

REFERENCES

10 ReferencesThis section lists the standards and references used within this Technical Description.

[IEEE 802.1ad-2005]

Provider Bridges, May 2006

[IEEE 802.1ag] Connectivity Fault Management, December 2007

[IEEE 802.3x] Specification for 802.3 Full Duplex Operation

[IEEE 802.3-2008]

Carrier Sense Multiple Access with Collision Detection (CMSA/CD) AccessMethod and Physical Layer Specifications, Dec 2008

[ITU-T G.781] Synchronization layer functions

[ITU-T G.823] The control of jitter and wander within digital networks which are based onthe 2048 kbit/s hierarchy, March 2000.

[ITU-T G.826] End-to-end error performance parameters and objectives for international,constant bit rate digital paths and connections

[ITU-T G.8032] Ethernet ring protection switching, G.8032/Y.1344, June 2008

[G.8262] Timing characteristics of synchronous Ethernet equipment slave clock(EEC), G.8262/Y.1362, Aug 2007

[ITU-T G.8264] Distribution of timing through packet networks

[MEF10.2] Ethernet Services Attributes Phase 2, Oct 2009

[MEF 13] User Network Interface (UNI) Type 1 Implementation Agreement

[MEF 17] Service OAM Framework and Requirements

[MPLS Forum12.0.1]

Multi-Service Interworking – Ethernet over MPLS

[RFC2698] A Two Rate Three Color Marker

[RFC2236] Internet Group Management Protocol, Version 2

[RFC3270] Multi-Protocol Label Switching (MPLS) Support of Differentiated Services

[RFC3376] Internet Group Management Protocol, Version 3

[RFC3985] Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture

[RFC4448] Encapsulation for Transport of Ethernet over MPLS Networks

[RFC4541] Considerations for Internet Group Management Protocol (IGMP) and Multi-cast Listener Discovery (MLD) Snooping Switches

[RFC4647] Source-Specific Multicast for IP

[RFC5462] Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Re-named to "Traffic Class" Field

[RFC5880] Bidirectional Forwarding Detection (BFD)

TD-EMXPII Rev F | 2012-04-10 71 (72)

http://tools.ietf.org/html/rfc2698










REFERENCES

[RFC5884] Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths(LSPs)

[RFC5586] MPLS Generic Associated Channel

[RFC5921] A Framework for MPLS in Transport Networks

[RFC6370] MPLS Transport Profile (MPLS-TP) Identifiers

[RFC6371] Operations, Administration, and Maintenance Framework for MPLS-BasedTransport Networks

[RFC6372] MPLS Transport Profile (MPLS-TP) Survivability Framework

[RFC6378] MPLS Transport Profile (MPLS-TP) Linear Protection

[RFC6428] Proactive Connectivity Verification, Continuity Check, and Remote DefectIndication for the MPLS Transport Profile

[Y.1731] OAM functions and mechanisms for Ethernet based networks, Feb 2008

TRM-2010:0043 Technical Update TM-Series EMXP-II Latency Test Report, Rev A, 2010-11-16

TD-EMXPII Rev F | 2012-04-10 72 (72)









Ethernet Muxponders

Documents

Transcript of Ethernet Muxponders