SlideShare a Scribd company logo
1 of 168
Download to read offline
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
1
Content
1 LAN and VLAN: some considerations 3
1.1 Definitions 4
1.2 Domains in a traditional LAN 5
1.3 Domains in a VLAN 9
1.4 Traffic separation by VLAN 12
1.5 Tagging 13
1.6 VLAN Aware / Unaware 21
1.7 Links Types 22
1.8 Q-in-Q 25
1.9 Spanning Tree Protocol (802.1d) 29
1.10 Rapid Spanning Tree Protocol RSTP (802.1w) 32
1.11 Multiple Spanning Tree Protocol MSTP (802.1s) 33
2 Carrier Ethernet: Some Concepts 39
2.1 What is Carrier Ethernet 39
2.2 MEF: Metro Ethernet Forum 40
2.3 Cooperation with Other Standard Bodies 42
2.4 IEEE: Institute of Electrical and Electronics Engineers 42
2.5 IETF: The Internet Engineering Task Force 42
2.6 ITU: International Telecommunication Union Telecommunication
Standardization Sector 43
3 Carrier Ethernet Terminology 45
3.1 Basic Components 46
3.2 Carrier Ethernet Service Types 63
3.3 Circuit Emulation Services over Packet (CESoP) 64
3.4 FlexiPacket EVC and Services 71
4 Quality of Service in the HUB 75
4.1 QoS Mechanism 76
4.2 Classifier and Packet Marker 79
4.3 Policer 83
General Topics
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
2
4.4 Buffer Manager: Congestion Avoidance 86
4.5 Queue Scheduler 89
5 Quality of service in the FlexiPacket Radio Rel.1.3 EP1 99
5.1 Quality of Service Mechanism 99
5.2 Classification 100
5.3 Egress Scheduling 102
6 Quality of service in the FlexiPacket MultiRadio Rel 2.1 103
6.1 Quality of Service Mechanism 103
6.2 QoS Classification Criteria 104
6.3 Egress Scheduling 104
7 Ethernet OAM 105
7.1 OAM Definition 106
7.2 OAM Layers 107
7.3 Ethernet Link Fault Management OAM (EFM OAM) 802.3ah 111
7.4 Connectivity Fault Management (CFM) – 802.1ag 112
7.5 Performance Monitoring - ITU-T Y.1731 120
7.6 E2E OAM – Ethernet AIS 124
7.7 Remote Defect Indication (RDI) 125
8 Network Synchronization 127
8.1 Introduction 128
8.2 Physical Layer Synchronization – Synchronous Ethernet (SyncE) 129
8.3 Timing-over-Packet (ToP) IEEE1588 v2 (official Title: Precision Time
Protocol) 136
8.4 IEEE-1588 and Synchronous Ethernet 146
8.5 FlexiPacket Synchronization 148
9 CESoP Clock Recovery 151
9.1 Clock Recovery 152
9.2 CESoP with Differential Clock Recovery 153
10 Digital Radio Relay Signals 155
10.1 Quadrant Amplitude Modulation (QAM) 156
10.2 Filtered Spectrum 160
10.3 Adaptive Modulation 166
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
3
1 LAN and VLAN: some considerations
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
4
1.1 Definitions
A LAN or Local Area Network is a computer network (or data communications
network) which is confined in a limited geographical location.
A Virtual (or logical) LAN is a local area network with a definition that maps
workstations/PCs on some other basis than geographic location (for example, by
department, type of user or primary application)
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
5
1.2 Domains in a traditional LAN
In a traditional Ethernet LAN, stations connected to the same media, share a domain.
In this domain, every station hears broadcast frames transmitted by every other
station.
As the number of stations grows, contention and broadcast traffic increase a lot.
At some point, the Ethernet becomes saturated.
To operate efficiently, the LAN must be divided into smaller pieces.
In a traditional LAN, stations are connected to each other by means of HUBS or
REPEATERS.
HUB HUB
One collision Domain
One Broadcast Domain
Fig. 1 Domains in a traditional LAN (1)
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
6
A BRIDGE (or a L2 SWITCH) is able to divide one collision domain in different
collision domains.
HUB HUB
Two collision Domains
One Broadcast Domain
BRIDGE
Fig. 2 Domains in a traditional LAN (2)
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
7
A BRIDGE (or a L2 SWITCH) do not forward collisions, but allows broadcast and
multicast passing through.
Broadcast domain refers to a part of network where a single broadcast packet is
transmitted to all segments of the network (i.e. ARP request, NETBIOS name
request).
This type of traffic, affects the whole network because each device receiving a
broadcast frame must analyze it.
If broadcast frames increases in frequency, available bandwidth decrease up to be
exhaust (BROADCAST STORM).
SWITCH = MULTIPORT BRIDGE
L2 SWITCH
Fig. 3 Domains in a traditional LAN (3)
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
8
A ROUTER may be used to prevent Broadcast and Multicast from traveling through
the network because it is able to segment a LAN in different Broadcast domains.
HUB HUB
Two collision Domains
Two Broadcast Domain
ROUTER
Fig. 4 Domains in a traditional LAN
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
9
1.3 Domains in a VLAN
VLANs allow a network manager to logically segment a LAN into different broadcast
domains without using routers.
Bridging software is used to define which workstations are to be included in the
broadcast domain.
VLAN 2 Broadcast
Damain
VLAN 2 Broadcast
Damain
VLAN 1 Broadcast
Domain
VLAN 1 Broadcast
Domain
L2 SWITCH L2 SWITCH
Fig. 5 Domains in a VLAN (1)
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
10
ROUTERS are necessary only to make possible communication between different
VLANs.
VLAN IS A LOGICALLY DEFINED BROADCAST DOMAIN.
VLAN 2 Broadcast
Damain
VLAN 2 Broadcast
Damain
VLAN 1 Broadcast
Domain
VLAN 1 Broadcast
Domain
L2 SWITCH L2 SWITCH
ROUTER
Fig. 6 Domains in a VLAN (2)
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
11
The advantages of VLANs as regards to traditional LANs are shown in Fig. 7.
Periodically, sensitive data may be
broadcast on a network. Placing only those
users who can have access to have access to
that data on a VLAN can reduce the
chances of an outsider gaining access to the
data
SECURITY
Routers are only used to interconnect
different broadcast domains
REDUCED COSTS
Simply moves, adds and changesSIMPLIFIED
ADMINISTRATION
Independent from the physical wiringVIRTUAL WORKGROUPS
Better control of broadcastPERFORMANCE
Fig. 7 Domains in a VLAN (3)
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
12
1.4 Traffic separation by VLAN
With VLANs it is possible to separate different logical networks on one physical
infrastructure supporting the traffic separation.
Figure Fig. 8 shows a Traffic Separation Example by VLAN.
RNC
Ethernet Network
Flexi BTS Nr.1
Flexi BTS Nr.2
VLAN1 -> Voice from Flexi BTS Nr.1
to RNC
Traffic over same physical port
separated by VLAN.
VLAN2 -> Data from Flexi BTS Nr.1
to RNC
VLAN4 -> Data from Flexi BTS Nr.1
to RNC
VLAN3 -> Voice from Flexi BTS Nr.2
to RNC
Fig. 8 Traffic separation by VLAN
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
13
1.5 Tagging
Tagging is a process used to identify the VLAN originating.
The VLAN tagging scheme in 802.1q results in four bytes of information being added
to the frame following the source address and preceding the type/length field.
This increases the maximum frame size in Ethernet to 1522 bytes.
Fig. 9 reports a IEEE 802.3 untagged frame
Fig. 10and Fig. 11 explain the TAG fields.
MAC DA
6 bytes
Payload
46-1500 bytes
FCS
4 bytes
Basic IEEE 802.3 Ethernet Frame:
minimum length 64 bytes, maximum length 1518 bytes
Destination & Source MAC Addresses:
The Destination MAC Address field identifies the station or stations that are to receive the
frame.
The Source MAC Address identifies the station that originated the frame. A Destination
Address may be a unicast destined for a single station, or a "multicast address" destined for a
group of stations. A Destination Address of all 1 bits refers to all stations on the LAN and is
called a "broadcast address".
Length/Type:
If the value of this field is less than or equal to 1500, then the Length/Type field indicates
the number of bytes in the Payload field. If the value of this field is greater than or equal to
1536, then the Length/Type field indicates protocol type.
Payload (MAC Client Data):
This field contains the data transferred from the source station to the destination station or
stations.
Frame Check Sequence:
This field contains a 4-byte cyclical redundancy check (CRC) value used for error checking.
MAC SA
6 bytes
Length/Type
2 bytes
VLAN tags may be added here
Preamble
+SD
8 bytes
Interframe
Gap
12 bytes
64-1518 bytes
Fig. 9 IEEE 802.3 Untagged Frame
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
14
C
F
I
16 bits
TAG Protocol Identifier TPID
0x8100
1bit 12 bits3bits
Priority VLAN ID
TCI
Tag Control Identifier
TPID
TAG Protocol Identifier
2 bytes2 bytes
4 bytes
IEEE 802.3 Frame without VLAN Tag Header
IEEE 802.3 with 802.1Q 4-Byte VLAN Tag Header
User priority (Priority Code
Point PCP)
CFI (Canonical
format identifier)
VLAN ID <= 4094)
4 bytes are added in the Ethernet frame between the MAC Source Address and
the Type-Field.
802.1Q – VLAN (single tagged)
MAC DA
6 bytes
Payload
48-1500 bytes
FCS
4 bytes
MAC SA
6 bytes
Length/Type
2 bytes
Preamble
+SD
8 bytes
Interframe
Gap
12 bytes
Payload
48-1500 bytes
FCS
4 bytes
Length/Type
2 bytes
Interframe
Gap
12 bytes
MAC DA
6 bytes
MAC SA
6 bytes
Preamble
+SD
8 bytes
TPID TCI
Fig. 10 802.1Q Single Tagged Frame (1)
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
15
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Is used to uniquely identify the VLAN to which the
frame belongs. There can be a maximum of 212 -1
VLANs. Zero is used to indicate no VLAN ID
Vlan IDentifier
Always 0 if Ethernet.It is used to make
compatibility between Ethernet and Token Ring
Canonical Format Indicator
It allows priority information to be encoded in the
frame. Eight levels of priority are allowed
Priority Code Point (PCP)
It Indicates that it will follow a 802.1q TAG and
not the payload; the Default TPID value in IEEE
802.1Q, is 0x8100
Tag Protocol IDentifier
DESCRIPTIONTC FIELD
Fig. 11 802.1Q Single Tagged Frame (2)
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
16
1.5.1 Class of Service (CoS) IEEE 802.1p
The IEEE 802.1p provides a standard and interoperable way to set the priority bits in
a frame’s header and to map these settings to TRAFFIC CLASSES.
There are 8 TRAFFIC CLASSES (3 Bits) according to the table reported in Fig. 12.
000BEBEST EFFORT
001BKBACKGROUND
010RRESERVRD FOR FUTURE USE
011EEEXCELLENT EFFORT TRAFFIC
100CLCONTROLLED LOAD TRAFFIC
101VIVIDEO TRAFFIC
110VOVOICE TRAFFIC
111NCNETWORK CONTROL TRAFFIC
Fig. 12 Quality Of Service IEEE 802.1p (1)
WARNING
Of course, network operators may choose to implement traffic differentiation
on a per VLAN-ID basis rather than using the three CoS bits.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
17
The TRAFFIC CLASSES are assigned to separate queues with different priorities.
Traffic classes
queues
map to
outgoing
Priority bits
Fig. 13 Quality Of Service IEEE 802.1p (2)
If a switch provides 8 queues for the 8 priorities settings, each queue will store
frames with a specific priority setting to provide complete differentiated services.
Fig. 14 Switch with 8 queues; each priority has one queue
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
18
FlexiPacket First Mile 200, HUB 800 and FlexiPacket MultiRadio have 8 queues and
the association between PCP and Priority Queue is reported in Fig. 15.
FPFM-200/HUB-
800/FPMR Priority
Queue
PCP
Fig. 15 FPFM-200/HUB 800/FPMR PCP - Priority queues association
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
19
To minimize costs, however, fewer queues may be provided in such switches.
Frames from several priority settings may be stored together in one queue.
Fig. 16 Switch with less than 8 queues; more than one priority in one queue
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
20
When 4 queues are available, like in the FlexiPacket ODU, the 8 PCPcodes could be
associated to four priority values as reported in Fig. 17 (FlexiPacket ODU default).
37
26
25
24
13
12
01
00
Queue Priority
Value
PCP
Fig. 17 FlexiPacket ODU Priority Code Point Configuration
When 5 queues are available, like in FlexiPacket HUB 2200/1200, the 8 PCP codes
could be associated to five priority values as reported in Fig. 16 (HUB 1200/2200
configuration).
47
36
25
24
13
12
01
00
Queue Priority
Value
PCP
Fig. 18 FlexiPacket HUB (2200/1200) Priority Code Point Configuration
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
21
1.6 VLAN Aware / Unaware
VLAN AWARE
If the data is to go to a device that knows about VLAN implementation (VLAN Aware),
the VLAN identifier is added to the data.
VLAN UNAWARE
If it is to go to a device that has no knowledge of VLAN implementation (VLAN
Unaware), the BRIDGE sends the data without the VLAN identifier.
TAG
added/removed
TAGTAG
FrameFrame
TAGTAG
FrameFrame
TAGTAG
FrameFrame
FrameFrame
FrameFrame
FrameFrameFrameFrameFrameFrame
FrameFrame
TAG
added/removed
L2-Switch L2-Switch
VLAN aware
Bridge/L2-Switch
VLAN aware
VLAN unaware stations
Bridge/L2-Switch
Fig. 19 VLAN Aware/Unaware
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
22
1.7 Links Types
Devices on a VLAN can be connected in three ways based on whether the connected
devices are VLAN Aware or VLAN Unaware as reported in Fig. 20, Fig. 21, Fig. 22.
Recall that a VLAN aware device is one which understands VLAN memberships (i.e.
which users belong to a VLAN) and VLAN formats.
This is a combination of the previous two links. This is a link where
both VLAN aware and VLAN Unaware devices are attached.
A hybrid link can have both tagged and untagged frames, but all the
frames for a specific VLAN must be either tagged or untagged.
Hybrid Link
An access link connects a VLAN Unaware device to the port of a VLAN
Aware Bridge.
Access Link
All the devices connected to a trunk link, including workstations, must
be VLAN Aware.
All frames on a trunk link must have a special header attached. These
special frames are called TAGGED FRAMES.
Trunk Link
DESCRIPTIONLINK TYPE
Fig. 20 Link Types
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
23
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L2-Switch
L2-Switch
Trunk Link
Trunk Link
VLAN-aware Workstation
VLAN-aware
Bridge/L2-Switch
VLAN-aware
Bridge/L2-Switch
Fig. 21 Trunk Link
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
24
L2-Switch
Access Link
VLAN-unaware Device
VLAN-aware
Bridge/L2-Switch
Fig. 22 Access Link
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
25
1.8 Q-in-Q
In the VLAN tag field defined in IEEE 802.1Q, only 12 bits are used for VLAN IDs, so
a device can support a maximum of 4,094 VLANs.
In actual applications, however, a large number of VLAN are required to isolate
users, especially in metropolitan area networks, and 4,094 VLANs are far from
satisfying such requirements.
The so called Q-in-Q (IEEE 802.1ad) feature enables the encapsulation of double
VLAN tags within an Ethernet frame, with the inner VLAN tag being the customer
network VLAN tag while the outer one being the VLAN tag assigned by the service
provider to the customer.
In the backbone network of the service provider (the public network), frames are
forwarded based on the outer VLAN tag only, while the customer network VLAN tag
is shielded during data transmission.
The Q-in-Q feature enables a device to support up to 4,094 x 4,094 VLANs.
DA SA
DA SA
DA SA
LEN/
Etype Data FCS
TPID TAG
LEN/
Etype Data FCS
TPID TAG
LEN/
Etype Data FCSTPID TAG
Untagged Ethernet Frame
Service Provider
Tagging
Customer Tagging
6 6 2 446 to 1500
2 2
2 2
Bytes
Single Tagged Ethernet Frame
Double Tagged Ethernet Frame
Fig. 23 Untagged, Single Tagged and Double Tagged Ethernet Frames
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
26
Double TAG VLAN Tag Control Identifier (TCI) is reported in Fig. 24
DA SA TPID TAG
LEN/
Etype Data FCSTPID TCI
2 2
Double Tagged Ethernet Frame
User Priority
Priority Code Point
DEI
S-VID
Service V-LAN Identifier
3 bits 1 bit 12 bits
1 bit Drop Eligible Indicator → drop first, if congestion occurs
Fig. 24 Double TAG VLAN Tag Control Identifier
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
27
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Double Tag Example
S-VLAN 2
C-VLAN 2
A
D
C
E
B
2
3
4
S-VLAN 2
C-VLAN 2
Swap outer with 4 and forward
to D- port 2
221
Forwarding DecisionVLAN Outer
Tag
VLAN Inner
Tag
A-Port
S-VLAN 2
C-VLAN 2
x
1S-VLAN 4
C-VLAN 2
1
2
S= Service Provider
C= Customer
Fig. 25 Double TAG Example
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
28
1.8.1 Q in Q TPID
The QinQ frame contains the modified tag protocol identifier (TPID) value of VLAN
Tags. By default, the VLAN tag uses the TPID field to identify the protocol type of the
tag. The value of this field, as defined in IEEE 802.1Q, is 0x8100.
The device determines whether a received frame carries a service provider VLAN tag
or a customer VLAN tag by checking the corresponding TPID value.
After receiving a frame, the device compares the configured TPID value with the
value of the TPID field in the frame.
If the two match, the frame carries the corresponding VLAN tag. For example, if a
frame carries VLAN tags with the TPID values of 0x88a8 and 0x8100, respectively,
while the configured TPID value of the service provider VLAN tag is 0x88a8 and that
of the VLAN tag for a customer network is 0x8200, the device considers that the
frame carries only the service provider VLAN tag but not the customer VLAN tag.
In addition, the systems of different vendors might set the TPID of the outer VLAN tag
of QinQ frames to different values.
For compatibility with these systems, you can modify the TPID value so that the QinQ
frames, when sent to the public network, carry the TPID value identical to the value of
a particular vendor to allow interoperability with the devices of that vendor.
The TPID in an Ethernet frame has the same position with the protocol type field in a
frame without a VLAN tag.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
29
1.9 Spanning Tree Protocol (802.1d)
In order to increase the availability may be useful to introduce redundancy.
In presence of simultaneous alternative paths, copies of frames are created
producing the so called LOOPS. In order to avoid loops, a SPANNING TREE
algorithm must be implemented to disable some bridge interfaces.
Spanning Tree Protocol (STP) is a link manager protocol that provides path
redundancy while preventing loops in the network.
STP algorithm creates a tree topology, and loop free path from the root to all of the
nodes in the LAN.
1.9.1 Spanning Tree Root bridge selection
The bridges exchange Configuration Bridge Protocol Data Units (BPDU’s) in order to
learn the topology of the network.
A root bridge is selected according to MAC or priority.
A lowest cost path to the root is chosen, and redundant links are blocked.
Root Bridge
= blocked links
Fig. 26
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
30
In case of link failure, BPDU’s are again exchanged in the network to notify tree of
the topology change.
Redundant routes are enabled.
Root Bridge
Fig. 27
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
31
1.9.2 Spanning Tree Port roles
Spanning Tree port roles are:
• Root port: pointing towards the root bridge.
• Designated port: active ports that aren’t root ports.
• Alternate port: one side of a blocked link (the other side is designated).
Root Bridge
R
R
R
R D
D
D
D
D
D
A
A
Fig. 28
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
32
1.9.3 Spanning Tree Port states
Spanning Tree Port states are:
• Forwarding: all frames are forwarded on the port.
• Discarding: all user data is dropped. BPDUs are forwarded.
• Learning: Port is still inactive, but learns MAC addresses.
Root BridgePort role: Root
Port state: Forwarding
Port role: Root
Port state: Forwarding
Port role: Alternate
Port state: Discarding
Fig. 29
1.10 Rapid Spanning Tree Protocol RSTP (802.1w)
Regular STP (802.1d) provides very slow failure recovery time: 30-60 sec.
Thus the STP mechanism was improved, and a new protocol was published: RSTP
(802.1w).
RSTP offers ~1 sec failure recovery time.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
33
1.11 Multiple Spanning Tree Protocol MSTP (802.1s)
The 802.1D and 802.1w spanning tree protocols operate without regard to a
network’s VLAN configuration, and maintain one common spanning tree throughout a
bridged network.
These protocols map one loop-free, logical topology on a given physical topology.
In a VLAN environment, the problem could be put in evidence considering the Fig.
30.
The figure shows a network of two switches with two configured VLANs.
If the switches are running STP or RSTP, all the links for VLAN 2 would be blocked.
This is because both STP and RSTP support only a single spanning tree for the
whole network and block the redundant links.
The above situation can be rectified by using MSTP.
The 802.1s Multiple Spanning Tree protocol (MSTP) uses VLANs to create multiple
spanning trees in a network, which significantly improves network resource utilization
while maintaining a loop-free environment.
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
VLAN 1 VLAN 2
X
X
Switch 1
(root Bridge)
Switch 2
Fig. 30 Example of two switches with two configured VLANs
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
34
1.11.1 Multiple spanning tree concepts
MST Instance (MSTI)
MSTP enables the grouping and mapping of VLANs to different spanning tree
instances each with a different root bridge.
A MST Instance (MSTI) is a particular set of VLANs that are all using the same
spanning tree.
Spanning tree of MSTI= 1 containing
vlans 1, 2, 3, 4
Spanning tree of MSTI= 2 containing
vlans 5, 6, 7, 8
Spanning tree of MSTI= 3 containing
vlans 9, 10, 11, 12
Same Physical connection
Root
Bridge
Root
Bridge
Root
Bridge
Fig. 31 Different spanning trees created by different MSTIs on the same physical layout
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
35
Regions
A MST region is a set of interconnected switches that all have the same values for
the following parameters:
• MST configuration name: the name of the MST region
• Revision level: the revision number of configuration (The revision level is an
arbitrary number that you assign to a MST region. It can be used to keep track of
the number of times that MST configuration has been updated for the network. If
the revision level is not set explicitly by the command, the default revision level
value will be 0.
• Configuration Digest: the mapping of which VLANs are mapped to which MST
instances
Each MST instance created is identified by an MSTI number. This number is locally
significant within the MST region. Therefore, a MSTI will not span across MST
regions.
MSTI1
MSTI2
MSTI3
MSTI4
MSTI2
MSTI4
The MSTI2 in Region 1 is unrelated to the MSTI2 in Region 3 and the MSTI4 in Region 2 is unrelated to
the MSTI4 in Region 3.
Region 1
Region 2
Region 3
Same Physical
Connection
Fig. 32 MSTIs in different regions
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
36
Common and Internal Spanning Tree (CIST)
The CIST is the default spanning tree instance of MSTP, i.e. all VLANs that are not
members of particular MSTIs are members of the CIST.
Also, an individual MST region can be regarded a single virtual bridge by other MST
regions.
The spanning tree that runs between regions is the CIST. The CIST is also the
spanning tree that runs between MST regions and Single Spanning Tree (SST)
entities.
So, in Fig. 33, the STP that is running between the regions, and to the Single
Spanning Tree bridges, is the CIST.
MSTP
Region 1
MSTP
Region 2
MSTP
Region 3
Switch non MSTP capable
Switch non MSTP capable
Switch non MSTP capable
= CIST
Fig. 33 Common and Internal Spanning Tree (CIST)
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
37
Returning now to the example of Fig. 30, the problem can be solved mapping
VLAN 1 and VLAN 2 to different MSTIs.
The MSTP configures separate spanning tree for VLANs 1 and 2 and blocks the
redundant links for VLAN 2.
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
VLAN 1 VLAN 2
X
Switch 1
(root Bridge)
Switch 2
MSTI1= VLAN1
MSTI2= VLAN2
Fig. 34 Active topologies for MSTI 1 and MSTI 2
1.11.2 Load Balancing
We have seen that with MSTP, each spanning tree instance can include one or more
VLANs and applies a separate, per-instance forwarding topology.
This means that where a port belongs to multiple VLANs, it may be dynamically
blocked in one spanning tree instance, but forwarding in another instance.
This achieves load-balancing across the network while keeping the switch’s CPU
load at a moderate level (by aggregating multiple VLANs in a single spanning tree
instance).
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
38
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
39
2 Carrier Ethernet: Some Concepts
2.1 What is Carrier Ethernet
Carrier Ethernet is the use of high-bandwidth Ethernet technology for Internet access
and for communication among business, academic and government local area
networks (LANs).
The use of Carrier Ethernet technology within a metropolitan area network (MAN) is
known as Metro Ethernet.
Fig. 35 What's Carrier Ethernet
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
40
2.2 MEF: Metro Ethernet Forum
The Metro Ethernet Forum (MEF) is a global industry alliance comprising more than
145 organizations.
Nokia Siemens Network is part of the MEF
The MEF develops technical specifications and implementation agreements to
promote interoperability and deployment of Carrier Ethernet worldwide.
Fig. 36 MEF
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
41
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 37 Nokia Siemens Networks is part of the MEF
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
42
2.3 Cooperation with Other Standard Bodies
The goal of the MEF is to create Implementation Agreements (IAs) that leverage
existing standards defined by other organizations such as IEEE, ITU-T and IETF
rather than creating competing standards. Where necessary, the MEF will:
• make recommendations to existing standards bodies. MEF has liaisons to IEEE
and ITU-T. MEF also works closely with IETF.
• As a last resort, create standards that are not being developed by other standards
bodies.
2.4 IEEE: Institute of Electrical and Electronics
Engineers
The IEEE, a non- profit organization, is the world's leading professional association
for the advancement of technology.
The IEEE is a leading developer of international standards that underpin many of
today's telecommunications, information technology and power generation products
and services.
2.5 IETF: The Internet Engineering Task Force
The IETF is the principal body engaged in development of new Internet standard
specifications.
It is a large open international community of network designers, operators, vendors
and researchers concerned with the evolution of the Internet Architecture and the
smooth operation of the Internet.
Its mission includes:
• identifying and proposing solutions to operational and technical problems in the
Internet;
• specifying the development or usage of protocols and near-term architecture to
solve such technical problems for the Internet;
• making recommendations to the Internet Engineers Steering Group (IESG)
regarding the standardization of protocols and protocol usage in the Internet;
• Providing a forum for the exchange of information within the Internet community
between vendors, users, researchers, agency contractors and network managers.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
43
2.6 ITU: International Telecommunication Union
Telecommunication Standardization Sector
The ITU is an international organization under the United Nations within which
government and the private sector coordinate global telecom networks and services.
ITU-T: Telecommunication Standardization Sector
The main products of ITU-T are the Recommendations. At present, more than 3,000
Recommendations (Standards) are in force.
Recommendations are standards that define how telecommunication networks
operate and interwork.
ITU-T Recommendations are non-binding, however they are generally complied with
due to their high quality and because they guarantee the interconnectivity of networks
and enable telecommunication services to be provided on a worldwide scale.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
44
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
45
3 Carrier Ethernet Terminology
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
46
3.1 Basic Components
UNI, EVC and NNI are the Fundamental Constructs of an Ethernet Service
3.1.1 The User Network Interface (UNI)
The UNI is the physical interface or port that is the demarcation between the
customer and the service provider.
The UNI is always provided by the Service Provider
The UNI in a Carrier Ethernet Network is a physical Ethernet Interface at operating
speeds 10Mbs, 100Mbps, 1Gbps or 10Gbps.
CE: Customer Equipment, UNI: User Network Interface. MEF certified Carrier Ethernet
products
Carrier Ethernet
Network
UNIUNI
CECE
Fig. 38 User Network Interface
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
47
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Network to Network Interface (NNI)
NNI is the demarcation between carrier Ethernet networks operated by one or more
carriers
UNI: User Network Interface,
UNI-C: UNI-customer side,
UNI-N network side
NNI: Network to Network Interface,
E-NNI: External NNI;
I-NNI Internal NNI
Service Provider 1 Carrier Ethernet
Network
CECE
UNIUNI
Subscriber
Site
ETH
UNI-C
ETH
UNI-C
ETH
UNI-N
ETH
UNI-N
ETH
UNI-N
ETH
UNI-N
ETH
E-NNI
ETH
E-NNI
ETH
UNI-C
ETH
UNI-C
UNIUNI
CECE
I-NNII-NNI E-NNIE-NNI
Service Provider 2
I-NNII-NNI
ETH
E-NNI
ETH
E-NNI
Subscriber
Site
Fig. 39 UNI and NNI Interfaces
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
48
3.1.3 FlexiPacket UNI / NNI ports
In the FlexiPacket Indoor Unit, each Ethernet port (both copper and fiber) can be
configured either as UNI (User to Network Interface) or NNI (Network to Network
Interface). As default, all ports are configured as NNI.
Fig. 40 illustrates a generic network scenario in which UNI and NNI interfaces are
highlighted.
IDU -- 1 NNIUNI3rd
party
IDU - N
3rd
party
NNI
network UNI
Access to Network
Network to AccessNetwork to Network
End-to-end connection
Fig. 40 User to Network and Network to Network Interfaces
In order to provide end-to-end connections, mapping criteria are required at each
interface boundary:
Incoming packet arriving at the UNI port is mapped to a specific connection, which is
identified by VLAN.
The mapping operation is done once per packet in the network.
After packet is mapped and tagged (VLAN), it already has its association to the
service, and on the next hopes (NNI port) mapping is not needed.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
49
FlexiPacket Radio ODUs are connected to A2200/A1200/First Mile IDUs by either
UNI or NNI ports, as illustrated in Fig. 41, Fig. 42 and Fig. 43.
IDU
NNI
3rd
party
IDU
3rd
party
IDU
3rd
party
NNI NNI
-
NNI
A2200/1200
network
NNI
UNI UNI UNI
Fig. 41 FlexiPacket Radio –IDU connections by UNI/NNI ports (1)
3rd
party
FPR
IDU
3rd
party
UNI
UNI NNI
FPRFPR
Fig. 42 FlexiPacket Radio –IDU connections by UNI/NNI ports (2)
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
50
network
IDU
NNI
BTS
FPR FPR
UNI
Fig. 43 FlexiPacket Radio –IDU connections by UNI/NNI ports (3)
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
51
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
52
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
53
UNI Interface functions
Here below are reported the UNI functions
• Mapping: performed on the incoming traffic in order to identify the connection it is
associated to. Mapping functionality allows associating to all incoming traffic a
specific VLAN ID identifying the EVC. The mapping is based on configurable
mapping rules, different for each equipment and software releases.
WARNING
Please refer yourself to the "HUB Structure chapter" for further details about
mapping
TIP
Once the mapping has been performed, all the incoming traffic has been associated
to a specific EVC. This means that the VLAN tag associated to the Carrier Ethernet
service is appended to each frame and it is used across the entire Carrier Ethernet
network for delivering the frame towards the destination. This tag is called S-tag.
• Manipulation: Manipulation is configurable per EVC. The configuration foresees
two options:
VID preservation: transparent transport of the incoming frames; no modifications
are performed on the incoming frame; in egress the S-VID is removed thus the
frame come out the original C-tag;
VID translation: removal of the C-tag of the incoming traffic (if present): in case of
tagged frames the tag of the incoming frames is overwritten by S-tag; this
functionality allows modifying the frame format from that one received at the UNI to
a new one suitable for the treatment inside the network.
WARNING
Please refer yourself to the HUB Structure chapter for further details about
Manipulation
• Marking / Policing: the ingress traffic is marked by using 3 bits (Priority Code
Point) for defining priority and color.
WARNING
Please refer yourself to the HUB Structure chapter for further details about
Marking and Policing.
• Congestion Management: mechanism used for congestion avoidance by
randomly dropping packets according to congestion level (queue fill level), color
and priority.
WARNING
Please refer yourself to the QoS chapter for further details about Congestion
Management
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
54
• Queuing, Shaping (per port) and Scheduling
 5 queues per port in A1200/A200 and 8 queues in FPFM 200/HUB 800
 both Strict Priority (SP) and Weighted Round Robin (WRR) are mixed
for scheduling
WARNING
Please refer yourself to the QoS chapter for further details about Queuing and
Scheduling
• Per Hop Behavior decoding: by configuration it is possible to replace Priority
Code Point bits with new values in order to give different marking.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
55
NNI Interface functions
Here below are reported the UNI functions:
• Congestion Management
• Queuing, shaping (port) and scheduling
• Per Hop Behavior (PHB) Decoding: by configuration it is possible to replace PCP
bits with new values in order to give different marking.
The egress traffic flowing from the network to the access is already mapped to a
specific service. Therefore the mapping function is no more needed.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
56
3.1.4 Ethernet Virtual Connection (EVC)
The EVC is the Logical representation of an Ethernet service as defined by the
association between 2 or more UNIs.
It permits to transfer Ethernet Frames from one site to another one.
The EVC prevents data transfer between sites that are not part of the same EVC
They are typically distinguished by VLAN tags or Q-in-Q.
Three types of EVCs are defined by MEF as reported in Fig. 44, Fig. 45 and Fig. 46:
• Point-to-Point,
• Multipoint-to-Multipoint,
• Rooted Multipoint (Point-to-Multipoint)
Point-to-Point EVC
Carrier Ethernet
Network
CECE
UNIUNI
CECE
UNIUNI
CECE
UNIUNI
ISP
POP
UNIUNI
Storage Service Provider
Internet
Fig. 44 Point to Point EVC
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
57
Multipoint-to-Multipoint EVC
Carrier Ethernet Network
CECE
UNIUNI
CECE
UNIUNI
Carrier Ethernet Network
Fig. 45 Multipoint to Multipoint
Service
Multiplexed
Ethernet UNI
Point-to-Multipoint EVC
Carrier Ethernet
Network
CECE
UNIUNI
UNIUNI
UNIUNI
CECE
UNIUNI
CECE
Fig. 46 Point to Multipoint EVC
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
58
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
59
3.1.5 EVC Basic Service Attributes
Details regarding the EVC include:
• Bandwidth profiles
• Class of Service (CoS) Identification
• Service Performance
• Frame Delay (Latency)
• Frame Delay Variation (Jitter)
3.1.5.1 Definition Bandwidth Profiles parameters for policing
4 main parameters are defined to determine the Bandwidth Profiles:
two bandwidth limits—CIR and EIR—and two burst sizes— CBS and EBS.
CIR Committed Information Rate: the average rate up to which Service Frames are
delivered per the service performance parameters. The CIR is an average rate
because all Service Frames are always sent at the UNI speed, e.g., 10Mbps, and not
at the CIR, e.g., 2Mbps.
EIR Excess Information Rate specifies the average rate up to which Service Frames
are admitted into the provider’s network. The EIR is an average rate because all
Service Frames are sent at the UNI speed, e.g., 10Mbps, and not at the EIR, e.g.
8Mbps.
PIR Peak Information Rate: = CIR + EIR
CBS Committed Burst Size: is the maximum number of bytes (e.g. 2K bytes) allowed
for incoming packets to burst above the CIR, but still be marked green.
EBS Excess Burst Size: is the maximum number of bytes (e.g. 2K bytes) allowed for
incoming packets to burst above the EIR and are marked yellow. When the burst size
has been exceeded, packets above the EIR are marked red.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
60
3.1.5.2 Color Marking
A way to describe Service Frames when their average rate is in profile or out of
profile is using the colors according to the Fig. 47
Green = conformant to CIR bandwidth profile
Yellow = conformant to EIR bandwidth profile. Yellow packets have
higher drop elegibility (will be dropped first in case of congestion).
Performance requirements delay, jitter and loss are not applied to
yellow packets within transport network
Red = not conformant and discarded immediately.
CIR Conformant
Traffic ≤ CIR
EIR Conformant
Traffic ≥ CIR
No traffic
Traffic ≥ EIR
Fig. 47 Color Marking
TIP
See more in MEF10.1, section 7.11
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
61
EVC-1
CIR
EIR
EVC-2
C
IR
EIR
EVC-3
CIREIR
Fig. 48
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
62
3.1.6 Three Types of Bandwidth Profiles
MEF defines three Bandwidths profiles as reported in the example of Fig. 49
Fig. 49 Bandwidths Profiles
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
63
3.2 Carrier Ethernet Service Types
Using the EVCs it's possible to support the Ethernet Services
Three Ethernet Service types are available as reported in Fig. 50:
• E-Line Service Type
• E-LAN Service Type
• E-Tree Service Type
E-LINE
E-LAN
E-TREE
Fig. 50 Carrier Ethernet Service Types
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
64
3.3 Circuit Emulation Services over Packet (CESoP)
Circuit Emulation Services Enables TDM Services to be transported across Carrier
Ethernet network, re-creating the TDM circuit at the far end.
They run on a standard Ethernet Line Service (E-Line).
TDM Circuits
(e.g. T1/E1/STM Lines)
Carrier Ethernet Network
TDM Circuits
(e.g. T1/E1/STM Lines)
Circuit Emulated
TDM Traffic
Fig. 51 Circuit Emulation Services
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
65
3.3.1 Standards
Different standards are available to provide the transport of a TDM service, typically
an E1/T1, through a bridged/routed packet network:
• IETF RFC5086 (CESoPSN).
• IETF RFC5087 (TDMoIP),
• IETF RFC4553 (SAToP)
• MEF8 (CESoETH).
The standard adopted by the 1st release of the FlexiPacket Radio product family was
the RFC5086.
WARNING
FM200 and HUB800 release 2 are able to support CESoPSN and SAToP
NSN FlexiPacket IDUs provide the Interworking Function (IWF) to support the
initiation and termination of a CESoPSN / SAToP service.
The ODU just provide prioritized transport of the packet flows related to the CES
service.
CESoPSN Internet Working Function (IWF)
Fig. 52 Internet Working Function
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
66
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
67
3.3.2 Pseudowire
Pseudowire is a mechanism that emulates the attributes of a TDM service such as an
E1, T1 or a fractional nx64 TDM service over a Packet switched network (PSN)
TDM pseudowire has to support:
• Packetization and Encapsulation of TDM Traffic
• Packet Delay Variation (PDV) attenuation
• Frame Loss and Out-of Sequence Packets
• Clock recovery and Synchronization
Packetization and Encapsulation
Packetization refers to the process of converting the PDH or SONET/SDH bit stream
into Ethernet frames. Specific packet connectivity information is dependent on the
type of PSN: Ethernet, MPLS or IP.
The encapsulation process places a pseudowire control word in front of the TDM
data in order to define the format identifier, to support error flags, length and
sequence number (see "Frame Loss and Out-of Sequence Packets" point).
E1/T1
Frame
E1/T1
FrameEthernet Frames Ethernet Frames
Packet
Switched
Network
Header
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
68
Packet delay variation (PDV) is mainly due to the variable load conditions of
network elements and interfaces, randomly occurring in the network. Although
priority-based schedulers are implemented in each network element of the
FlexiPacket products, still a delay variation is present for high priority packets (such
as CESoP packets) passing through a network element.
The packet delay variation is compensated by the “playout buffer” located in the
receiving IWF. The basic criterion for dimensioning the playout buffer is to estimate
the overall “packet delay variation” of the network between the initiating and the
terminating CESoPSN IWF and to assign the receiving IWF a buffer size more than
twice the estimated packet delay variation.
Actually the packet delay variation is defined as the difference between the maximum
delay of the CESoP packets to be supported without impairments (i.e. without errors
or out-of-service conditions on the E1 stream) and their minimum delay.
For what concerns the estimation of the total E1 end-to-end delay this will correspond
to the network delay of CESoP packets added to the delay provided by the playout
buffer.
WARNING
The "playout buffer" dimensioning is calculated by means of a proper tool.
Please refer yourself to the Annex for detailed information about that.
Frame Loss and Out-of Sequence Packets
Frames may occasionally not arrive in the order in which they were sent out. In some
cases, the frames may arrive very late or not at all, resulting in frames being
discarded.
TDM and SONET/SDH networks don't have the concepts of resending frames hence
such frames are considered lost if they are not received within the window of the jitter
buffer at the destination.
The destination must have the ability to re-sequence the arriving frames.
This is achieved through the use of sequence numbers within the headers.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
69
Clock recovery and Synchronization
In the PDH network, the difference between in clock frequencies between TDM links
is compensated for using bit stuffing technologies. With a packet network, that
connection between the ingress and egress frequency is broken, since the packets
are discontinuous in time. The consequence of a long-term mismatch in frequency is
that the queue at the egress of the packet network will either fill up or empty.
For this reason particular techniques such as "Differential Clock Recovery" and
"Adaptive Clock Recovery" must be implemented.
WARNING
About Clock recovery and synchronization please, refer to the chapter
"Synchronization"
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
70
Different pseudowires are available according to the different standards:
CESoPSN (Circuit Emulation over PSN) Pseudowire
CESoPSN Pseudowire is able to transmit emulated structured TDM signals. That is it
can identify and process the frame structure and transmit signaling in TDM frames
A benefit of CESoPSN is that unused timeslots are not transported in the payload,
thereby saving on bandwidth.
CESoPSN provides three encapsulation modes:
• IP/UDP (IP over User Datagram Protocol : solution actually adopted in
FlexiPacket
• MPLS (Multi-Protocol Label Switching)
• L2TPv3 (layer 2Tunneling Protocol Version 3: alternative protocol to MPLS)
TDMoIP Pseudowire
The main difference between TDMoIP and CESoPSN is that the first packetizes TDM
data in multiples of 48 bytes while the second uses multiples of the TDM frame itself.
TDMoIP provides the same encapsulation modes as CESoPSN and the pure
Ethernet encapsulation
SAToP (Structure Agnostic TDM over Packet) Pseudowire
SAToP differs from the previous Pseudowires technologies because it treats the TDM
traffic as a data stream and ignores the framing or the timeslots.
SATOP provides the same encapsulation modes as CESoPSN
CESoETH (CES over Ethernet) Pseudowire
CESoETH define TDM Circuit Emulation packets encapsulated by bare Ethernet.
Emulated TDM CS data is distinguished based on the Emulated Circuit Identifier
(ECID).
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
71
3.4 FlexiPacket EVC and Services
NSN FlexiPacket IDUs provide Ethernet Virtual Connections (EVC), each one
associated to a service. Each service initiates at the ingress and terminates at the
egress of a network, running over both NNI and UNI ports.
WARNING
Since the mapping of traffic into connections / services is performed on UNI
ports only, both the initiation and termination of a service is possible on UNI
ports only (see Fig. 54).
NNIUNI3rd
party
3rd
party
NNI
network UNI
Access to Network Network to Network
End-to-end connection
FlexiPacket
IDU
FlexiPacket
IDU
Access to Network
Fig. 54 User to Network and Network to Network Interfaces
Three types of Services are supported by FlexiPacket IDU:
• CESoP (Circuit Emulation Service over Packet)
• SAToP (Structure Agnostic TDM over Packet; it's implemented in FM200 R2.0 and
HUB800 R2.0)
• E-line
 it is based on point-to-point EVC, running end-to-end between UNI
ports. A unique VLAN ID is reserved in the network to identify each E-
line service.
• E-LAN
 it is based on multipoint-to-multipoint EVC. In A1200 and A2200
Release 4.5, only one management E-LAN can be defined and it
identifies the management domain between FPR and A2200/A1200
devices. A unique VLAN ID, VIDMGT, is reserved for the management E-
LAN service (default value = 127). Forwarding is based on bridge
functionality. Destination MAC address is used to reach the target.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
72
WARNING
In FPH-A1200 Release 5.0 drop 2, only one E-LAN can be configured and it is
reserved for the management/DCN service. By default, this service is identified
by (VLAN ID=127). In FPH-2200 Release 5.0 is also possible to manage E-LAN
services via CLI and Web UI.
WARNING
In FPFM-200 and HUB 800, both E-Lines and E-LANs can be configured; one E-
LAN is reserved for the management/DCN service. By default, this service is
identified by (VLAN ID=127).
In Fig. 55, E-Lines and E-LAN (management) examples are shown.
At UNI:
• Mapping of traffic to the Service
• Assignment to a Class of Service
• Policing (CIR /EIR) according to SLA
• CE-VLAN manipulation (transparent/translation)
At NNI:
• Traffic of a Service is identified by a VLAN ID
NNI
UNI
UNI
DCN
Untagged
frames
3rd
party
untagged frames
UNI
3rd
party
E-line 1
UNI
3rd
party
NNI NNI
E-line 2
E-line 3
E-line 4
NNI
Packet
network
E-LAN
NMS
IDU IDU IDU
Fig. 55 FlexiPacket E-Lines and E-LAN Example
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
73
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
In Fig. 56, FlexiPacket CES and E-Line Services are shown.
2G
3G
3G
2G3G
2G
3G
Tail Site 2G+3G
Chain Site 2G+3G
Tail Site 3G
MW Hub Site
Packet i/f
CES : Circuit Emulation Service
•E1 over Ethernet via Pseudo Wire Emulation
•Higher priority in the network
UNI
UNI
E-Line
•Point to point service for Ethernet traffic
•Configurable Committed and Peak data Rate
•Basic entity for traffic provisioning and monitoring
TDM i/f
Fig. 56
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
74
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
75
4 Quality of Service in the HUB
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
76
4.1 QoS Mechanism
Quality of Service Mechanism implemented in the HUB includes (Fig. 57):
• Classifier and Packet Marker
a) Classifier makes the association EVC ↔ CoS based on settable "Classification
Rules".
b) Packet Marker marks QoS level at packet header (Green = conformant to CIR
bandwidth profile; Yellow = conformant to EIR bandwidth profile; Red = not
conformant and discarded immediately).
• Policer:
Protecting network resources by preventing usage in excess of guaranteed
bandwidth (bps), i.e. compare incoming traffic rate with Traffic Profile
• Buffer manager:
Congestions avoidance mechanisms
• Queue Scheduler:
decide which packet forward first based on its priority
WARNING
A way to describe Service Frames when their average rate is in profile or out of
profile is using the colors.
Packet colors are:
Green = conformant to CIR bandwidth profile
Yellow = conformant to EIR bandwidth profile
Red = not conformant and discarded immediately
Green or yellow color is marked into packet (Priority Code Point PCP bits) and
it will be carried to next phases in network.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
77
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
.....
Queue Scheduler
Meter
Dropper
Policer
#1
Marker
Meter
Dropper
Policer
#2
Marker
Meter
Dropper
Policer
#3
Marker
Meter
Dropper
Policer
#N
Marker
Output Port
PacketMarker
Scheduler
Q1
Q2
Q3
Qn
ClassifierandPacketMarker
BufferManager
Fig. 57 QoS Process Internal View
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
78
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
79
4.2 Classifier and Packet Marker
Classification is based on the Service Level Agreement (SLA) set up between the
service provider and the user. Traffic is classified in different priorities.
FlexiPacket Hub A1200/2200 Classification Criteria are characterized as following:
• Only one per-EVC basis criterion: each EVC is associated to a Class of Service
(CoS). The same classification criteria foreseen for the EVC mapping are still valid
for the CoSs mapping.
• Apply Customer Priority (ACP): this feature allows the user to flow traffic of
different priorities over the same service, all sharing the service's BW. When
enabled, packets for the service should be assigned with a Priority Code Point
(PCP) according to the C-Tag priority value and the customer priority decode
table.
FlexiPacket FirstMile-200 and HUB 800 also support two types of classification
criteria:
• Per EVC: each EVC is associated to a CoS.
• Multi-CoS: traffic belonging to the same EVC can be split in several CoSs.
Once the CoS has been identified, the PCP field of the VLAN tag associated to the
service is properly marked.
The PCP values will be used by the schedulers to select the proper queue.
PCP values to be associated to the CoSs are configurable in FPFM200 and HUB
800.
The association between CoS and PCP in FlexiPacket First Mile 200 and in the
FlexiPacket HUB 800 is reported in Fig. 58.
The association between CoS and PCP is fixed in A1200/A2200 and is reported in
Fig. 59.
Each queue is associated to a specific identification string (reported in the following
pictures); such identification string derives from the standard nomenclature
associated to the Differentiated Services (DiffServ) architecture specified by the
IETF.
IETF defines a set of six CoSs (in order of decreasing priority): EF, AF4, AF3, AF2,
AF1, BE.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
80
Some considerations about FPH-x200 respect to IETF architecture
FPH-x200 does not consider the entire set of identifiers:
It does not foresee the AF4 ID;
It foresees the additional EF1 ID;
FPH-x200 uses an opposite order of priorities for AFx classes:
AFx ID is associated to an higher priority with respect the AFx+1ID (i.e. in order of
decreasing priority AF1, AF2, AF3);
WARNING
In FPH-x200, traffic associated to the same CoS is handled in the same queue,
but with different discarding eligibility as reported in Fig. 59.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
81
0Queue 0: SP/WFQBest EffortsBE
1Queue 1: SP/WFQcontrolAF
2Queue 2: SP/WFQNormalAF3
3Queue 3: SP/WFQBusiness CriticalAF2
4Queue 4: SP/WFQControlAF1
5Queue 5: SP/WFQControlEF
6Queue 6: SP/WFQCESEF1
7Queue 7: SP/WFQDelay SensitiveEF2
PCPTreatment
(programmable)
ServiceIdentification
String
EF= Expedited Forwarding
AF= Assured Forwarding
Fig. 58 association between CoSs and PCP in FlexiPacket First Mile 200 and FlexiPacket HUB 800
1 (green)
0 (yellow)
Queue 0: WFQBest EffortsAF3
3 (green)
2 (yellow)
Queue 1: WFQBusiness CriticalAF2
5 (green)
4 (yellow)
Queue 2: WFQManagementAF1
6 (green)Queue 3: SPDelay SensitiveEF2
7 (green)Queue 4: SPCESEF1
PCPTreatment
(Fix)
ServiceIdentification
String
EF= Expedited Forwarding
AF= Assured Forwarding
Fig. 59 association between CoSs and PCP in A1200/A2200
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
82
The characteristics of the classes are:
• EF1
 Lowest delay and delay variation
 No packet loss
 Similar to DiffServ Expedited Forwarding
 Usually reserved for Circuit Emulation Service (TDM services)
 May be used for Voice
• EF2
 Low delay, delay variation, and no packet loss
 Used for Voice, Video, other real-time application
• AF1
 Low packet loss
 Reserved for internal network control traffic (OSPF, configuration, download
etc.)
• AF2
 Lower delay and packet loss than Normal Data
 Better excess BW treatment than Normal Data
 Similar to DiffServ Assured Forwarding
• AF3
 Not just Best effort – may still have guaranteed BW
• BE
 Best Effort
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
83
4.3 Policer
The Meter (Fig. 60) measures incoming traffic (bps), compares it with traffic profile
and sends the results (Conform, Exceed, Violate) to the "Policer Action".
Policer Actions decisions are:
• Pass: Forwarding packet
• Mark : Change value of L2 802.1p (Marker block in Fig. 60 )
• Drop: Discarding packet (Dropper block in Fig. 60)
Meter
Policer
Packet
In
Packet
Out
Dropper
Marker
Fig. 60 Policer
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
84
4.3.1 Meter Algorithm: Two rate - three color marker (trTCM)
A token bucket analogy is used to describe the algorithm that performs the metering.
The algorithm decides which particular packets are within the bandwidth limits, and
which are in excess the limit.
Two buckets are used, one with a volume equal to the CBS (C bucket) and one with
the volume equal to the EBS (E bucket).
How does it works (see Fig. 61)
• The token buckets C and E are initially (at time 0) full, i.e.:
 the token count Tc(0) = CBS
 the token count Te(0) = EBS.
• Tokens are dropped into the buckets at rates equal to the CIR and EIR
respectively.
• Simultaneously, every time a packet comes past, a set of tokens equal to the size
of the packet are taken out of the buckets.
• As long as the C bucket is not empty, packets are market green.
• When the C bucket is empty, but the E bucket is not, packets are marked yellow.
• If both buckets are empty, packets are marked red
• When the source remains idle (no incoming frames) tokens accumulate in the
bucket.
• The idle “credits” can be recovered by the source via sending packets later at a
speed faster than CIR bits/sec.
The value of CBS will depend upon the type of applications or traffic that the service
is targeting to support.
For example, for a service designed to support bursty TCP-based data applications,
CBS will be much larger than for a service supporting more constant rate UDP-based
applications.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
85
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dropped
Incoming
Frames
Bucket size
according to EBS
Bucket size
according to CBS
Excess Rate
Bucket
Committed Rate
Bucket
Outgoing Frames
at a regular rate
with controlled burst
CIR - Committed Information Rate, CBS - Committed Burst Size, PIR - Peak Information Rate, MBS -
Maximum Burst Size, EIR: Excess Information Rate
Metering: Two rate - three color marker Algorithm (trTCM)
New token added CIR/8 times/second
Check packet size against
“number of tokens“ in
Bucket
If OK, go on and subtract
packet size.
If not OK, drop packet.
New token added EIR/8
times/second
One token = one byte
c
E
…
…
…
…
…
…
.
Violating Frames
(above EIR)
Conforming Frames
(within EIR)
Conforming Frames
(within CIR)
Exceeding Frames
between CIR and PIR
Fig. 61 Metering algorithm
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
86
4.4 Buffer Manager: Congestion Avoidance
RED Algorithm
Random Early Detection (RED) is an algorithm which simply drops packets if too
many are being received.
This causes the devices which are sending the packets to notice a problem and
reduce their transmissions.
This mechanism is especially useful in TCP traffic where the TCP can adjust its BW
according to the network congestion levels.
The key to this policy is the hypothesis that a packet randomly drop from all incoming
traffic will belong to a particular user with a probability proportional to the average
rate of transmission of that user.
The design idea of RED is very simple: two preset thresholds are used to detect
incipient congestion and control the average queue size.
Fig. 62 illustrates the general idea of RED.
According to the estimated average queue length, there are three different working
states.
• When the average queue length is less than the minimum threshold, all incoming
packets are processed and forwarded properly, and no packet is dropped.
• When average queue length is between the minimum and maximum thresholds,
arriving packets are randomly dropped with a probability that is a function of the
average queue length.
• When the average queue length is greater than the maximum threshold, every
arriving packet is discarded.
However, the probability of packet discard when the queue depth equals the
maximum threshold is 1/ (MPD) where MPD is the so called Mark Probability
Denominator
For example, if the mark probability denominator was set to 10, when the queue
depth reached the maximum threshold, the probability of discard would be 1/10 (that
is, a 10 percent chance of discard).
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
87
RED – Drop Profile
•RED: Random early detect
Idea: Throw away certain packets before the buffers run completely full.
Without RED
(Tail Drop)
Queue filling
level
Drop Probability
0
0 Max
0
0
100%
Max
With RED
No
dropping
random
dropping
full dropping100%
probability of discard at
the maximum threshold
Equal to 1/MPD)
Fig. 62 RED general Idea
WARNING
Red Algorithm is implemented inside the First Mile 200 and HUB 800 and it only
works for yellow packets. The green packets will be dropped only when the
buffer becomes full. All the red packets are dropped.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
88
WRED Algorithm
Unlike RED, Weighted Random Early Detection (WRED) has a profile for each
priority marking.
For example, a packet marked "yellow" might have a minimum threshold of 25
packets, whereas a packet marked "green" might have a minimum threshold of 30
packets. In this example, "yellow" packets start to be discarded "before" green.
0
0
100%
Max
Lower class is treated with a more
aggressive Drop-Profile
DropProbability
Queue filling
Fig. 63 WRED general idea
WARNING
WRED Algorithm is implemented inside the A1200/A2200
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
89
4.5 Queue Scheduler
By means of scheduling algorithms is possible to decide which frames forward first
based on its priority and how to manage the shared available bandwidth in case of
congestion.
Five strategies can be considered:
1) Without QoS management: FIFO (First In First Out) queuing (Fig. 64)
• Only one queue
• Frames are transmitted in the same order they arrive
In case of congestion:
• All frames experience queue delay irrespective of their class of service
• Frames may be discarded irrespective of their class of service
First In First Out
Fig. 64 FIFO Queuing
WARNING
FIFO could be implemented inside FPFM200 and HUB 800
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
90
2) Strict priority queuing (Fig. 65)
• One queue for each class
• Queues are processed in descending order (highest to lowest).
• Queues assigned as high priority are serviced until they are empty.
Low priority queues potentially can be starved; in order to avoid it, high priority traffic
should be kept small.
Strict Priority Queuing (SPQ)
• SPQ Uses multiple queues
• Allows prioritization
• Always empties higher priority queue before going to the next queue:
– Empty Queue Q3
– If Queue Q3 empty, then dispatch from Queue no. 2
– If both Queue Q3 and Queue Q2 empty, then dispatch from Queue Q0…
1 3 6 6 7 7 7
Queues
Until Queue 3 is emptied
Direction of Data flow
7 7 7
6
3
Q3
Q2
Q1
1
Q0
6
Queue Priority
Q3 7
Q2 6,5
Q1 3,4
Q0 1,2
Fig. 65 Example of Strict Priority Queuing
Strict Priority is implemented inside A1200, A2200 and First Mile 200
FlexiPacket A1200/A2200 has 5 queues
FPFM200 and HUB 800 have 8 queues
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
91
3) Weighted Round Robin (WRR) (Fig. 66)
• The weight is a variable that indicates how many packets have to be sent in each
cycle from each queue.
• A sequence of scheduling is generated automatically according to this value.
• If a queue has fewer packets than the value of the weight, the WRR scheduler
outputs the existent number of packets and begins to serve the next queue.
• The WRR scheduler does not take the size of the transmitted packets into
account.
Weighted Round Robin (WRR)
• Allows prioritization
• Assign a “weight” to each queue
• Dispatches packets from each queue proportional to an
assigned weight
3 67 77
Queues
Direction of Data flow
7 77
6
3
6
6
Queue Priority Weight
Q3 7 3
Q2 6 2
Q1 3 1
Q3
Q1
Q2
Q3
Q2
Q3
Q1
Q3
Q2
Fig. 66 Example of Sequence of Scheduling in a Weighted Round Robin
Weighted Round Robin is implemented inside A1200/A2200/ First Mile 200/HUB
800
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
92
4) Deficit Round Robin (DRR)
An inherent limitation of the WRR mode is that bandwidth is allocated in terms of
packets. WRR works well if the average packet size of each coarse-grained CoS
queue flow is known. In most instances, however, this attribute is traffic-dependent
and can vary over time. DRR provides a bandwidth allocation scheduler mode that
takes into account the variably sized packet issue by maintaining sufficient state
information when arbitrating across the CoS queues.
According to the DRR algorithm, each queue "I" has a counter associated called
Deficit Counter (DCi), which indicate the amount of resources (bytes) the flow can
use in a round.
Flows are visited in a round robin fashion.
Each flow is visited only once during each round.
Upon each visit the flow’s deficit counter DCi is increased by a fixed quantity Q called
quantum.
A packet is sent only if its length is smaller than the deficit counter’s current value,
otherwise the flow is skipped.
After a packet is sent the deficit counter is decreased by the size of the transmitted
packet.
Let's consider one example in which there are 4 queues with the same "quantum" in
order to simplify the example.
The example is reported from Fig. 67 to Fig. 70.
As reported in Fig. 67 the "Quantum" is equal to 500 bytes.
As you can see in the example, the packet is sent only if it's ≤ respect to the "Deficit
Counter's current value".
The "Deficit Counter's current value" may include a "Credit" coming from the previous
"round".
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
93
500700
200500
400
Initial State
Queue 1
Queue 2
Queue 3
Queue 4
Quantum = 500 bytes for all queues (may have different quantum for each queue)
Empty space Bytes of the packet Round Robin
1°packet2°packet
2°packet 1°packet
1°packet
600
2°packet
500
3°packet
x..x
Fig. 67
500700
200500
400
Deficit Counter
500
0
500
500
1° Round
Current Value Credit Packet Sent
0
0
300
100
Q1
Q3
Q4
Queue 1
Queue 2
Queue 3
Queue 4
Packet 1 of queue1 gets served (500 ≥ 500) => credit = 0
Packet 1 of queue3 gets served (500 ≥ 200) => credit = 300
Packet 1 of queue4 gets served (500 ≥ 400) => credit = 100
Quantum
size
Empty space Bytes of the packet Round RobinPacket sent
600
500
Fig. 68
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
94
700
500
Deficit Counter
500
0
800
600
2° Round
Current Value Credit Packet Sent
500
0
300
0
Q3
Queue 1
Queue 2
Queue 3
Queue 4
500
Quantum size+
1° round credit
Quantum
size
Packet 2 of queue1 not served (500 < 700) => credit = 500
Packet 2 of queue3 gets served (300+500 > 500)=> credit = 300
Packet 2 of queue 4 gets served (600 =>600 credit = 0
Empty space Bytes of the packet Round RobinPacket sent
600
Quantum size+
1° round credit
Q4
Fig. 69
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
95
700
Empty queue
500
Deficit Counter
1000
0
800
0
3° Round
Current Value Credit Packet Sent
300
0
300
0
Q3
Queue 1
Queue 2
Queue 3
Queue 4
Q1
Quantum size+ credit
Quantum size+ 2°
round credit
Packet 3 of queue1 gets served (500 + 500 > 700) => credit = 300
Packet 3 of queue3 gets served (300 + 500 > 500) => credit = 300
Empty space Round RobinPacket sent
Fig. 70
WARNING
A reset operation avoids outstanding packets. No accumulate credits for a long
period
WARNING
Quantum may be different for each queue introducing a different "weight" for
each queue
FlexiPacket First Mile 200 and HUB 800 give the possibility to select the DRR
Scheduling mode
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
96
5) Multi stage: two strategies can be combined together
Example: Weighted Round Robin Queuing + Strict Priority (Fig. 71)
WARNING
Weighted Round Robin + Strict Priority Multi Stage is implemented inside
A1200/A2200/FPFM200 and HUB 800. In A1200/A2200 there is a fix Multi stage:
2SP+3WRR (Fig. 71). In First Mile 200/HUB 800 the Multi stage is fully
programmable (Fig. 72).
Deficit Round Robin + Strict Priority is implemented inside FPFM200/HUB800
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
97
A1200/A2200 QoS Classes Summary
Fig. 71 A1200/A2200 QoS Classes Summary
Fig. 72 FPFM 200 WRR/DRR and Strict Priority scheduling
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
98
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
99
5 Quality of service in the FlexiPacket Radio
Rel.1.3 EP1
WARNING
Please, skip this chapter and jump to the chapter 6 if the course is about the
FlexiPacket MultiRadio
5.1 Quality of Service Mechanism
Quality of Service Mechanism implemented in the FlexiPacket Radio includes (Fig.
73):
• Classification
• Egress scheduling
Classification
Egress
Scheduling
IDU Side ODU Side
Fig. 73 FlexiPacket Radio Quality of Service (1)
FPR SVR1.x supports QoS mechanism in only one direction: from the gigabit
Ethernet side towards the radio side.
This derives from the fact that the bandwidth available on the gigabit interface is
much bigger than the capacity over the radio link (1 Gbps versus about 400 Mbps).
This implies that there is no need to apply QoS to traffic coming from the radio
interface towards the Ethernet one.
Moreover, frames coming from the radio have been already scheduled and properly
enquired on the remote FPR where QoS has been applied.
The QoS suite foresees a scheduler whose characteristics are described in the
following.
WARNING
As you can see in Fig. 73 metering function is not supported since FPR SVR1.x
does not support the UNI interface, where traffic is metered and marked
accordingly.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
100
5.2 Classification
Incoming packets are classified according to specified rules in order for them to be
queued in the corresponding Tx queue and then scheduled.
Four Tx queues are available (Fig. 74).
FlexiPacket Radio classifies packets according to the following rules, allowing
multiple classifications (user selectable):
• VLAN ID field (Highest precedence)
• IEEE 802.1p VLAN priority field
• IPv4 DSCP field
• IPv6 traffic class field
• Port (Lowest precedence, always enabled). This criterion is not configurable and it
is exclusively used to assign a CoS to traffic which has not been classified in
anyway. The priority associated to this traffic is based on the port which traffic is
received from. In details: If traffic is received from gigabit Ethernet interface frames
are queued into priority 0 queue (lowest); If traffic is generated internally by the
microprocessor frames are queued into priority 2 queue (second highest).
It is possible to enable the criteria either separately or in combination (the criterion
based on the port is always enabled) but it is not possible to modify the associated
priority (if VLAN ID and PCP criteria are enabled, VLAN ID field will be always
checked first) . The incoming frame is processed starting from the highest
precedence criteria. Lower precedence criteria are considered only if the frame
doesn’t match the higher ones.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
101
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fig. 74 ODU Quality of Service
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
102
5.3 Egress Scheduling
FlexiPacket Radio supports four egress scheduling algorithms to handle Ethernet
frames towards the radio:
1) FIFO (First In First Out) queuing (see Fig. 64)
2) Strict priority queuing (Fig. 65)
3) Weighted Round Robin (Fig. 66)
4) Multi stage: Weighted Round Robin+ Strict Priority
Two strategies can be combined together.
FlexiPacket Radio supports 2 SP + 2 WRR with configurable weights (default) or
1 SP + 3 WRR with configurable weights
WARNING
FlexiPacket Radio has four queues
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
103
6 Quality of service in the FlexiPacket
MultiRadio Rel 2.1
WARNING
Please, skip this chapter if the course is about the FlexiPacket Radio
6.1 Quality of Service Mechanism
Figure Fig. 75 shows the QoS architecture, structured in two main functional blocks:
• Classification
• Egress scheduling
Classification
Egress
Scheduling
IDU Side ODU Side
Fig. 75 FlexiPacket MultiRadio Quality of Service (1)
Incoming Ethernet packets are classified according to the specified criteria in order to
be queued inside the correspondent buffer, waiting to be scheduled.
The Egress scheduling applies the QoS scheduling criteria among all queues to
prioritize the egress traffic sent to the radio.
Up to 8 egress queues could be configured and used for scheduling the egress
traffic.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
104
6.2 QoS Classification Criteria
The incoming Ethernet packets are classified according to the following criteria also
called classification rules in the following:
• Ethernet Source and Destination MAC address
• EtherType field
• IEEE 802.1p VLAN priority field
• VLAN ID field
• Pv4 ToS/DSCP field
• IPv6 traffic class field
• MPLS EXP field
6.3 Egress Scheduling
FlexiPacket MultiRadio supports three egress scheduling algorithms to handle
Ethernet frames towards the radio:
1) FIFO (First In First Out) queuing (see Fig. 64)
2) Strict Priority Queuing (Fig. 65)
In Strict Priority Queuing strategy, the active egress queues are served in descending
order of priority, from the highest to the lowest: each queue is served till it is
completely empty.
3) Weighted Round Robin (Fig. 66)
In Weighted Fair Queuing strategy, the available bandwidth is shared among all
active queues proportionally to specific weights associated to each queue: these
weights permit defining the amount of traffic that will be scheduled out for each
queue.
The weighting is configurable: the weights can be assigned to each priority queue.
Moreover a queue limiter is implemented in order to limit the amount of traffic from a
specific queue.
4) Multi stage: Weighted Round Robin+ Strict Priority
Two strategies can be combined together.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
105
7 Ethernet OAM
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
106
7.1 OAM Definition
OA&M (operations, administration, and maintenance) generally speaking means a
set of functions used by the user that enables detection of network fault and
measurement of network performance, as well as distribution of fault-related
information.
Ethernet OAM means Management Capabilities associated with Ethernet
Technology and used mainly in the Access network.
It refers to the tools and utilities available to install, monitor, and troubleshoot the
network and allow service providers to offer improved levels of services assurance.
What is OAM? Here below there are some OAM tasks:
Operations:
• Automatic monitoring of environment (e.g. discovery)
• Detect and isolate faults (e.g. connectivity verification, path trace)
• Alert administrators (e.g. AIS, RDI, SNMP trap)
Administration:
• Performance monitoring (utilization, latency, loss, error rate, jitter)
• Capacity planning
Maintenance:
• Upgrades
• New feature deployment
• Monitor health
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
107
7.2 OAM Layers
Ethernet as a technology may overlay a set of physical layer segments on one hand
and on the other hand enable seamless layer-2 services end-to-end.
Considering the OA&M requirements of such technology and its objectives (efficient
troubleshooting), the entire solution can be divided into the following layers:
• Service Layer
 Measures and represents the status of the services as seen by the
customer.
 Produces metrics such as throughput, roundtrip delay, and jitter
that need to be monitored to meet the SLAs contracted between
the provider and the customer.
• Network Layer
 Monitors path between two non-adjacent devices.
• Transport Layer
 Ensures that two directly connected peers maintain bidirectional
communication.
 Must detect “link down” failure and notify higher layer for protocol
to reroute around the failure.
 Monitors link quality to ensure that performance meets an
acceptable level.
Relationship among layers and standards is reported in Fig. 76.
• Each layer supports OAM capabilities independently
• OAMs interoperate
• Component responsibilities are complementary
E2E Performance
Monitoring
E2E Fault Monitoring
P2P Link Fault
Management
E-LMI= Ethernet Local Management Interface
Fig. 76 OAM Layer Components
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
108
Fig. 77 resumes the Ethernet OAM Standards.
Ethernet OAM
IEEE 802.1ag:
Connectivity Fault Management (CFM)
Also referred as Service OAM
IEEE 802.3ah (clause 57)
Ethernet Link OAM
Also referred as 802.3 OAM, Link OAM or Ethernet in the First Mile (EFM) OAM
ITU-T Y.1731
OAM functions and mechanisms for Ethernet-based networks
MEF E-LMI
Ethernet Local Management Interface
Fig. 77 Ethernet OAM Standards
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
109
The Ethernet OAM architecture building block is reported in Fig. 78
Point-to-Point EVCPoint-to-Point EVC
Carrier A
E-NNI
UNI
Multi-point to
Multi-point EVC
Multi-point to
Multi-point EVC
UNIUNI
Point-to-Point EVCPoint-to-Point EVC
UNI
UNI
UNI
Link OAM
•Fault-802.3ah
E2E Service OAM
•Fault-802.1ag
•Perform-Y.1731
Carrier B
Fig. 78 Ethernet OAM architecture building block
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
110
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
111
7.3 Ethernet Link Fault Management OAM (EFM OAM)
802.3ah
Ethernet Link Fault Management (see Fig. 79 ) has the following main tasks:
• Monitors the physical connection between two devices
• Troubleshoot individual links
• Fault Detection and Notification (Alarms)
• Count Frame and Symbol errors
• Remote Link Fault
• Loop-back testing – out-of-service
802.3ah 802.3ah 802.3ah 802.3ah 802.3ah 802.3ah 802.3ah 802.3ah
UNI UNI
E-NNI
802.3ah
E-Line Service
Operator 1 Operator 2
Fig. 79 EFM OAM
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
112
7.4 Connectivity Fault Management
(CFM) – 802.1ag
CFM is an end-to-end per-service-instance Ethernet layer OAM protocol that includes
the following proactive Fault Management functions:
• Fault Detection/Monitoring
 Continuity check (CC)
• Fault Verification
 Loopback (LB)
• Fault Isolation
 Link Trace (LT)
7.4.1 802.1ag: Terminology
Maintenance Domain (MD)
It's a part of a network that is controlled by a single operator.
It's defined by a set of internal and external (boundary) ports.
A Domain is assigned by the administrator a unique Maintenance Level (0 – 7).
The level of the domain is useful in defining the hierarchical relationships of multiple
domains.
CFM maintenance domains allow different organizations to use CFM in the same
network, but independently.
For example (Fig. 80), let's consider a service provider who offers a service to a
customer, and to provide that service, they use two other operators in segments of
the network.
In this environment, the customer can use CFM between their CE devices, to verify
and manage connectivity across the whole network, the service provider can use
CFM between their PE devices to verify and manage the services they are providing
and each operator can use CFM within their operator network, to verify and manage
connectivity within their network.
Recommended values of levels are as follow:
• Customer Domain largest (e.g. 7)
• Provider Domain in between (e.g. 3)
• Operator Domain smallest (e.g. 1)
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
113
Maintenance Domains are nested but not overlapped.
The encompassing domain must have a higher level than the domain it encloses as
reported in Fig. 80.
Operator 1 Domain level 1 Operator 2 Domain level 0
Service Provider Domain level 6
Core CoreAccess Access
Customer Domain level 7
Fig. 80 Different CFM Maintenance Domains across a Network
.
Maintenance Association (MA)
It's used to monitor connectivity for a single service instance within the Maintenance
Domain.
It's a set of MEPs (see next point) established to verify the integrity of a single service
instance.
Maintenance Point (MP)
A CFM Maintenance Point (MP) is an instance of a particular CFM service on a
specific interface.
CFM only operates on an interface if there is a CFM maintenance point on the
interface; otherwise, CFM frames are forwarded transparently through the interface.
A maintenance point is always associated with a particular CFM service, and
therefore with a particular maintenance domain at a particular level.
Maintenance points generally only process CFM frames at the same level as their
associated maintenance domain.
Frames at a higher maintenance level are always forwarded transparently, while
frames at a lower maintenance level are normally dropped.
This helps enforce the maintenance domain hierarchy, and ensures that CFM frames
for a particular domain cannot leak out beyond the boundary of the domain.
0BGeneral Topics
FT48923EN02GLA0
© 2011 Nokia Siemens Networks
114
There are two types of Maintenance Point: MEP and MIP (see next step and Fig. 81)
Maintenance End Point (MEP)
It resides at the edge of a maintenance domain. Proactively transmits Continuity
Check (CC) Messages. MEP processes/Drops/Forwards CFM frames based on MD
level. It transmits trace-route and Loopback messages upon operator request.
There are two types of MEP (Fig. 82):
• UP (inward in respect to the device)
• DOWN (outward in respect to the device)
The terms Down MEP and Up MEP are defined in the IEEE 802.1ag and ITU-T
Y.1731 standards, and refer to the direction that CFM frames are sent from the MEP.
The terms should not be confused with the operational status of the MEP.
Maintenance Intermediate Point (MIP)
It's a passive functional entity located at intermediate points in a Maintenance
Domain.
MIP maintains CCM Database and responds to trace-route and Loopback messages.
Operator 1 Domain Operator 2 Domain
Service Provider Domain
MEPMIPMEP MIP
MEPMIPMIP
MEPMIP
MEPMIPMEP
MEP
MEP
PHY
Core CoreAccess Access
CFM
Customer Domain
Fig. 81 CFM Terminology
WARNING
In CFM diagrams, the conventions are that triangles represent MEPs, pointing
in the direction that the MEP sends CFM frames, and circles represent MIPs.
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_
03 ft48923 en02gla0_general topics_

More Related Content

What's hot

Tutorial on IEEE 802.11 - MAC Protocols and Frames
Tutorial on IEEE 802.11 - MAC Protocols and FramesTutorial on IEEE 802.11 - MAC Protocols and Frames
Tutorial on IEEE 802.11 - MAC Protocols and FramesDheryta Jaisinghani
 
Odl010024 qin q laboratory exercise guide issue1
Odl010024 qin q laboratory exercise guide issue1Odl010024 qin q laboratory exercise guide issue1
Odl010024 qin q laboratory exercise guide issue1jcbp_peru
 
CCNA Routing Fundamentals - EIGRP, OSPF and RIP
CCNA  Routing Fundamentals -  EIGRP, OSPF and RIPCCNA  Routing Fundamentals -  EIGRP, OSPF and RIP
CCNA Routing Fundamentals - EIGRP, OSPF and RIPsushmil123
 
Presentation of the IEEE 802.11a MAC Layer
Presentation of the IEEE 802.11a MAC LayerPresentation of the IEEE 802.11a MAC Layer
Presentation of the IEEE 802.11a MAC LayerMahdi Ahmed Jama
 
Ccna ppt1
Ccna ppt1Ccna ppt1
Ccna ppt1AIRTEL
 
Switching & VLAN(4knet.ir)
Switching & VLAN(4knet.ir)Switching & VLAN(4knet.ir)
Switching & VLAN(4knet.ir)Azad Kaki
 
Other Wireless Networks
Other Wireless NetworksOther Wireless Networks
Other Wireless NetworksMeenakshi Paul
 
CCNA Routing Protocols
CCNA Routing ProtocolsCCNA Routing Protocols
CCNA Routing ProtocolsDsunte Wilson
 
IEEE 802.11a Physical Layer Simulation
IEEE 802.11a Physical Layer SimulationIEEE 802.11a Physical Layer Simulation
IEEE 802.11a Physical Layer SimulationMichail Grigoropoulos
 
CCNA Exam 200-120 pdf
CCNA Exam 200-120 pdfCCNA Exam 200-120 pdf
CCNA Exam 200-120 pdfMadhan Banda
 

What's hot (20)

Tutorial on IEEE 802.11 - MAC Protocols and Frames
Tutorial on IEEE 802.11 - MAC Protocols and FramesTutorial on IEEE 802.11 - MAC Protocols and Frames
Tutorial on IEEE 802.11 - MAC Protocols and Frames
 
ccna networking ppt
ccna networking pptccna networking ppt
ccna networking ppt
 
Ccna day4
Ccna day4Ccna day4
Ccna day4
 
Ccna day3
Ccna day3Ccna day3
Ccna day3
 
Wired LANs
Wired LANsWired LANs
Wired LANs
 
Ccna day5
Ccna day5Ccna day5
Ccna day5
 
Odl010024 qin q laboratory exercise guide issue1
Odl010024 qin q laboratory exercise guide issue1Odl010024 qin q laboratory exercise guide issue1
Odl010024 qin q laboratory exercise guide issue1
 
Dynamic routing protocols (CCNA)
Dynamic routing protocols (CCNA)Dynamic routing protocols (CCNA)
Dynamic routing protocols (CCNA)
 
Lan Network with Redundancy.ppt
Lan Network with Redundancy.pptLan Network with Redundancy.ppt
Lan Network with Redundancy.ppt
 
Ccna day4
Ccna day4Ccna day4
Ccna day4
 
CCNA Routing Fundamentals - EIGRP, OSPF and RIP
CCNA  Routing Fundamentals -  EIGRP, OSPF and RIPCCNA  Routing Fundamentals -  EIGRP, OSPF and RIP
CCNA Routing Fundamentals - EIGRP, OSPF and RIP
 
Presentation of the IEEE 802.11a MAC Layer
Presentation of the IEEE 802.11a MAC LayerPresentation of the IEEE 802.11a MAC Layer
Presentation of the IEEE 802.11a MAC Layer
 
Ccna ppt1
Ccna ppt1Ccna ppt1
Ccna ppt1
 
802 1ad
802 1ad802 1ad
802 1ad
 
Switching & VLAN(4knet.ir)
Switching & VLAN(4knet.ir)Switching & VLAN(4knet.ir)
Switching & VLAN(4knet.ir)
 
Other Wireless Networks
Other Wireless NetworksOther Wireless Networks
Other Wireless Networks
 
CCNA Routing Protocols
CCNA Routing ProtocolsCCNA Routing Protocols
CCNA Routing Protocols
 
IEEE 802.11a Physical Layer Simulation
IEEE 802.11a Physical Layer SimulationIEEE 802.11a Physical Layer Simulation
IEEE 802.11a Physical Layer Simulation
 
Vlans
VlansVlans
Vlans
 
CCNA Exam 200-120 pdf
CCNA Exam 200-120 pdfCCNA Exam 200-120 pdf
CCNA Exam 200-120 pdf
 

Similar to 03 ft48923 en02gla0_general topics_

OptiQNet-842-DM-v0.4-for-852
OptiQNet-842-DM-v0.4-for-852OptiQNet-842-DM-v0.4-for-852
OptiQNet-842-DM-v0.4-for-852Yi-Neng Lin
 
Frame relay design
Frame relay designFrame relay design
Frame relay designBhargav Amin
 
Nwk assignment body copy
Nwk assignment body   copyNwk assignment body   copy
Nwk assignment body copyTonny Michael
 
Telecommunications: Wireless Networks
Telecommunications: Wireless NetworksTelecommunications: Wireless Networks
Telecommunications: Wireless NetworksNapier University
 
03 PO_SP2001_E01_0 L2 Technology_VLAN.pdf
03 PO_SP2001_E01_0 L2 Technology_VLAN.pdf03 PO_SP2001_E01_0 L2 Technology_VLAN.pdf
03 PO_SP2001_E01_0 L2 Technology_VLAN.pdfNguynTy5
 
VLAN Trunking Protocol
VLAN Trunking ProtocolVLAN Trunking Protocol
VLAN Trunking ProtocolNetwax Lab
 
CCNA Basic Switching and Switch Configuration
CCNA Basic Switching and Switch ConfigurationCCNA Basic Switching and Switch Configuration
CCNA Basic Switching and Switch ConfigurationDsunte Wilson
 
Westermo webinar: Learning the Basics of Ethernet Networking
Westermo webinar: Learning the Basics of Ethernet NetworkingWestermo webinar: Learning the Basics of Ethernet Networking
Westermo webinar: Learning the Basics of Ethernet NetworkingWestermo Network Technologies
 
NetSim Technology Library- Internetworks
NetSim Technology Library- InternetworksNetSim Technology Library- Internetworks
NetSim Technology Library- InternetworksVishal Sharma
 
OpenNebula - Mellanox Considerations for Smart Cloud
OpenNebula - Mellanox Considerations for Smart CloudOpenNebula - Mellanox Considerations for Smart Cloud
OpenNebula - Mellanox Considerations for Smart CloudOpenNebula Project
 
Paper id 21201485
Paper id 21201485Paper id 21201485
Paper id 21201485IJRAT
 
Virtual Local Area Network
Virtual Local Area NetworkVirtual Local Area Network
Virtual Local Area NetworkAtakan ATAK
 
Ethernet protocol
Ethernet protocolEthernet protocol
Ethernet protocolTom Chou
 

Similar to 03 ft48923 en02gla0_general topics_ (20)

Virtual lan
Virtual lanVirtual lan
Virtual lan
 
OptiQNet-842-DM-v0.4-for-852
OptiQNet-842-DM-v0.4-for-852OptiQNet-842-DM-v0.4-for-852
OptiQNet-842-DM-v0.4-for-852
 
Installing motorola pbn_products
Installing motorola pbn_productsInstalling motorola pbn_products
Installing motorola pbn_products
 
Zigbee 802-15-4
Zigbee 802-15-4Zigbee 802-15-4
Zigbee 802-15-4
 
Frame relay design
Frame relay designFrame relay design
Frame relay design
 
Nwk assignment body copy
Nwk assignment body   copyNwk assignment body   copy
Nwk assignment body copy
 
Telecommunications: Wireless Networks
Telecommunications: Wireless NetworksTelecommunications: Wireless Networks
Telecommunications: Wireless Networks
 
LAN Proposal
LAN Proposal LAN Proposal
LAN Proposal
 
03 PO_SP2001_E01_0 L2 Technology_VLAN.pdf
03 PO_SP2001_E01_0 L2 Technology_VLAN.pdf03 PO_SP2001_E01_0 L2 Technology_VLAN.pdf
03 PO_SP2001_E01_0 L2 Technology_VLAN.pdf
 
VLAN Trunking Protocol
VLAN Trunking ProtocolVLAN Trunking Protocol
VLAN Trunking Protocol
 
C C N A Day5
C C N A  Day5C C N A  Day5
C C N A Day5
 
CCNA Basic Switching and Switch Configuration
CCNA Basic Switching and Switch ConfigurationCCNA Basic Switching and Switch Configuration
CCNA Basic Switching and Switch Configuration
 
Westermo webinar: Learning the Basics of Ethernet Networking
Westermo webinar: Learning the Basics of Ethernet NetworkingWestermo webinar: Learning the Basics of Ethernet Networking
Westermo webinar: Learning the Basics of Ethernet Networking
 
NetSim Technology Library- Internetworks
NetSim Technology Library- InternetworksNetSim Technology Library- Internetworks
NetSim Technology Library- Internetworks
 
OpenNebula - Mellanox Considerations for Smart Cloud
OpenNebula - Mellanox Considerations for Smart CloudOpenNebula - Mellanox Considerations for Smart Cloud
OpenNebula - Mellanox Considerations for Smart Cloud
 
The Basics of Industrial Ethernet Communications
The Basics of Industrial Ethernet CommunicationsThe Basics of Industrial Ethernet Communications
The Basics of Industrial Ethernet Communications
 
Paper id 21201485
Paper id 21201485Paper id 21201485
Paper id 21201485
 
Virtual Local Area Network
Virtual Local Area NetworkVirtual Local Area Network
Virtual Local Area Network
 
Ethernet protocol
Ethernet protocolEthernet protocol
Ethernet protocol
 
Frame Relay
Frame RelayFrame Relay
Frame Relay
 

Recently uploaded

9892124323 | Book Call Girls in Juhu and escort services 24x7
9892124323 | Book Call Girls in Juhu and escort services 24x79892124323 | Book Call Girls in Juhu and escort services 24x7
9892124323 | Book Call Girls in Juhu and escort services 24x7Pooja Nehwal
 
CALL ON ➥8923113531 🔝Call Girls Saharaganj Lucknow best sexual service
CALL ON ➥8923113531 🔝Call Girls Saharaganj Lucknow best sexual serviceCALL ON ➥8923113531 🔝Call Girls Saharaganj Lucknow best sexual service
CALL ON ➥8923113531 🔝Call Girls Saharaganj Lucknow best sexual serviceanilsa9823
 
CALL ON ➥8923113531 🔝Call Girls Gomti Nagar Lucknow best Night Fun service
CALL ON ➥8923113531 🔝Call Girls Gomti Nagar Lucknow best Night Fun serviceCALL ON ➥8923113531 🔝Call Girls Gomti Nagar Lucknow best Night Fun service
CALL ON ➥8923113531 🔝Call Girls Gomti Nagar Lucknow best Night Fun serviceanilsa9823
 
哪里有卖的《俄亥俄大学学历证书+俄亥俄大学文凭证书+俄亥俄大学学位证书》Q微信741003700《俄亥俄大学学位证书复制》办理俄亥俄大学毕业证成绩单|购买...
哪里有卖的《俄亥俄大学学历证书+俄亥俄大学文凭证书+俄亥俄大学学位证书》Q微信741003700《俄亥俄大学学位证书复制》办理俄亥俄大学毕业证成绩单|购买...哪里有卖的《俄亥俄大学学历证书+俄亥俄大学文凭证书+俄亥俄大学学位证书》Q微信741003700《俄亥俄大学学位证书复制》办理俄亥俄大学毕业证成绩单|购买...
哪里有卖的《俄亥俄大学学历证书+俄亥俄大学文凭证书+俄亥俄大学学位证书》Q微信741003700《俄亥俄大学学位证书复制》办理俄亥俄大学毕业证成绩单|购买...wyqazy
 
Call US Pooja 9892124323 ✓Call Girls In Mira Road ( Mumbai ) secure service,
Call US Pooja 9892124323 ✓Call Girls In Mira Road ( Mumbai ) secure service,Call US Pooja 9892124323 ✓Call Girls In Mira Road ( Mumbai ) secure service,
Call US Pooja 9892124323 ✓Call Girls In Mira Road ( Mumbai ) secure service,Pooja Nehwal
 
Chandigarh Call Girls Service ❤️🍑 9115573837 👄🫦Independent Escort Service Cha...
Chandigarh Call Girls Service ❤️🍑 9115573837 👄🫦Independent Escort Service Cha...Chandigarh Call Girls Service ❤️🍑 9115573837 👄🫦Independent Escort Service Cha...
Chandigarh Call Girls Service ❤️🍑 9115573837 👄🫦Independent Escort Service Cha...Niamh verma
 
Model Call Girl in Shalimar Bagh Delhi reach out to us at 🔝8264348440🔝
Model Call Girl in Shalimar Bagh Delhi reach out to us at 🔝8264348440🔝Model Call Girl in Shalimar Bagh Delhi reach out to us at 🔝8264348440🔝
Model Call Girl in Shalimar Bagh Delhi reach out to us at 🔝8264348440🔝soniya singh
 

Recently uploaded (7)

9892124323 | Book Call Girls in Juhu and escort services 24x7
9892124323 | Book Call Girls in Juhu and escort services 24x79892124323 | Book Call Girls in Juhu and escort services 24x7
9892124323 | Book Call Girls in Juhu and escort services 24x7
 
CALL ON ➥8923113531 🔝Call Girls Saharaganj Lucknow best sexual service
CALL ON ➥8923113531 🔝Call Girls Saharaganj Lucknow best sexual serviceCALL ON ➥8923113531 🔝Call Girls Saharaganj Lucknow best sexual service
CALL ON ➥8923113531 🔝Call Girls Saharaganj Lucknow best sexual service
 
CALL ON ➥8923113531 🔝Call Girls Gomti Nagar Lucknow best Night Fun service
CALL ON ➥8923113531 🔝Call Girls Gomti Nagar Lucknow best Night Fun serviceCALL ON ➥8923113531 🔝Call Girls Gomti Nagar Lucknow best Night Fun service
CALL ON ➥8923113531 🔝Call Girls Gomti Nagar Lucknow best Night Fun service
 
哪里有卖的《俄亥俄大学学历证书+俄亥俄大学文凭证书+俄亥俄大学学位证书》Q微信741003700《俄亥俄大学学位证书复制》办理俄亥俄大学毕业证成绩单|购买...
哪里有卖的《俄亥俄大学学历证书+俄亥俄大学文凭证书+俄亥俄大学学位证书》Q微信741003700《俄亥俄大学学位证书复制》办理俄亥俄大学毕业证成绩单|购买...哪里有卖的《俄亥俄大学学历证书+俄亥俄大学文凭证书+俄亥俄大学学位证书》Q微信741003700《俄亥俄大学学位证书复制》办理俄亥俄大学毕业证成绩单|购买...
哪里有卖的《俄亥俄大学学历证书+俄亥俄大学文凭证书+俄亥俄大学学位证书》Q微信741003700《俄亥俄大学学位证书复制》办理俄亥俄大学毕业证成绩单|购买...
 
Call US Pooja 9892124323 ✓Call Girls In Mira Road ( Mumbai ) secure service,
Call US Pooja 9892124323 ✓Call Girls In Mira Road ( Mumbai ) secure service,Call US Pooja 9892124323 ✓Call Girls In Mira Road ( Mumbai ) secure service,
Call US Pooja 9892124323 ✓Call Girls In Mira Road ( Mumbai ) secure service,
 
Chandigarh Call Girls Service ❤️🍑 9115573837 👄🫦Independent Escort Service Cha...
Chandigarh Call Girls Service ❤️🍑 9115573837 👄🫦Independent Escort Service Cha...Chandigarh Call Girls Service ❤️🍑 9115573837 👄🫦Independent Escort Service Cha...
Chandigarh Call Girls Service ❤️🍑 9115573837 👄🫦Independent Escort Service Cha...
 
Model Call Girl in Shalimar Bagh Delhi reach out to us at 🔝8264348440🔝
Model Call Girl in Shalimar Bagh Delhi reach out to us at 🔝8264348440🔝Model Call Girl in Shalimar Bagh Delhi reach out to us at 🔝8264348440🔝
Model Call Girl in Shalimar Bagh Delhi reach out to us at 🔝8264348440🔝
 

03 ft48923 en02gla0_general topics_

  • 1. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 1 Content 1 LAN and VLAN: some considerations 3 1.1 Definitions 4 1.2 Domains in a traditional LAN 5 1.3 Domains in a VLAN 9 1.4 Traffic separation by VLAN 12 1.5 Tagging 13 1.6 VLAN Aware / Unaware 21 1.7 Links Types 22 1.8 Q-in-Q 25 1.9 Spanning Tree Protocol (802.1d) 29 1.10 Rapid Spanning Tree Protocol RSTP (802.1w) 32 1.11 Multiple Spanning Tree Protocol MSTP (802.1s) 33 2 Carrier Ethernet: Some Concepts 39 2.1 What is Carrier Ethernet 39 2.2 MEF: Metro Ethernet Forum 40 2.3 Cooperation with Other Standard Bodies 42 2.4 IEEE: Institute of Electrical and Electronics Engineers 42 2.5 IETF: The Internet Engineering Task Force 42 2.6 ITU: International Telecommunication Union Telecommunication Standardization Sector 43 3 Carrier Ethernet Terminology 45 3.1 Basic Components 46 3.2 Carrier Ethernet Service Types 63 3.3 Circuit Emulation Services over Packet (CESoP) 64 3.4 FlexiPacket EVC and Services 71 4 Quality of Service in the HUB 75 4.1 QoS Mechanism 76 4.2 Classifier and Packet Marker 79 4.3 Policer 83 General Topics
  • 2. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 2 4.4 Buffer Manager: Congestion Avoidance 86 4.5 Queue Scheduler 89 5 Quality of service in the FlexiPacket Radio Rel.1.3 EP1 99 5.1 Quality of Service Mechanism 99 5.2 Classification 100 5.3 Egress Scheduling 102 6 Quality of service in the FlexiPacket MultiRadio Rel 2.1 103 6.1 Quality of Service Mechanism 103 6.2 QoS Classification Criteria 104 6.3 Egress Scheduling 104 7 Ethernet OAM 105 7.1 OAM Definition 106 7.2 OAM Layers 107 7.3 Ethernet Link Fault Management OAM (EFM OAM) 802.3ah 111 7.4 Connectivity Fault Management (CFM) – 802.1ag 112 7.5 Performance Monitoring - ITU-T Y.1731 120 7.6 E2E OAM – Ethernet AIS 124 7.7 Remote Defect Indication (RDI) 125 8 Network Synchronization 127 8.1 Introduction 128 8.2 Physical Layer Synchronization – Synchronous Ethernet (SyncE) 129 8.3 Timing-over-Packet (ToP) IEEE1588 v2 (official Title: Precision Time Protocol) 136 8.4 IEEE-1588 and Synchronous Ethernet 146 8.5 FlexiPacket Synchronization 148 9 CESoP Clock Recovery 151 9.1 Clock Recovery 152 9.2 CESoP with Differential Clock Recovery 153 10 Digital Radio Relay Signals 155 10.1 Quadrant Amplitude Modulation (QAM) 156 10.2 Filtered Spectrum 160 10.3 Adaptive Modulation 166
  • 3. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 3 1 LAN and VLAN: some considerations
  • 4. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 4 1.1 Definitions A LAN or Local Area Network is a computer network (or data communications network) which is confined in a limited geographical location. A Virtual (or logical) LAN is a local area network with a definition that maps workstations/PCs on some other basis than geographic location (for example, by department, type of user or primary application)
  • 5. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 5 1.2 Domains in a traditional LAN In a traditional Ethernet LAN, stations connected to the same media, share a domain. In this domain, every station hears broadcast frames transmitted by every other station. As the number of stations grows, contention and broadcast traffic increase a lot. At some point, the Ethernet becomes saturated. To operate efficiently, the LAN must be divided into smaller pieces. In a traditional LAN, stations are connected to each other by means of HUBS or REPEATERS. HUB HUB One collision Domain One Broadcast Domain Fig. 1 Domains in a traditional LAN (1)
  • 6. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 6 A BRIDGE (or a L2 SWITCH) is able to divide one collision domain in different collision domains. HUB HUB Two collision Domains One Broadcast Domain BRIDGE Fig. 2 Domains in a traditional LAN (2)
  • 7. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 7 A BRIDGE (or a L2 SWITCH) do not forward collisions, but allows broadcast and multicast passing through. Broadcast domain refers to a part of network where a single broadcast packet is transmitted to all segments of the network (i.e. ARP request, NETBIOS name request). This type of traffic, affects the whole network because each device receiving a broadcast frame must analyze it. If broadcast frames increases in frequency, available bandwidth decrease up to be exhaust (BROADCAST STORM). SWITCH = MULTIPORT BRIDGE L2 SWITCH Fig. 3 Domains in a traditional LAN (3)
  • 8. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 8 A ROUTER may be used to prevent Broadcast and Multicast from traveling through the network because it is able to segment a LAN in different Broadcast domains. HUB HUB Two collision Domains Two Broadcast Domain ROUTER Fig. 4 Domains in a traditional LAN
  • 9. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 9 1.3 Domains in a VLAN VLANs allow a network manager to logically segment a LAN into different broadcast domains without using routers. Bridging software is used to define which workstations are to be included in the broadcast domain. VLAN 2 Broadcast Damain VLAN 2 Broadcast Damain VLAN 1 Broadcast Domain VLAN 1 Broadcast Domain L2 SWITCH L2 SWITCH Fig. 5 Domains in a VLAN (1)
  • 10. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 10 ROUTERS are necessary only to make possible communication between different VLANs. VLAN IS A LOGICALLY DEFINED BROADCAST DOMAIN. VLAN 2 Broadcast Damain VLAN 2 Broadcast Damain VLAN 1 Broadcast Domain VLAN 1 Broadcast Domain L2 SWITCH L2 SWITCH ROUTER Fig. 6 Domains in a VLAN (2)
  • 11. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 11 The advantages of VLANs as regards to traditional LANs are shown in Fig. 7. Periodically, sensitive data may be broadcast on a network. Placing only those users who can have access to have access to that data on a VLAN can reduce the chances of an outsider gaining access to the data SECURITY Routers are only used to interconnect different broadcast domains REDUCED COSTS Simply moves, adds and changesSIMPLIFIED ADMINISTRATION Independent from the physical wiringVIRTUAL WORKGROUPS Better control of broadcastPERFORMANCE Fig. 7 Domains in a VLAN (3)
  • 12. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 12 1.4 Traffic separation by VLAN With VLANs it is possible to separate different logical networks on one physical infrastructure supporting the traffic separation. Figure Fig. 8 shows a Traffic Separation Example by VLAN. RNC Ethernet Network Flexi BTS Nr.1 Flexi BTS Nr.2 VLAN1 -> Voice from Flexi BTS Nr.1 to RNC Traffic over same physical port separated by VLAN. VLAN2 -> Data from Flexi BTS Nr.1 to RNC VLAN4 -> Data from Flexi BTS Nr.1 to RNC VLAN3 -> Voice from Flexi BTS Nr.2 to RNC Fig. 8 Traffic separation by VLAN
  • 13. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 13 1.5 Tagging Tagging is a process used to identify the VLAN originating. The VLAN tagging scheme in 802.1q results in four bytes of information being added to the frame following the source address and preceding the type/length field. This increases the maximum frame size in Ethernet to 1522 bytes. Fig. 9 reports a IEEE 802.3 untagged frame Fig. 10and Fig. 11 explain the TAG fields. MAC DA 6 bytes Payload 46-1500 bytes FCS 4 bytes Basic IEEE 802.3 Ethernet Frame: minimum length 64 bytes, maximum length 1518 bytes Destination & Source MAC Addresses: The Destination MAC Address field identifies the station or stations that are to receive the frame. The Source MAC Address identifies the station that originated the frame. A Destination Address may be a unicast destined for a single station, or a "multicast address" destined for a group of stations. A Destination Address of all 1 bits refers to all stations on the LAN and is called a "broadcast address". Length/Type: If the value of this field is less than or equal to 1500, then the Length/Type field indicates the number of bytes in the Payload field. If the value of this field is greater than or equal to 1536, then the Length/Type field indicates protocol type. Payload (MAC Client Data): This field contains the data transferred from the source station to the destination station or stations. Frame Check Sequence: This field contains a 4-byte cyclical redundancy check (CRC) value used for error checking. MAC SA 6 bytes Length/Type 2 bytes VLAN tags may be added here Preamble +SD 8 bytes Interframe Gap 12 bytes 64-1518 bytes Fig. 9 IEEE 802.3 Untagged Frame
  • 14. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 14 C F I 16 bits TAG Protocol Identifier TPID 0x8100 1bit 12 bits3bits Priority VLAN ID TCI Tag Control Identifier TPID TAG Protocol Identifier 2 bytes2 bytes 4 bytes IEEE 802.3 Frame without VLAN Tag Header IEEE 802.3 with 802.1Q 4-Byte VLAN Tag Header User priority (Priority Code Point PCP) CFI (Canonical format identifier) VLAN ID <= 4094) 4 bytes are added in the Ethernet frame between the MAC Source Address and the Type-Field. 802.1Q – VLAN (single tagged) MAC DA 6 bytes Payload 48-1500 bytes FCS 4 bytes MAC SA 6 bytes Length/Type 2 bytes Preamble +SD 8 bytes Interframe Gap 12 bytes Payload 48-1500 bytes FCS 4 bytes Length/Type 2 bytes Interframe Gap 12 bytes MAC DA 6 bytes MAC SA 6 bytes Preamble +SD 8 bytes TPID TCI Fig. 10 802.1Q Single Tagged Frame (1)
  • 15. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Is used to uniquely identify the VLAN to which the frame belongs. There can be a maximum of 212 -1 VLANs. Zero is used to indicate no VLAN ID Vlan IDentifier Always 0 if Ethernet.It is used to make compatibility between Ethernet and Token Ring Canonical Format Indicator It allows priority information to be encoded in the frame. Eight levels of priority are allowed Priority Code Point (PCP) It Indicates that it will follow a 802.1q TAG and not the payload; the Default TPID value in IEEE 802.1Q, is 0x8100 Tag Protocol IDentifier DESCRIPTIONTC FIELD Fig. 11 802.1Q Single Tagged Frame (2)
  • 16. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 16 1.5.1 Class of Service (CoS) IEEE 802.1p The IEEE 802.1p provides a standard and interoperable way to set the priority bits in a frame’s header and to map these settings to TRAFFIC CLASSES. There are 8 TRAFFIC CLASSES (3 Bits) according to the table reported in Fig. 12. 000BEBEST EFFORT 001BKBACKGROUND 010RRESERVRD FOR FUTURE USE 011EEEXCELLENT EFFORT TRAFFIC 100CLCONTROLLED LOAD TRAFFIC 101VIVIDEO TRAFFIC 110VOVOICE TRAFFIC 111NCNETWORK CONTROL TRAFFIC Fig. 12 Quality Of Service IEEE 802.1p (1) WARNING Of course, network operators may choose to implement traffic differentiation on a per VLAN-ID basis rather than using the three CoS bits.
  • 17. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 17 The TRAFFIC CLASSES are assigned to separate queues with different priorities. Traffic classes queues map to outgoing Priority bits Fig. 13 Quality Of Service IEEE 802.1p (2) If a switch provides 8 queues for the 8 priorities settings, each queue will store frames with a specific priority setting to provide complete differentiated services. Fig. 14 Switch with 8 queues; each priority has one queue
  • 18. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 18 FlexiPacket First Mile 200, HUB 800 and FlexiPacket MultiRadio have 8 queues and the association between PCP and Priority Queue is reported in Fig. 15. FPFM-200/HUB- 800/FPMR Priority Queue PCP Fig. 15 FPFM-200/HUB 800/FPMR PCP - Priority queues association
  • 19. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 19 To minimize costs, however, fewer queues may be provided in such switches. Frames from several priority settings may be stored together in one queue. Fig. 16 Switch with less than 8 queues; more than one priority in one queue
  • 20. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 20 When 4 queues are available, like in the FlexiPacket ODU, the 8 PCPcodes could be associated to four priority values as reported in Fig. 17 (FlexiPacket ODU default). 37 26 25 24 13 12 01 00 Queue Priority Value PCP Fig. 17 FlexiPacket ODU Priority Code Point Configuration When 5 queues are available, like in FlexiPacket HUB 2200/1200, the 8 PCP codes could be associated to five priority values as reported in Fig. 16 (HUB 1200/2200 configuration). 47 36 25 24 13 12 01 00 Queue Priority Value PCP Fig. 18 FlexiPacket HUB (2200/1200) Priority Code Point Configuration
  • 21. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 21 1.6 VLAN Aware / Unaware VLAN AWARE If the data is to go to a device that knows about VLAN implementation (VLAN Aware), the VLAN identifier is added to the data. VLAN UNAWARE If it is to go to a device that has no knowledge of VLAN implementation (VLAN Unaware), the BRIDGE sends the data without the VLAN identifier. TAG added/removed TAGTAG FrameFrame TAGTAG FrameFrame TAGTAG FrameFrame FrameFrame FrameFrame FrameFrameFrameFrameFrameFrame FrameFrame TAG added/removed L2-Switch L2-Switch VLAN aware Bridge/L2-Switch VLAN aware VLAN unaware stations Bridge/L2-Switch Fig. 19 VLAN Aware/Unaware
  • 22. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 22 1.7 Links Types Devices on a VLAN can be connected in three ways based on whether the connected devices are VLAN Aware or VLAN Unaware as reported in Fig. 20, Fig. 21, Fig. 22. Recall that a VLAN aware device is one which understands VLAN memberships (i.e. which users belong to a VLAN) and VLAN formats. This is a combination of the previous two links. This is a link where both VLAN aware and VLAN Unaware devices are attached. A hybrid link can have both tagged and untagged frames, but all the frames for a specific VLAN must be either tagged or untagged. Hybrid Link An access link connects a VLAN Unaware device to the port of a VLAN Aware Bridge. Access Link All the devices connected to a trunk link, including workstations, must be VLAN Aware. All frames on a trunk link must have a special header attached. These special frames are called TAGGED FRAMES. Trunk Link DESCRIPTIONLINK TYPE Fig. 20 Link Types
  • 23. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . L2-Switch L2-Switch Trunk Link Trunk Link VLAN-aware Workstation VLAN-aware Bridge/L2-Switch VLAN-aware Bridge/L2-Switch Fig. 21 Trunk Link
  • 24. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 24 L2-Switch Access Link VLAN-unaware Device VLAN-aware Bridge/L2-Switch Fig. 22 Access Link
  • 25. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 25 1.8 Q-in-Q In the VLAN tag field defined in IEEE 802.1Q, only 12 bits are used for VLAN IDs, so a device can support a maximum of 4,094 VLANs. In actual applications, however, a large number of VLAN are required to isolate users, especially in metropolitan area networks, and 4,094 VLANs are far from satisfying such requirements. The so called Q-in-Q (IEEE 802.1ad) feature enables the encapsulation of double VLAN tags within an Ethernet frame, with the inner VLAN tag being the customer network VLAN tag while the outer one being the VLAN tag assigned by the service provider to the customer. In the backbone network of the service provider (the public network), frames are forwarded based on the outer VLAN tag only, while the customer network VLAN tag is shielded during data transmission. The Q-in-Q feature enables a device to support up to 4,094 x 4,094 VLANs. DA SA DA SA DA SA LEN/ Etype Data FCS TPID TAG LEN/ Etype Data FCS TPID TAG LEN/ Etype Data FCSTPID TAG Untagged Ethernet Frame Service Provider Tagging Customer Tagging 6 6 2 446 to 1500 2 2 2 2 Bytes Single Tagged Ethernet Frame Double Tagged Ethernet Frame Fig. 23 Untagged, Single Tagged and Double Tagged Ethernet Frames
  • 26. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 26 Double TAG VLAN Tag Control Identifier (TCI) is reported in Fig. 24 DA SA TPID TAG LEN/ Etype Data FCSTPID TCI 2 2 Double Tagged Ethernet Frame User Priority Priority Code Point DEI S-VID Service V-LAN Identifier 3 bits 1 bit 12 bits 1 bit Drop Eligible Indicator → drop first, if congestion occurs Fig. 24 Double TAG VLAN Tag Control Identifier
  • 27. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 27 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Double Tag Example S-VLAN 2 C-VLAN 2 A D C E B 2 3 4 S-VLAN 2 C-VLAN 2 Swap outer with 4 and forward to D- port 2 221 Forwarding DecisionVLAN Outer Tag VLAN Inner Tag A-Port S-VLAN 2 C-VLAN 2 x 1S-VLAN 4 C-VLAN 2 1 2 S= Service Provider C= Customer Fig. 25 Double TAG Example
  • 28. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 28 1.8.1 Q in Q TPID The QinQ frame contains the modified tag protocol identifier (TPID) value of VLAN Tags. By default, the VLAN tag uses the TPID field to identify the protocol type of the tag. The value of this field, as defined in IEEE 802.1Q, is 0x8100. The device determines whether a received frame carries a service provider VLAN tag or a customer VLAN tag by checking the corresponding TPID value. After receiving a frame, the device compares the configured TPID value with the value of the TPID field in the frame. If the two match, the frame carries the corresponding VLAN tag. For example, if a frame carries VLAN tags with the TPID values of 0x88a8 and 0x8100, respectively, while the configured TPID value of the service provider VLAN tag is 0x88a8 and that of the VLAN tag for a customer network is 0x8200, the device considers that the frame carries only the service provider VLAN tag but not the customer VLAN tag. In addition, the systems of different vendors might set the TPID of the outer VLAN tag of QinQ frames to different values. For compatibility with these systems, you can modify the TPID value so that the QinQ frames, when sent to the public network, carry the TPID value identical to the value of a particular vendor to allow interoperability with the devices of that vendor. The TPID in an Ethernet frame has the same position with the protocol type field in a frame without a VLAN tag.
  • 29. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 29 1.9 Spanning Tree Protocol (802.1d) In order to increase the availability may be useful to introduce redundancy. In presence of simultaneous alternative paths, copies of frames are created producing the so called LOOPS. In order to avoid loops, a SPANNING TREE algorithm must be implemented to disable some bridge interfaces. Spanning Tree Protocol (STP) is a link manager protocol that provides path redundancy while preventing loops in the network. STP algorithm creates a tree topology, and loop free path from the root to all of the nodes in the LAN. 1.9.1 Spanning Tree Root bridge selection The bridges exchange Configuration Bridge Protocol Data Units (BPDU’s) in order to learn the topology of the network. A root bridge is selected according to MAC or priority. A lowest cost path to the root is chosen, and redundant links are blocked. Root Bridge = blocked links Fig. 26
  • 30. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 30 In case of link failure, BPDU’s are again exchanged in the network to notify tree of the topology change. Redundant routes are enabled. Root Bridge Fig. 27
  • 31. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 31 1.9.2 Spanning Tree Port roles Spanning Tree port roles are: • Root port: pointing towards the root bridge. • Designated port: active ports that aren’t root ports. • Alternate port: one side of a blocked link (the other side is designated). Root Bridge R R R R D D D D D D A A Fig. 28
  • 32. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 32 1.9.3 Spanning Tree Port states Spanning Tree Port states are: • Forwarding: all frames are forwarded on the port. • Discarding: all user data is dropped. BPDUs are forwarded. • Learning: Port is still inactive, but learns MAC addresses. Root BridgePort role: Root Port state: Forwarding Port role: Root Port state: Forwarding Port role: Alternate Port state: Discarding Fig. 29 1.10 Rapid Spanning Tree Protocol RSTP (802.1w) Regular STP (802.1d) provides very slow failure recovery time: 30-60 sec. Thus the STP mechanism was improved, and a new protocol was published: RSTP (802.1w). RSTP offers ~1 sec failure recovery time.
  • 33. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 33 1.11 Multiple Spanning Tree Protocol MSTP (802.1s) The 802.1D and 802.1w spanning tree protocols operate without regard to a network’s VLAN configuration, and maintain one common spanning tree throughout a bridged network. These protocols map one loop-free, logical topology on a given physical topology. In a VLAN environment, the problem could be put in evidence considering the Fig. 30. The figure shows a network of two switches with two configured VLANs. If the switches are running STP or RSTP, all the links for VLAN 2 would be blocked. This is because both STP and RSTP support only a single spanning tree for the whole network and block the redundant links. The above situation can be rectified by using MSTP. The 802.1s Multiple Spanning Tree protocol (MSTP) uses VLANs to create multiple spanning trees in a network, which significantly improves network resource utilization while maintaining a loop-free environment. 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 VLAN 1 VLAN 2 X X Switch 1 (root Bridge) Switch 2 Fig. 30 Example of two switches with two configured VLANs
  • 34. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 34 1.11.1 Multiple spanning tree concepts MST Instance (MSTI) MSTP enables the grouping and mapping of VLANs to different spanning tree instances each with a different root bridge. A MST Instance (MSTI) is a particular set of VLANs that are all using the same spanning tree. Spanning tree of MSTI= 1 containing vlans 1, 2, 3, 4 Spanning tree of MSTI= 2 containing vlans 5, 6, 7, 8 Spanning tree of MSTI= 3 containing vlans 9, 10, 11, 12 Same Physical connection Root Bridge Root Bridge Root Bridge Fig. 31 Different spanning trees created by different MSTIs on the same physical layout
  • 35. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 35 Regions A MST region is a set of interconnected switches that all have the same values for the following parameters: • MST configuration name: the name of the MST region • Revision level: the revision number of configuration (The revision level is an arbitrary number that you assign to a MST region. It can be used to keep track of the number of times that MST configuration has been updated for the network. If the revision level is not set explicitly by the command, the default revision level value will be 0. • Configuration Digest: the mapping of which VLANs are mapped to which MST instances Each MST instance created is identified by an MSTI number. This number is locally significant within the MST region. Therefore, a MSTI will not span across MST regions. MSTI1 MSTI2 MSTI3 MSTI4 MSTI2 MSTI4 The MSTI2 in Region 1 is unrelated to the MSTI2 in Region 3 and the MSTI4 in Region 2 is unrelated to the MSTI4 in Region 3. Region 1 Region 2 Region 3 Same Physical Connection Fig. 32 MSTIs in different regions
  • 36. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 36 Common and Internal Spanning Tree (CIST) The CIST is the default spanning tree instance of MSTP, i.e. all VLANs that are not members of particular MSTIs are members of the CIST. Also, an individual MST region can be regarded a single virtual bridge by other MST regions. The spanning tree that runs between regions is the CIST. The CIST is also the spanning tree that runs between MST regions and Single Spanning Tree (SST) entities. So, in Fig. 33, the STP that is running between the regions, and to the Single Spanning Tree bridges, is the CIST. MSTP Region 1 MSTP Region 2 MSTP Region 3 Switch non MSTP capable Switch non MSTP capable Switch non MSTP capable = CIST Fig. 33 Common and Internal Spanning Tree (CIST)
  • 37. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 37 Returning now to the example of Fig. 30, the problem can be solved mapping VLAN 1 and VLAN 2 to different MSTIs. The MSTP configures separate spanning tree for VLANs 1 and 2 and blocks the redundant links for VLAN 2. 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 VLAN 1 VLAN 2 X Switch 1 (root Bridge) Switch 2 MSTI1= VLAN1 MSTI2= VLAN2 Fig. 34 Active topologies for MSTI 1 and MSTI 2 1.11.2 Load Balancing We have seen that with MSTP, each spanning tree instance can include one or more VLANs and applies a separate, per-instance forwarding topology. This means that where a port belongs to multiple VLANs, it may be dynamically blocked in one spanning tree instance, but forwarding in another instance. This achieves load-balancing across the network while keeping the switch’s CPU load at a moderate level (by aggregating multiple VLANs in a single spanning tree instance).
  • 38. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 38
  • 39. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 39 2 Carrier Ethernet: Some Concepts 2.1 What is Carrier Ethernet Carrier Ethernet is the use of high-bandwidth Ethernet technology for Internet access and for communication among business, academic and government local area networks (LANs). The use of Carrier Ethernet technology within a metropolitan area network (MAN) is known as Metro Ethernet. Fig. 35 What's Carrier Ethernet
  • 40. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 40 2.2 MEF: Metro Ethernet Forum The Metro Ethernet Forum (MEF) is a global industry alliance comprising more than 145 organizations. Nokia Siemens Network is part of the MEF The MEF develops technical specifications and implementation agreements to promote interoperability and deployment of Carrier Ethernet worldwide. Fig. 36 MEF
  • 41. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 41 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fig. 37 Nokia Siemens Networks is part of the MEF
  • 42. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 42 2.3 Cooperation with Other Standard Bodies The goal of the MEF is to create Implementation Agreements (IAs) that leverage existing standards defined by other organizations such as IEEE, ITU-T and IETF rather than creating competing standards. Where necessary, the MEF will: • make recommendations to existing standards bodies. MEF has liaisons to IEEE and ITU-T. MEF also works closely with IETF. • As a last resort, create standards that are not being developed by other standards bodies. 2.4 IEEE: Institute of Electrical and Electronics Engineers The IEEE, a non- profit organization, is the world's leading professional association for the advancement of technology. The IEEE is a leading developer of international standards that underpin many of today's telecommunications, information technology and power generation products and services. 2.5 IETF: The Internet Engineering Task Force The IETF is the principal body engaged in development of new Internet standard specifications. It is a large open international community of network designers, operators, vendors and researchers concerned with the evolution of the Internet Architecture and the smooth operation of the Internet. Its mission includes: • identifying and proposing solutions to operational and technical problems in the Internet; • specifying the development or usage of protocols and near-term architecture to solve such technical problems for the Internet; • making recommendations to the Internet Engineers Steering Group (IESG) regarding the standardization of protocols and protocol usage in the Internet; • Providing a forum for the exchange of information within the Internet community between vendors, users, researchers, agency contractors and network managers.
  • 43. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 43 2.6 ITU: International Telecommunication Union Telecommunication Standardization Sector The ITU is an international organization under the United Nations within which government and the private sector coordinate global telecom networks and services. ITU-T: Telecommunication Standardization Sector The main products of ITU-T are the Recommendations. At present, more than 3,000 Recommendations (Standards) are in force. Recommendations are standards that define how telecommunication networks operate and interwork. ITU-T Recommendations are non-binding, however they are generally complied with due to their high quality and because they guarantee the interconnectivity of networks and enable telecommunication services to be provided on a worldwide scale.
  • 44. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 44
  • 45. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 45 3 Carrier Ethernet Terminology
  • 46. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 46 3.1 Basic Components UNI, EVC and NNI are the Fundamental Constructs of an Ethernet Service 3.1.1 The User Network Interface (UNI) The UNI is the physical interface or port that is the demarcation between the customer and the service provider. The UNI is always provided by the Service Provider The UNI in a Carrier Ethernet Network is a physical Ethernet Interface at operating speeds 10Mbs, 100Mbps, 1Gbps or 10Gbps. CE: Customer Equipment, UNI: User Network Interface. MEF certified Carrier Ethernet products Carrier Ethernet Network UNIUNI CECE Fig. 38 User Network Interface
  • 47. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 47 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Network to Network Interface (NNI) NNI is the demarcation between carrier Ethernet networks operated by one or more carriers UNI: User Network Interface, UNI-C: UNI-customer side, UNI-N network side NNI: Network to Network Interface, E-NNI: External NNI; I-NNI Internal NNI Service Provider 1 Carrier Ethernet Network CECE UNIUNI Subscriber Site ETH UNI-C ETH UNI-C ETH UNI-N ETH UNI-N ETH UNI-N ETH UNI-N ETH E-NNI ETH E-NNI ETH UNI-C ETH UNI-C UNIUNI CECE I-NNII-NNI E-NNIE-NNI Service Provider 2 I-NNII-NNI ETH E-NNI ETH E-NNI Subscriber Site Fig. 39 UNI and NNI Interfaces
  • 48. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 48 3.1.3 FlexiPacket UNI / NNI ports In the FlexiPacket Indoor Unit, each Ethernet port (both copper and fiber) can be configured either as UNI (User to Network Interface) or NNI (Network to Network Interface). As default, all ports are configured as NNI. Fig. 40 illustrates a generic network scenario in which UNI and NNI interfaces are highlighted. IDU -- 1 NNIUNI3rd party IDU - N 3rd party NNI network UNI Access to Network Network to AccessNetwork to Network End-to-end connection Fig. 40 User to Network and Network to Network Interfaces In order to provide end-to-end connections, mapping criteria are required at each interface boundary: Incoming packet arriving at the UNI port is mapped to a specific connection, which is identified by VLAN. The mapping operation is done once per packet in the network. After packet is mapped and tagged (VLAN), it already has its association to the service, and on the next hopes (NNI port) mapping is not needed.
  • 49. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 49 FlexiPacket Radio ODUs are connected to A2200/A1200/First Mile IDUs by either UNI or NNI ports, as illustrated in Fig. 41, Fig. 42 and Fig. 43. IDU NNI 3rd party IDU 3rd party IDU 3rd party NNI NNI - NNI A2200/1200 network NNI UNI UNI UNI Fig. 41 FlexiPacket Radio –IDU connections by UNI/NNI ports (1) 3rd party FPR IDU 3rd party UNI UNI NNI FPRFPR Fig. 42 FlexiPacket Radio –IDU connections by UNI/NNI ports (2)
  • 50. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 50 network IDU NNI BTS FPR FPR UNI Fig. 43 FlexiPacket Radio –IDU connections by UNI/NNI ports (3)
  • 51. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 51 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  • 52. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 52
  • 53. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 53 UNI Interface functions Here below are reported the UNI functions • Mapping: performed on the incoming traffic in order to identify the connection it is associated to. Mapping functionality allows associating to all incoming traffic a specific VLAN ID identifying the EVC. The mapping is based on configurable mapping rules, different for each equipment and software releases. WARNING Please refer yourself to the "HUB Structure chapter" for further details about mapping TIP Once the mapping has been performed, all the incoming traffic has been associated to a specific EVC. This means that the VLAN tag associated to the Carrier Ethernet service is appended to each frame and it is used across the entire Carrier Ethernet network for delivering the frame towards the destination. This tag is called S-tag. • Manipulation: Manipulation is configurable per EVC. The configuration foresees two options: VID preservation: transparent transport of the incoming frames; no modifications are performed on the incoming frame; in egress the S-VID is removed thus the frame come out the original C-tag; VID translation: removal of the C-tag of the incoming traffic (if present): in case of tagged frames the tag of the incoming frames is overwritten by S-tag; this functionality allows modifying the frame format from that one received at the UNI to a new one suitable for the treatment inside the network. WARNING Please refer yourself to the HUB Structure chapter for further details about Manipulation • Marking / Policing: the ingress traffic is marked by using 3 bits (Priority Code Point) for defining priority and color. WARNING Please refer yourself to the HUB Structure chapter for further details about Marking and Policing. • Congestion Management: mechanism used for congestion avoidance by randomly dropping packets according to congestion level (queue fill level), color and priority. WARNING Please refer yourself to the QoS chapter for further details about Congestion Management
  • 54. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 54 • Queuing, Shaping (per port) and Scheduling  5 queues per port in A1200/A200 and 8 queues in FPFM 200/HUB 800  both Strict Priority (SP) and Weighted Round Robin (WRR) are mixed for scheduling WARNING Please refer yourself to the QoS chapter for further details about Queuing and Scheduling • Per Hop Behavior decoding: by configuration it is possible to replace Priority Code Point bits with new values in order to give different marking.
  • 55. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 55 NNI Interface functions Here below are reported the UNI functions: • Congestion Management • Queuing, shaping (port) and scheduling • Per Hop Behavior (PHB) Decoding: by configuration it is possible to replace PCP bits with new values in order to give different marking. The egress traffic flowing from the network to the access is already mapped to a specific service. Therefore the mapping function is no more needed.
  • 56. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 56 3.1.4 Ethernet Virtual Connection (EVC) The EVC is the Logical representation of an Ethernet service as defined by the association between 2 or more UNIs. It permits to transfer Ethernet Frames from one site to another one. The EVC prevents data transfer between sites that are not part of the same EVC They are typically distinguished by VLAN tags or Q-in-Q. Three types of EVCs are defined by MEF as reported in Fig. 44, Fig. 45 and Fig. 46: • Point-to-Point, • Multipoint-to-Multipoint, • Rooted Multipoint (Point-to-Multipoint) Point-to-Point EVC Carrier Ethernet Network CECE UNIUNI CECE UNIUNI CECE UNIUNI ISP POP UNIUNI Storage Service Provider Internet Fig. 44 Point to Point EVC
  • 57. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 57 Multipoint-to-Multipoint EVC Carrier Ethernet Network CECE UNIUNI CECE UNIUNI Carrier Ethernet Network Fig. 45 Multipoint to Multipoint Service Multiplexed Ethernet UNI Point-to-Multipoint EVC Carrier Ethernet Network CECE UNIUNI UNIUNI UNIUNI CECE UNIUNI CECE Fig. 46 Point to Multipoint EVC
  • 58. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 58
  • 59. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 59 3.1.5 EVC Basic Service Attributes Details regarding the EVC include: • Bandwidth profiles • Class of Service (CoS) Identification • Service Performance • Frame Delay (Latency) • Frame Delay Variation (Jitter) 3.1.5.1 Definition Bandwidth Profiles parameters for policing 4 main parameters are defined to determine the Bandwidth Profiles: two bandwidth limits—CIR and EIR—and two burst sizes— CBS and EBS. CIR Committed Information Rate: the average rate up to which Service Frames are delivered per the service performance parameters. The CIR is an average rate because all Service Frames are always sent at the UNI speed, e.g., 10Mbps, and not at the CIR, e.g., 2Mbps. EIR Excess Information Rate specifies the average rate up to which Service Frames are admitted into the provider’s network. The EIR is an average rate because all Service Frames are sent at the UNI speed, e.g., 10Mbps, and not at the EIR, e.g. 8Mbps. PIR Peak Information Rate: = CIR + EIR CBS Committed Burst Size: is the maximum number of bytes (e.g. 2K bytes) allowed for incoming packets to burst above the CIR, but still be marked green. EBS Excess Burst Size: is the maximum number of bytes (e.g. 2K bytes) allowed for incoming packets to burst above the EIR and are marked yellow. When the burst size has been exceeded, packets above the EIR are marked red.
  • 60. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 60 3.1.5.2 Color Marking A way to describe Service Frames when their average rate is in profile or out of profile is using the colors according to the Fig. 47 Green = conformant to CIR bandwidth profile Yellow = conformant to EIR bandwidth profile. Yellow packets have higher drop elegibility (will be dropped first in case of congestion). Performance requirements delay, jitter and loss are not applied to yellow packets within transport network Red = not conformant and discarded immediately. CIR Conformant Traffic ≤ CIR EIR Conformant Traffic ≥ CIR No traffic Traffic ≥ EIR Fig. 47 Color Marking TIP See more in MEF10.1, section 7.11
  • 61. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 61 EVC-1 CIR EIR EVC-2 C IR EIR EVC-3 CIREIR Fig. 48
  • 62. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 62 3.1.6 Three Types of Bandwidth Profiles MEF defines three Bandwidths profiles as reported in the example of Fig. 49 Fig. 49 Bandwidths Profiles
  • 63. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 63 3.2 Carrier Ethernet Service Types Using the EVCs it's possible to support the Ethernet Services Three Ethernet Service types are available as reported in Fig. 50: • E-Line Service Type • E-LAN Service Type • E-Tree Service Type E-LINE E-LAN E-TREE Fig. 50 Carrier Ethernet Service Types
  • 64. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 64 3.3 Circuit Emulation Services over Packet (CESoP) Circuit Emulation Services Enables TDM Services to be transported across Carrier Ethernet network, re-creating the TDM circuit at the far end. They run on a standard Ethernet Line Service (E-Line). TDM Circuits (e.g. T1/E1/STM Lines) Carrier Ethernet Network TDM Circuits (e.g. T1/E1/STM Lines) Circuit Emulated TDM Traffic Fig. 51 Circuit Emulation Services
  • 65. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 65 3.3.1 Standards Different standards are available to provide the transport of a TDM service, typically an E1/T1, through a bridged/routed packet network: • IETF RFC5086 (CESoPSN). • IETF RFC5087 (TDMoIP), • IETF RFC4553 (SAToP) • MEF8 (CESoETH). The standard adopted by the 1st release of the FlexiPacket Radio product family was the RFC5086. WARNING FM200 and HUB800 release 2 are able to support CESoPSN and SAToP NSN FlexiPacket IDUs provide the Interworking Function (IWF) to support the initiation and termination of a CESoPSN / SAToP service. The ODU just provide prioritized transport of the packet flows related to the CES service. CESoPSN Internet Working Function (IWF) Fig. 52 Internet Working Function
  • 66. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 66
  • 67. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 67 3.3.2 Pseudowire Pseudowire is a mechanism that emulates the attributes of a TDM service such as an E1, T1 or a fractional nx64 TDM service over a Packet switched network (PSN) TDM pseudowire has to support: • Packetization and Encapsulation of TDM Traffic • Packet Delay Variation (PDV) attenuation • Frame Loss and Out-of Sequence Packets • Clock recovery and Synchronization Packetization and Encapsulation Packetization refers to the process of converting the PDH or SONET/SDH bit stream into Ethernet frames. Specific packet connectivity information is dependent on the type of PSN: Ethernet, MPLS or IP. The encapsulation process places a pseudowire control word in front of the TDM data in order to define the format identifier, to support error flags, length and sequence number (see "Frame Loss and Out-of Sequence Packets" point). E1/T1 Frame E1/T1 FrameEthernet Frames Ethernet Frames Packet Switched Network Header
  • 68. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 68 Packet delay variation (PDV) is mainly due to the variable load conditions of network elements and interfaces, randomly occurring in the network. Although priority-based schedulers are implemented in each network element of the FlexiPacket products, still a delay variation is present for high priority packets (such as CESoP packets) passing through a network element. The packet delay variation is compensated by the “playout buffer” located in the receiving IWF. The basic criterion for dimensioning the playout buffer is to estimate the overall “packet delay variation” of the network between the initiating and the terminating CESoPSN IWF and to assign the receiving IWF a buffer size more than twice the estimated packet delay variation. Actually the packet delay variation is defined as the difference between the maximum delay of the CESoP packets to be supported without impairments (i.e. without errors or out-of-service conditions on the E1 stream) and their minimum delay. For what concerns the estimation of the total E1 end-to-end delay this will correspond to the network delay of CESoP packets added to the delay provided by the playout buffer. WARNING The "playout buffer" dimensioning is calculated by means of a proper tool. Please refer yourself to the Annex for detailed information about that. Frame Loss and Out-of Sequence Packets Frames may occasionally not arrive in the order in which they were sent out. In some cases, the frames may arrive very late or not at all, resulting in frames being discarded. TDM and SONET/SDH networks don't have the concepts of resending frames hence such frames are considered lost if they are not received within the window of the jitter buffer at the destination. The destination must have the ability to re-sequence the arriving frames. This is achieved through the use of sequence numbers within the headers.
  • 69. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 69 Clock recovery and Synchronization In the PDH network, the difference between in clock frequencies between TDM links is compensated for using bit stuffing technologies. With a packet network, that connection between the ingress and egress frequency is broken, since the packets are discontinuous in time. The consequence of a long-term mismatch in frequency is that the queue at the egress of the packet network will either fill up or empty. For this reason particular techniques such as "Differential Clock Recovery" and "Adaptive Clock Recovery" must be implemented. WARNING About Clock recovery and synchronization please, refer to the chapter "Synchronization"
  • 70. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 70 Different pseudowires are available according to the different standards: CESoPSN (Circuit Emulation over PSN) Pseudowire CESoPSN Pseudowire is able to transmit emulated structured TDM signals. That is it can identify and process the frame structure and transmit signaling in TDM frames A benefit of CESoPSN is that unused timeslots are not transported in the payload, thereby saving on bandwidth. CESoPSN provides three encapsulation modes: • IP/UDP (IP over User Datagram Protocol : solution actually adopted in FlexiPacket • MPLS (Multi-Protocol Label Switching) • L2TPv3 (layer 2Tunneling Protocol Version 3: alternative protocol to MPLS) TDMoIP Pseudowire The main difference between TDMoIP and CESoPSN is that the first packetizes TDM data in multiples of 48 bytes while the second uses multiples of the TDM frame itself. TDMoIP provides the same encapsulation modes as CESoPSN and the pure Ethernet encapsulation SAToP (Structure Agnostic TDM over Packet) Pseudowire SAToP differs from the previous Pseudowires technologies because it treats the TDM traffic as a data stream and ignores the framing or the timeslots. SATOP provides the same encapsulation modes as CESoPSN CESoETH (CES over Ethernet) Pseudowire CESoETH define TDM Circuit Emulation packets encapsulated by bare Ethernet. Emulated TDM CS data is distinguished based on the Emulated Circuit Identifier (ECID).
  • 71. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 71 3.4 FlexiPacket EVC and Services NSN FlexiPacket IDUs provide Ethernet Virtual Connections (EVC), each one associated to a service. Each service initiates at the ingress and terminates at the egress of a network, running over both NNI and UNI ports. WARNING Since the mapping of traffic into connections / services is performed on UNI ports only, both the initiation and termination of a service is possible on UNI ports only (see Fig. 54). NNIUNI3rd party 3rd party NNI network UNI Access to Network Network to Network End-to-end connection FlexiPacket IDU FlexiPacket IDU Access to Network Fig. 54 User to Network and Network to Network Interfaces Three types of Services are supported by FlexiPacket IDU: • CESoP (Circuit Emulation Service over Packet) • SAToP (Structure Agnostic TDM over Packet; it's implemented in FM200 R2.0 and HUB800 R2.0) • E-line  it is based on point-to-point EVC, running end-to-end between UNI ports. A unique VLAN ID is reserved in the network to identify each E- line service. • E-LAN  it is based on multipoint-to-multipoint EVC. In A1200 and A2200 Release 4.5, only one management E-LAN can be defined and it identifies the management domain between FPR and A2200/A1200 devices. A unique VLAN ID, VIDMGT, is reserved for the management E- LAN service (default value = 127). Forwarding is based on bridge functionality. Destination MAC address is used to reach the target.
  • 72. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 72 WARNING In FPH-A1200 Release 5.0 drop 2, only one E-LAN can be configured and it is reserved for the management/DCN service. By default, this service is identified by (VLAN ID=127). In FPH-2200 Release 5.0 is also possible to manage E-LAN services via CLI and Web UI. WARNING In FPFM-200 and HUB 800, both E-Lines and E-LANs can be configured; one E- LAN is reserved for the management/DCN service. By default, this service is identified by (VLAN ID=127). In Fig. 55, E-Lines and E-LAN (management) examples are shown. At UNI: • Mapping of traffic to the Service • Assignment to a Class of Service • Policing (CIR /EIR) according to SLA • CE-VLAN manipulation (transparent/translation) At NNI: • Traffic of a Service is identified by a VLAN ID NNI UNI UNI DCN Untagged frames 3rd party untagged frames UNI 3rd party E-line 1 UNI 3rd party NNI NNI E-line 2 E-line 3 E-line 4 NNI Packet network E-LAN NMS IDU IDU IDU Fig. 55 FlexiPacket E-Lines and E-LAN Example
  • 73. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 73 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . In Fig. 56, FlexiPacket CES and E-Line Services are shown. 2G 3G 3G 2G3G 2G 3G Tail Site 2G+3G Chain Site 2G+3G Tail Site 3G MW Hub Site Packet i/f CES : Circuit Emulation Service •E1 over Ethernet via Pseudo Wire Emulation •Higher priority in the network UNI UNI E-Line •Point to point service for Ethernet traffic •Configurable Committed and Peak data Rate •Basic entity for traffic provisioning and monitoring TDM i/f Fig. 56
  • 74. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 74
  • 75. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 75 4 Quality of Service in the HUB
  • 76. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 76 4.1 QoS Mechanism Quality of Service Mechanism implemented in the HUB includes (Fig. 57): • Classifier and Packet Marker a) Classifier makes the association EVC ↔ CoS based on settable "Classification Rules". b) Packet Marker marks QoS level at packet header (Green = conformant to CIR bandwidth profile; Yellow = conformant to EIR bandwidth profile; Red = not conformant and discarded immediately). • Policer: Protecting network resources by preventing usage in excess of guaranteed bandwidth (bps), i.e. compare incoming traffic rate with Traffic Profile • Buffer manager: Congestions avoidance mechanisms • Queue Scheduler: decide which packet forward first based on its priority WARNING A way to describe Service Frames when their average rate is in profile or out of profile is using the colors. Packet colors are: Green = conformant to CIR bandwidth profile Yellow = conformant to EIR bandwidth profile Red = not conformant and discarded immediately Green or yellow color is marked into packet (Priority Code Point PCP bits) and it will be carried to next phases in network.
  • 77. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 77 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... ..... Queue Scheduler Meter Dropper Policer #1 Marker Meter Dropper Policer #2 Marker Meter Dropper Policer #3 Marker Meter Dropper Policer #N Marker Output Port PacketMarker Scheduler Q1 Q2 Q3 Qn ClassifierandPacketMarker BufferManager Fig. 57 QoS Process Internal View
  • 78. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 78
  • 79. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 79 4.2 Classifier and Packet Marker Classification is based on the Service Level Agreement (SLA) set up between the service provider and the user. Traffic is classified in different priorities. FlexiPacket Hub A1200/2200 Classification Criteria are characterized as following: • Only one per-EVC basis criterion: each EVC is associated to a Class of Service (CoS). The same classification criteria foreseen for the EVC mapping are still valid for the CoSs mapping. • Apply Customer Priority (ACP): this feature allows the user to flow traffic of different priorities over the same service, all sharing the service's BW. When enabled, packets for the service should be assigned with a Priority Code Point (PCP) according to the C-Tag priority value and the customer priority decode table. FlexiPacket FirstMile-200 and HUB 800 also support two types of classification criteria: • Per EVC: each EVC is associated to a CoS. • Multi-CoS: traffic belonging to the same EVC can be split in several CoSs. Once the CoS has been identified, the PCP field of the VLAN tag associated to the service is properly marked. The PCP values will be used by the schedulers to select the proper queue. PCP values to be associated to the CoSs are configurable in FPFM200 and HUB 800. The association between CoS and PCP in FlexiPacket First Mile 200 and in the FlexiPacket HUB 800 is reported in Fig. 58. The association between CoS and PCP is fixed in A1200/A2200 and is reported in Fig. 59. Each queue is associated to a specific identification string (reported in the following pictures); such identification string derives from the standard nomenclature associated to the Differentiated Services (DiffServ) architecture specified by the IETF. IETF defines a set of six CoSs (in order of decreasing priority): EF, AF4, AF3, AF2, AF1, BE.
  • 80. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 80 Some considerations about FPH-x200 respect to IETF architecture FPH-x200 does not consider the entire set of identifiers: It does not foresee the AF4 ID; It foresees the additional EF1 ID; FPH-x200 uses an opposite order of priorities for AFx classes: AFx ID is associated to an higher priority with respect the AFx+1ID (i.e. in order of decreasing priority AF1, AF2, AF3); WARNING In FPH-x200, traffic associated to the same CoS is handled in the same queue, but with different discarding eligibility as reported in Fig. 59.
  • 81. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 81 0Queue 0: SP/WFQBest EffortsBE 1Queue 1: SP/WFQcontrolAF 2Queue 2: SP/WFQNormalAF3 3Queue 3: SP/WFQBusiness CriticalAF2 4Queue 4: SP/WFQControlAF1 5Queue 5: SP/WFQControlEF 6Queue 6: SP/WFQCESEF1 7Queue 7: SP/WFQDelay SensitiveEF2 PCPTreatment (programmable) ServiceIdentification String EF= Expedited Forwarding AF= Assured Forwarding Fig. 58 association between CoSs and PCP in FlexiPacket First Mile 200 and FlexiPacket HUB 800 1 (green) 0 (yellow) Queue 0: WFQBest EffortsAF3 3 (green) 2 (yellow) Queue 1: WFQBusiness CriticalAF2 5 (green) 4 (yellow) Queue 2: WFQManagementAF1 6 (green)Queue 3: SPDelay SensitiveEF2 7 (green)Queue 4: SPCESEF1 PCPTreatment (Fix) ServiceIdentification String EF= Expedited Forwarding AF= Assured Forwarding Fig. 59 association between CoSs and PCP in A1200/A2200
  • 82. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 82 The characteristics of the classes are: • EF1  Lowest delay and delay variation  No packet loss  Similar to DiffServ Expedited Forwarding  Usually reserved for Circuit Emulation Service (TDM services)  May be used for Voice • EF2  Low delay, delay variation, and no packet loss  Used for Voice, Video, other real-time application • AF1  Low packet loss  Reserved for internal network control traffic (OSPF, configuration, download etc.) • AF2  Lower delay and packet loss than Normal Data  Better excess BW treatment than Normal Data  Similar to DiffServ Assured Forwarding • AF3  Not just Best effort – may still have guaranteed BW • BE  Best Effort
  • 83. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 83 4.3 Policer The Meter (Fig. 60) measures incoming traffic (bps), compares it with traffic profile and sends the results (Conform, Exceed, Violate) to the "Policer Action". Policer Actions decisions are: • Pass: Forwarding packet • Mark : Change value of L2 802.1p (Marker block in Fig. 60 ) • Drop: Discarding packet (Dropper block in Fig. 60) Meter Policer Packet In Packet Out Dropper Marker Fig. 60 Policer
  • 84. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 84 4.3.1 Meter Algorithm: Two rate - three color marker (trTCM) A token bucket analogy is used to describe the algorithm that performs the metering. The algorithm decides which particular packets are within the bandwidth limits, and which are in excess the limit. Two buckets are used, one with a volume equal to the CBS (C bucket) and one with the volume equal to the EBS (E bucket). How does it works (see Fig. 61) • The token buckets C and E are initially (at time 0) full, i.e.:  the token count Tc(0) = CBS  the token count Te(0) = EBS. • Tokens are dropped into the buckets at rates equal to the CIR and EIR respectively. • Simultaneously, every time a packet comes past, a set of tokens equal to the size of the packet are taken out of the buckets. • As long as the C bucket is not empty, packets are market green. • When the C bucket is empty, but the E bucket is not, packets are marked yellow. • If both buckets are empty, packets are marked red • When the source remains idle (no incoming frames) tokens accumulate in the bucket. • The idle “credits” can be recovered by the source via sending packets later at a speed faster than CIR bits/sec. The value of CBS will depend upon the type of applications or traffic that the service is targeting to support. For example, for a service designed to support bursty TCP-based data applications, CBS will be much larger than for a service supporting more constant rate UDP-based applications.
  • 85. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 85 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dropped Incoming Frames Bucket size according to EBS Bucket size according to CBS Excess Rate Bucket Committed Rate Bucket Outgoing Frames at a regular rate with controlled burst CIR - Committed Information Rate, CBS - Committed Burst Size, PIR - Peak Information Rate, MBS - Maximum Burst Size, EIR: Excess Information Rate Metering: Two rate - three color marker Algorithm (trTCM) New token added CIR/8 times/second Check packet size against “number of tokens“ in Bucket If OK, go on and subtract packet size. If not OK, drop packet. New token added EIR/8 times/second One token = one byte c E … … … … … … . Violating Frames (above EIR) Conforming Frames (within EIR) Conforming Frames (within CIR) Exceeding Frames between CIR and PIR Fig. 61 Metering algorithm
  • 86. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 86 4.4 Buffer Manager: Congestion Avoidance RED Algorithm Random Early Detection (RED) is an algorithm which simply drops packets if too many are being received. This causes the devices which are sending the packets to notice a problem and reduce their transmissions. This mechanism is especially useful in TCP traffic where the TCP can adjust its BW according to the network congestion levels. The key to this policy is the hypothesis that a packet randomly drop from all incoming traffic will belong to a particular user with a probability proportional to the average rate of transmission of that user. The design idea of RED is very simple: two preset thresholds are used to detect incipient congestion and control the average queue size. Fig. 62 illustrates the general idea of RED. According to the estimated average queue length, there are three different working states. • When the average queue length is less than the minimum threshold, all incoming packets are processed and forwarded properly, and no packet is dropped. • When average queue length is between the minimum and maximum thresholds, arriving packets are randomly dropped with a probability that is a function of the average queue length. • When the average queue length is greater than the maximum threshold, every arriving packet is discarded. However, the probability of packet discard when the queue depth equals the maximum threshold is 1/ (MPD) where MPD is the so called Mark Probability Denominator For example, if the mark probability denominator was set to 10, when the queue depth reached the maximum threshold, the probability of discard would be 1/10 (that is, a 10 percent chance of discard).
  • 87. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 87 RED – Drop Profile •RED: Random early detect Idea: Throw away certain packets before the buffers run completely full. Without RED (Tail Drop) Queue filling level Drop Probability 0 0 Max 0 0 100% Max With RED No dropping random dropping full dropping100% probability of discard at the maximum threshold Equal to 1/MPD) Fig. 62 RED general Idea WARNING Red Algorithm is implemented inside the First Mile 200 and HUB 800 and it only works for yellow packets. The green packets will be dropped only when the buffer becomes full. All the red packets are dropped.
  • 88. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 88 WRED Algorithm Unlike RED, Weighted Random Early Detection (WRED) has a profile for each priority marking. For example, a packet marked "yellow" might have a minimum threshold of 25 packets, whereas a packet marked "green" might have a minimum threshold of 30 packets. In this example, "yellow" packets start to be discarded "before" green. 0 0 100% Max Lower class is treated with a more aggressive Drop-Profile DropProbability Queue filling Fig. 63 WRED general idea WARNING WRED Algorithm is implemented inside the A1200/A2200
  • 89. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 89 4.5 Queue Scheduler By means of scheduling algorithms is possible to decide which frames forward first based on its priority and how to manage the shared available bandwidth in case of congestion. Five strategies can be considered: 1) Without QoS management: FIFO (First In First Out) queuing (Fig. 64) • Only one queue • Frames are transmitted in the same order they arrive In case of congestion: • All frames experience queue delay irrespective of their class of service • Frames may be discarded irrespective of their class of service First In First Out Fig. 64 FIFO Queuing WARNING FIFO could be implemented inside FPFM200 and HUB 800
  • 90. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 90 2) Strict priority queuing (Fig. 65) • One queue for each class • Queues are processed in descending order (highest to lowest). • Queues assigned as high priority are serviced until they are empty. Low priority queues potentially can be starved; in order to avoid it, high priority traffic should be kept small. Strict Priority Queuing (SPQ) • SPQ Uses multiple queues • Allows prioritization • Always empties higher priority queue before going to the next queue: – Empty Queue Q3 – If Queue Q3 empty, then dispatch from Queue no. 2 – If both Queue Q3 and Queue Q2 empty, then dispatch from Queue Q0… 1 3 6 6 7 7 7 Queues Until Queue 3 is emptied Direction of Data flow 7 7 7 6 3 Q3 Q2 Q1 1 Q0 6 Queue Priority Q3 7 Q2 6,5 Q1 3,4 Q0 1,2 Fig. 65 Example of Strict Priority Queuing Strict Priority is implemented inside A1200, A2200 and First Mile 200 FlexiPacket A1200/A2200 has 5 queues FPFM200 and HUB 800 have 8 queues
  • 91. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 91 3) Weighted Round Robin (WRR) (Fig. 66) • The weight is a variable that indicates how many packets have to be sent in each cycle from each queue. • A sequence of scheduling is generated automatically according to this value. • If a queue has fewer packets than the value of the weight, the WRR scheduler outputs the existent number of packets and begins to serve the next queue. • The WRR scheduler does not take the size of the transmitted packets into account. Weighted Round Robin (WRR) • Allows prioritization • Assign a “weight” to each queue • Dispatches packets from each queue proportional to an assigned weight 3 67 77 Queues Direction of Data flow 7 77 6 3 6 6 Queue Priority Weight Q3 7 3 Q2 6 2 Q1 3 1 Q3 Q1 Q2 Q3 Q2 Q3 Q1 Q3 Q2 Fig. 66 Example of Sequence of Scheduling in a Weighted Round Robin Weighted Round Robin is implemented inside A1200/A2200/ First Mile 200/HUB 800
  • 92. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 92 4) Deficit Round Robin (DRR) An inherent limitation of the WRR mode is that bandwidth is allocated in terms of packets. WRR works well if the average packet size of each coarse-grained CoS queue flow is known. In most instances, however, this attribute is traffic-dependent and can vary over time. DRR provides a bandwidth allocation scheduler mode that takes into account the variably sized packet issue by maintaining sufficient state information when arbitrating across the CoS queues. According to the DRR algorithm, each queue "I" has a counter associated called Deficit Counter (DCi), which indicate the amount of resources (bytes) the flow can use in a round. Flows are visited in a round robin fashion. Each flow is visited only once during each round. Upon each visit the flow’s deficit counter DCi is increased by a fixed quantity Q called quantum. A packet is sent only if its length is smaller than the deficit counter’s current value, otherwise the flow is skipped. After a packet is sent the deficit counter is decreased by the size of the transmitted packet. Let's consider one example in which there are 4 queues with the same "quantum" in order to simplify the example. The example is reported from Fig. 67 to Fig. 70. As reported in Fig. 67 the "Quantum" is equal to 500 bytes. As you can see in the example, the packet is sent only if it's ≤ respect to the "Deficit Counter's current value". The "Deficit Counter's current value" may include a "Credit" coming from the previous "round".
  • 93. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 93 500700 200500 400 Initial State Queue 1 Queue 2 Queue 3 Queue 4 Quantum = 500 bytes for all queues (may have different quantum for each queue) Empty space Bytes of the packet Round Robin 1°packet2°packet 2°packet 1°packet 1°packet 600 2°packet 500 3°packet x..x Fig. 67 500700 200500 400 Deficit Counter 500 0 500 500 1° Round Current Value Credit Packet Sent 0 0 300 100 Q1 Q3 Q4 Queue 1 Queue 2 Queue 3 Queue 4 Packet 1 of queue1 gets served (500 ≥ 500) => credit = 0 Packet 1 of queue3 gets served (500 ≥ 200) => credit = 300 Packet 1 of queue4 gets served (500 ≥ 400) => credit = 100 Quantum size Empty space Bytes of the packet Round RobinPacket sent 600 500 Fig. 68
  • 94. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 94 700 500 Deficit Counter 500 0 800 600 2° Round Current Value Credit Packet Sent 500 0 300 0 Q3 Queue 1 Queue 2 Queue 3 Queue 4 500 Quantum size+ 1° round credit Quantum size Packet 2 of queue1 not served (500 < 700) => credit = 500 Packet 2 of queue3 gets served (300+500 > 500)=> credit = 300 Packet 2 of queue 4 gets served (600 =>600 credit = 0 Empty space Bytes of the packet Round RobinPacket sent 600 Quantum size+ 1° round credit Q4 Fig. 69
  • 95. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 95 700 Empty queue 500 Deficit Counter 1000 0 800 0 3° Round Current Value Credit Packet Sent 300 0 300 0 Q3 Queue 1 Queue 2 Queue 3 Queue 4 Q1 Quantum size+ credit Quantum size+ 2° round credit Packet 3 of queue1 gets served (500 + 500 > 700) => credit = 300 Packet 3 of queue3 gets served (300 + 500 > 500) => credit = 300 Empty space Round RobinPacket sent Fig. 70 WARNING A reset operation avoids outstanding packets. No accumulate credits for a long period WARNING Quantum may be different for each queue introducing a different "weight" for each queue FlexiPacket First Mile 200 and HUB 800 give the possibility to select the DRR Scheduling mode
  • 96. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 96 5) Multi stage: two strategies can be combined together Example: Weighted Round Robin Queuing + Strict Priority (Fig. 71) WARNING Weighted Round Robin + Strict Priority Multi Stage is implemented inside A1200/A2200/FPFM200 and HUB 800. In A1200/A2200 there is a fix Multi stage: 2SP+3WRR (Fig. 71). In First Mile 200/HUB 800 the Multi stage is fully programmable (Fig. 72). Deficit Round Robin + Strict Priority is implemented inside FPFM200/HUB800
  • 97. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 97 A1200/A2200 QoS Classes Summary Fig. 71 A1200/A2200 QoS Classes Summary Fig. 72 FPFM 200 WRR/DRR and Strict Priority scheduling
  • 98. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 98
  • 99. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 99 5 Quality of service in the FlexiPacket Radio Rel.1.3 EP1 WARNING Please, skip this chapter and jump to the chapter 6 if the course is about the FlexiPacket MultiRadio 5.1 Quality of Service Mechanism Quality of Service Mechanism implemented in the FlexiPacket Radio includes (Fig. 73): • Classification • Egress scheduling Classification Egress Scheduling IDU Side ODU Side Fig. 73 FlexiPacket Radio Quality of Service (1) FPR SVR1.x supports QoS mechanism in only one direction: from the gigabit Ethernet side towards the radio side. This derives from the fact that the bandwidth available on the gigabit interface is much bigger than the capacity over the radio link (1 Gbps versus about 400 Mbps). This implies that there is no need to apply QoS to traffic coming from the radio interface towards the Ethernet one. Moreover, frames coming from the radio have been already scheduled and properly enquired on the remote FPR where QoS has been applied. The QoS suite foresees a scheduler whose characteristics are described in the following. WARNING As you can see in Fig. 73 metering function is not supported since FPR SVR1.x does not support the UNI interface, where traffic is metered and marked accordingly.
  • 100. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 100 5.2 Classification Incoming packets are classified according to specified rules in order for them to be queued in the corresponding Tx queue and then scheduled. Four Tx queues are available (Fig. 74). FlexiPacket Radio classifies packets according to the following rules, allowing multiple classifications (user selectable): • VLAN ID field (Highest precedence) • IEEE 802.1p VLAN priority field • IPv4 DSCP field • IPv6 traffic class field • Port (Lowest precedence, always enabled). This criterion is not configurable and it is exclusively used to assign a CoS to traffic which has not been classified in anyway. The priority associated to this traffic is based on the port which traffic is received from. In details: If traffic is received from gigabit Ethernet interface frames are queued into priority 0 queue (lowest); If traffic is generated internally by the microprocessor frames are queued into priority 2 queue (second highest). It is possible to enable the criteria either separately or in combination (the criterion based on the port is always enabled) but it is not possible to modify the associated priority (if VLAN ID and PCP criteria are enabled, VLAN ID field will be always checked first) . The incoming frame is processed starting from the highest precedence criteria. Lower precedence criteria are considered only if the frame doesn’t match the higher ones.
  • 101. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 101 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fig. 74 ODU Quality of Service
  • 102. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 102 5.3 Egress Scheduling FlexiPacket Radio supports four egress scheduling algorithms to handle Ethernet frames towards the radio: 1) FIFO (First In First Out) queuing (see Fig. 64) 2) Strict priority queuing (Fig. 65) 3) Weighted Round Robin (Fig. 66) 4) Multi stage: Weighted Round Robin+ Strict Priority Two strategies can be combined together. FlexiPacket Radio supports 2 SP + 2 WRR with configurable weights (default) or 1 SP + 3 WRR with configurable weights WARNING FlexiPacket Radio has four queues
  • 103. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 103 6 Quality of service in the FlexiPacket MultiRadio Rel 2.1 WARNING Please, skip this chapter if the course is about the FlexiPacket Radio 6.1 Quality of Service Mechanism Figure Fig. 75 shows the QoS architecture, structured in two main functional blocks: • Classification • Egress scheduling Classification Egress Scheduling IDU Side ODU Side Fig. 75 FlexiPacket MultiRadio Quality of Service (1) Incoming Ethernet packets are classified according to the specified criteria in order to be queued inside the correspondent buffer, waiting to be scheduled. The Egress scheduling applies the QoS scheduling criteria among all queues to prioritize the egress traffic sent to the radio. Up to 8 egress queues could be configured and used for scheduling the egress traffic.
  • 104. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 104 6.2 QoS Classification Criteria The incoming Ethernet packets are classified according to the following criteria also called classification rules in the following: • Ethernet Source and Destination MAC address • EtherType field • IEEE 802.1p VLAN priority field • VLAN ID field • Pv4 ToS/DSCP field • IPv6 traffic class field • MPLS EXP field 6.3 Egress Scheduling FlexiPacket MultiRadio supports three egress scheduling algorithms to handle Ethernet frames towards the radio: 1) FIFO (First In First Out) queuing (see Fig. 64) 2) Strict Priority Queuing (Fig. 65) In Strict Priority Queuing strategy, the active egress queues are served in descending order of priority, from the highest to the lowest: each queue is served till it is completely empty. 3) Weighted Round Robin (Fig. 66) In Weighted Fair Queuing strategy, the available bandwidth is shared among all active queues proportionally to specific weights associated to each queue: these weights permit defining the amount of traffic that will be scheduled out for each queue. The weighting is configurable: the weights can be assigned to each priority queue. Moreover a queue limiter is implemented in order to limit the amount of traffic from a specific queue. 4) Multi stage: Weighted Round Robin+ Strict Priority Two strategies can be combined together.
  • 105. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 105 7 Ethernet OAM
  • 106. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 106 7.1 OAM Definition OA&M (operations, administration, and maintenance) generally speaking means a set of functions used by the user that enables detection of network fault and measurement of network performance, as well as distribution of fault-related information. Ethernet OAM means Management Capabilities associated with Ethernet Technology and used mainly in the Access network. It refers to the tools and utilities available to install, monitor, and troubleshoot the network and allow service providers to offer improved levels of services assurance. What is OAM? Here below there are some OAM tasks: Operations: • Automatic monitoring of environment (e.g. discovery) • Detect and isolate faults (e.g. connectivity verification, path trace) • Alert administrators (e.g. AIS, RDI, SNMP trap) Administration: • Performance monitoring (utilization, latency, loss, error rate, jitter) • Capacity planning Maintenance: • Upgrades • New feature deployment • Monitor health
  • 107. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 107 7.2 OAM Layers Ethernet as a technology may overlay a set of physical layer segments on one hand and on the other hand enable seamless layer-2 services end-to-end. Considering the OA&M requirements of such technology and its objectives (efficient troubleshooting), the entire solution can be divided into the following layers: • Service Layer  Measures and represents the status of the services as seen by the customer.  Produces metrics such as throughput, roundtrip delay, and jitter that need to be monitored to meet the SLAs contracted between the provider and the customer. • Network Layer  Monitors path between two non-adjacent devices. • Transport Layer  Ensures that two directly connected peers maintain bidirectional communication.  Must detect “link down” failure and notify higher layer for protocol to reroute around the failure.  Monitors link quality to ensure that performance meets an acceptable level. Relationship among layers and standards is reported in Fig. 76. • Each layer supports OAM capabilities independently • OAMs interoperate • Component responsibilities are complementary E2E Performance Monitoring E2E Fault Monitoring P2P Link Fault Management E-LMI= Ethernet Local Management Interface Fig. 76 OAM Layer Components
  • 108. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 108 Fig. 77 resumes the Ethernet OAM Standards. Ethernet OAM IEEE 802.1ag: Connectivity Fault Management (CFM) Also referred as Service OAM IEEE 802.3ah (clause 57) Ethernet Link OAM Also referred as 802.3 OAM, Link OAM or Ethernet in the First Mile (EFM) OAM ITU-T Y.1731 OAM functions and mechanisms for Ethernet-based networks MEF E-LMI Ethernet Local Management Interface Fig. 77 Ethernet OAM Standards
  • 109. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 109 The Ethernet OAM architecture building block is reported in Fig. 78 Point-to-Point EVCPoint-to-Point EVC Carrier A E-NNI UNI Multi-point to Multi-point EVC Multi-point to Multi-point EVC UNIUNI Point-to-Point EVCPoint-to-Point EVC UNI UNI UNI Link OAM •Fault-802.3ah E2E Service OAM •Fault-802.1ag •Perform-Y.1731 Carrier B Fig. 78 Ethernet OAM architecture building block
  • 110. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 110
  • 111. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 111 7.3 Ethernet Link Fault Management OAM (EFM OAM) 802.3ah Ethernet Link Fault Management (see Fig. 79 ) has the following main tasks: • Monitors the physical connection between two devices • Troubleshoot individual links • Fault Detection and Notification (Alarms) • Count Frame and Symbol errors • Remote Link Fault • Loop-back testing – out-of-service 802.3ah 802.3ah 802.3ah 802.3ah 802.3ah 802.3ah 802.3ah 802.3ah UNI UNI E-NNI 802.3ah E-Line Service Operator 1 Operator 2 Fig. 79 EFM OAM
  • 112. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 112 7.4 Connectivity Fault Management (CFM) – 802.1ag CFM is an end-to-end per-service-instance Ethernet layer OAM protocol that includes the following proactive Fault Management functions: • Fault Detection/Monitoring  Continuity check (CC) • Fault Verification  Loopback (LB) • Fault Isolation  Link Trace (LT) 7.4.1 802.1ag: Terminology Maintenance Domain (MD) It's a part of a network that is controlled by a single operator. It's defined by a set of internal and external (boundary) ports. A Domain is assigned by the administrator a unique Maintenance Level (0 – 7). The level of the domain is useful in defining the hierarchical relationships of multiple domains. CFM maintenance domains allow different organizations to use CFM in the same network, but independently. For example (Fig. 80), let's consider a service provider who offers a service to a customer, and to provide that service, they use two other operators in segments of the network. In this environment, the customer can use CFM between their CE devices, to verify and manage connectivity across the whole network, the service provider can use CFM between their PE devices to verify and manage the services they are providing and each operator can use CFM within their operator network, to verify and manage connectivity within their network. Recommended values of levels are as follow: • Customer Domain largest (e.g. 7) • Provider Domain in between (e.g. 3) • Operator Domain smallest (e.g. 1)
  • 113. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 113 Maintenance Domains are nested but not overlapped. The encompassing domain must have a higher level than the domain it encloses as reported in Fig. 80. Operator 1 Domain level 1 Operator 2 Domain level 0 Service Provider Domain level 6 Core CoreAccess Access Customer Domain level 7 Fig. 80 Different CFM Maintenance Domains across a Network . Maintenance Association (MA) It's used to monitor connectivity for a single service instance within the Maintenance Domain. It's a set of MEPs (see next point) established to verify the integrity of a single service instance. Maintenance Point (MP) A CFM Maintenance Point (MP) is an instance of a particular CFM service on a specific interface. CFM only operates on an interface if there is a CFM maintenance point on the interface; otherwise, CFM frames are forwarded transparently through the interface. A maintenance point is always associated with a particular CFM service, and therefore with a particular maintenance domain at a particular level. Maintenance points generally only process CFM frames at the same level as their associated maintenance domain. Frames at a higher maintenance level are always forwarded transparently, while frames at a lower maintenance level are normally dropped. This helps enforce the maintenance domain hierarchy, and ensures that CFM frames for a particular domain cannot leak out beyond the boundary of the domain.
  • 114. 0BGeneral Topics FT48923EN02GLA0 © 2011 Nokia Siemens Networks 114 There are two types of Maintenance Point: MEP and MIP (see next step and Fig. 81) Maintenance End Point (MEP) It resides at the edge of a maintenance domain. Proactively transmits Continuity Check (CC) Messages. MEP processes/Drops/Forwards CFM frames based on MD level. It transmits trace-route and Loopback messages upon operator request. There are two types of MEP (Fig. 82): • UP (inward in respect to the device) • DOWN (outward in respect to the device) The terms Down MEP and Up MEP are defined in the IEEE 802.1ag and ITU-T Y.1731 standards, and refer to the direction that CFM frames are sent from the MEP. The terms should not be confused with the operational status of the MEP. Maintenance Intermediate Point (MIP) It's a passive functional entity located at intermediate points in a Maintenance Domain. MIP maintains CCM Database and responds to trace-route and Loopback messages. Operator 1 Domain Operator 2 Domain Service Provider Domain MEPMIPMEP MIP MEPMIPMIP MEPMIP MEPMIPMEP MEP MEP PHY Core CoreAccess Access CFM Customer Domain Fig. 81 CFM Terminology WARNING In CFM diagrams, the conventions are that triangles represent MEPs, pointing in the direction that the MEP sends CFM frames, and circles represent MIPs.