Training New SDH All

NNew ew
SSDH DH
TTechnology echnology TTechnology echnology
SSeminar eminar
November 2002 November 2002
Agenda
Market & Technology Drivers
New SONET/SDH - Overview
Virtual Concatenation (VC)
Link Capacity Adjustment Scheme (LCAS)
Generic Frame Procedure (GFP)
Page 2
Generic Frame Procedure (GFP)
Acternas Solution
Testing Tasks
Appendix
The situation
The economic situation in the Telecom
Industry has changed...
Page 3
...and so has the technological approach
to meet new challenges!
The future - as seen in 2000
SONET/SDH
Network
SONET/SDH for
VOICE
Services
Seen Status
Future Network
Page 4
One new network for both applications!
LAN
Fully Routed
Optical IP
Network
Optical IP for
DATA
Services
Future Network
The Status Today
SDH/ SONET - is the deployed technology in the
core network with huge investments in capacity!
Ethernet - is the dominant technology of choice at
LANs and well known at all enterprises worldwide!
Data traffic is still growing, but only at a slower
Page 5
is still growing, but only at a slower
speed than expected
All network topologies focusing on a IP/Ethernet
ONLY approach are shifted to long-term future.
The future today:
Bring SONET/SDH and Ethernet together!
New Customer Applications
Virtual Private Network
(VPN)
Core Network
LAN
LAN
PC
Server
Ethernet
Page 6
Storage Area Network
(SAN)
Edge Network
Core Network
Storage Server
SONET/SDH
Fibre Channel
Bringing it all together?
Core
Operator wants:
Reduce Opex
Realize revenue-earning services
Use bandwidth of Core Network
X
Customer expects:
QoS & BW at low costs
Native Data Interfaces
Use & Improve what he knows!
LAN
Voice
Page 7
Edge
Use bandwidth of Core Network
Low investment immediate ROI
Close the edge bottleneck!
X
SAN
Solution:
Make SONET/SDH flexible & data aware at the edge and
still use the existing core!
Edge
Manufacturer needs:
...to develop solutions...fast!
Worldwide Optical Network Equipment Market
10,000.0
12,000.0
14,000.0
16,000.0
18,000.0

M
i
l
l
i
o
n
s

o
f

U
.
S
.

D
o
l
l
a
r
s
NewGen
Traditional SDH/SONET
Page 8
0.0
2,000.0
4,000.0
6,000.0
8,000.0
1999 2000 2001 2002 2003 2004 2005 2006
Year
M
i
l
l
i
o
n
s

o
f

U
.
S
.

D
o
l
l
a
r
s
Traditional SDH/SONET
Source: Gartner
Mass market Carrier Class market
Asynchronous Synchronous
Ethernet vs. SONET/SDH
Ethernet SONET / SDH
Page 9
Dynamic Bandwidth Fixed Bandwidth
Connection less Connection oriented
Best Effort Service High Quality of Service
How to solve all these challenges?
NNew ew
SSDH / DH / SSONET ONET
OOverview verview OOverview verview
Going into Details
Campus A
Ethernet
SONET/
SDH SONET/
SDH
Campus B
Ethernet
FICON
Page 11
Optical Core Optical Core
Network Network
Remote
Servers
Storage
Servers
Fibre
Channel
SONET/SDH SONET/SDH
DWDM DWDM
SONET/
SDH
Lets zoom in!
Core NE
Edge NE
S
O
N
E
T

M
U
X
/
D
E
M
U
X
N
a
t
i
v
e

I
n
t
e
r
f
a
c
e
s
New SONET/SDH at the
Edge
?
VC
LCAS
GFP
Ethernet
Ficon
Edge Core
Adaptation
Customer Operator
Page 12
SONET/
SDH
S
O
N
E
T

M
U
X
/
D
E
M
U
X
N
a
t
i
v
e

I
n
t
e
r
f
a
c
e
s
?
Thats New SONET/SDH
Virtual
Concatenation
Link
Capacity
Adjustment
Scheme
Generic
Frame
Procedure
LAPS
Ficon
Escon
Fibre
Channel
Customer needs Ethernet
Typical
Ethernet Traffic
Connections
100
75
Mbit/s
Problem: How can we efficiently transport Ethernet over an
existing SONET/SDH network?
Customer 3 = 100M
Customer 2 = 60M
Page 13
Connections
25
50
time
1 2
3 4
Ethernet Packet
Example: For 10M available SDH - Containers are...
VC-12 ...too small !
2.176 Mbit/s
VC-3
... inefficient
20%
48.38 Mbit/s
OR
Customer 1 = 10M
SDH Line Rates
10 M
Transport
10M Ethernet over SDH?
C-11 1.600 Mbit/s
C-12 2.176 Mbit/s
C-2 6.784 Mbit/s
C-3 48.384 Mbit/s
C-4 149.760 Mbit/s
SDH Payload Sizes
Standard
Containers
are inefficient!
?
5x
Page 14
C-4-4c 0.599 Gbit/s
C-4-16c 2.396 Gbit/s
C-4-64c 9.584 Gbit/s
C-4-256c 38.338 Gbit/s
Contiguous Concatenation
Contiguous
Concatenation
only large containers!
Cant 5 x VC-12 be concatenated?
VVirtual irtual
CConcatenation oncatenation
VC-n-Xv
Concatenation?
Offers concatenated payloads in fixed, large steps
One towing truck (POH) for all containers
All containers are on one path thru the network
C4 C4 C4 C4
Page 16
C-4-4c 599.040 Mbit/s
C-4-16c 2.396 Gbit/s
C-4-64c 9.584 Gbit/s
C-4-256c 38.338 Gbit/s
Virtual Concatenation
Offers structures in a fine granularity
Every container has its own towing truck (POH)
Every container might take a different path
VC-4-4v
VC-4 #1 VC-4 #2 VC-4 #3 VC-4 #4
VC-4-4c
RSOH
AU-4 Pointer
STM-N
CC: VC-4-Xc Container
Overhead N x 9 bytes Payload N x 261 bytes
J1
B3
Page 17
MSOH
VC-4-Xc, where X=4, 16, 64, 256
VC-4-Xc
X x 261 bytes
X -1 1
C2
G1
H4
F3
K3
N1
C-4-Xc
F
i
x
e
d

S
t
u
f
f
B3
F2
RSOH
AU-4 Pointer
STM-N
VC: VC-4-Xv Container
Overhead N x 9 bytes Payload N x 261 bytes
J1
J1
B3
Page 18
MSOH
VC-4-Xv, where X = 1..256
261 bytes
1
VC-4
J1
C2
G1
H4
F3
K3
N1
B3
F2
VC-4
C2
G1
H4
F3
K3
N1
B3
F2
VC-4
C2
G1
H4
F3
K3
N1
B3
F2
X frames
SDH Concatenation
STM-16 with VC-4-4c
RSOH
AU-4 Pointer
MSOH
VC-4-1 VC-4-2
VC-4-5 VC-4-6
VC-4-11 VC-41-2
VC-4-15 VC-4-16
VC-4-3 VC-4-4
VC-4-7 VC-4-8
VC-4-9 VC-4-10
VC-4-13 VC-4-14
Contiguous
concatenation
Page 19
RSOH
AU-4 Pointer
MSOH VC-4-#2
VC-4-#1
VC-4-1 VC-4-2
VC-4-3 VC-4-4
STM-4 with VC-4-2v
Virtual
concatenation
VCG = Virtual Container Group
RSOH
AU-4 Pointer
MSOH
SDH Concatenation
2x STM-16 with VC-4-11v
VC-4-1 VC-4-2
VC-4-5 VC-4-6
VC-4-11 VC-41-2
VC-4-15 VC-4-16
VC-4-3 VC-4-4
VC-4-7 VC-4-8
VC-4-9 VC-4-10
VC-4-13 VC-4-14
Virtual
Concatenation
spread across
#1
#2
#3 #4
#10
#8 #9
#11
Page 20
spread across
TWO frames
VCG = Virtual Container Group
RSOH
AU-4 Pointer
MSOH
VC-4-1 VC-4-2
VC-4-5 VC-4-6
VC-4-11 VC-41-2
VC-4-15 VC-4-16
VC-4-3 VC-4-4
VC-4-7 VC-4-8
VC-4-9 VC-4-10
VC-4-13 VC-4-14
#6
#5
#7
Virtual Concatenation is standardized
with SONET containers (ANSI T.105) or
SDH containers (ITU-T G.707)
Virtual Concatenation provides
a scheme to build right-sized SONET/SDH
Virtual Concatenation (VC or Vcat)
Page 21
a scheme to build right-sized SONET/SDH
containers
Virtual Concatenation offers
a very fine granularity
VC Nomenclature
VC-n
Virtual Container n
n=4, 3, 2, 12, 11
-X
Number of
virtually
v
Indictor for
Virtual
Page 22
n=4, 3, 2, 12, 11
Defines the type of virtual
containers, which will be
virtually concatenated.
virtually
concatenated
containers
All X Virtual Containers
form together the
Virtual Concatenated
Group (VCG)
Virtual
Concatenation
v = virtual
concatenation
c = contiguous
concatenation
Virtual Concatenated Group (VCG) of X VC-n containers!
High and Low Order VC
VC-4
High Order Virtual Concatenation
refers to virtually concatenated...
VC-3
containers
Page 23
VC-11
VC-12
VC-2
Low Order Virtual Concatenation
refers to virtually concatenated...
containers
VCG Granularity
Minimum
VCGs:
VC-4-1v Payload Size 149,76 Mbit/s
VC-4-Xv Granularity
VC-4
Example High Order VC:
VC-4 Container Size 150,3 Mbit/s
VC-4 Payload Size 149,76 Mbit/s
Page 24
VCG Payload
Capacity
Maximum
VC-4-256v Payload Size 38338 Mbit/s
Minimum
VCG Granularity
VCGs:
VC-12-Xv Granularity
Example Low Order VC:
VC-12 Container Size 2,240 Mbit/s
VC-12 Payload Size 2,176 Mbit/s
VC-12
Page 25
VCG Payload
Capacity
Maximum
VC Granularity and max. Capacity
Nomenclature Granularity Max. Capacity
VC-4 n v 149 M - 38.3G
VC-3 n v 48 M - 12.7 G
VC-2 n v 6.8 M - 434 M
VC-4
VC-3
Page 26
VC-2 n v 6.8 M - 434 M
VC-12 n v 2.2 M - 139 M
VC-11 n v 1.6M - 102 M
VC-2
VC-12
VC-11
Maximum Concatenation: = 256 containers
Max. Capacity: = 256 x granularity
VC Rate Efficiencies
Ethernet (10M) VC3 20% VC-12-5v 92%
Fast Ethernet (100M) VC-4 67% VC-12-46v 100%
Data Rates Efficiency w/o VC using VC
ESCON (200M) VC-4-4c 33% VC-3-4v 100%
Fibre Channel (800M) VC-4-16c 33% VC-4-6v 89%
Page 27
100M Ethernet
STM-1
= 64 x VC-12
VC-12-5v
VC-12-46v
2x 10M Ethernet
VC-12-5v
8x E1 Services
Example:
More services integrated- by using VC!
Gigabit Ethernet (1G) VC-4-16c 42% VC-4-7v 85%
Transporting Concatenated Signals
VC-4-4c
C-4 C-4
C-4 C-4
C-4 C-4
C-4 C-4
NE NE
One Path
C-4 C-4
C-4 C-4
Core Network
Page 28
VC-4-2v
VC-4
#2
VC-4
#1
VC-4
#1
Path 2
Path 1
VC-4
#2
Differential Delay
VC-4
#2
VC-4
#1
VC-4
#2
VC-4
#1
VC-4-4c
Core Network
VVirtual irtual
Virtual Concatenated Groups
Answer:
The containers do not know it!
Thats the job of the network management!
Question:
How does a container know that it belongs to a VCG?
Question:
Which containers can belong to the same group?
Page 30
Answer:
They must all start at one port!
And they must all end at one port!
A
B
A
B
A A
VC-4
Virtual Container Indicator
Problem:
How to distinguish between VCG members of one group?
SQ=0
Solution:
Give each member an individual number plate!
Sequence Indicator (SQ)
Page 31
VC-4
VC-4
VC-4
SQ=1
SQ=2
SQ=3
Result: VCG members can now be distinguished and sorted!
Time Stamp Mechanism
VC-4 SQ=0
Problem:
How do we know that members arriving together started together?
Solution:
Give each VCG an individual number
Frame Counter (FC)
SQ=0 SQ=0 SQ=0 SQ=0 SQ=0 SQ=0 SQ=0 SQ=0 SQ=0 SQ=0
Page 32
VC-4
VC-4
VC-4
VC-4
SQ=0
SQ=1
SQ=2
SQ=3
FC = 0
SQ=0
SQ=1
SQ=2
SQ=3
FC = 1
SQ=0
SQ=1
SQ=2
SQ=3
FC = 0
SQ=0
SQ=1
SQ=2
SQ=3
FC = 1
SQ=0
SQ=1
SQ=2
SQ=3
FC = 0
SQ=0
SQ=1
SQ=2
SQ=3
FC = 2
SQ=0
SQ=1
SQ=2
SQ=3
FC = 1
SQ=0
SQ=1
SQ=2
SQ=3
FC = 0
SQ=0
SQ=1
SQ=2
SQ=3
FC = 2
SQ=0
SQ=1
SQ=2
SQ=3
FC = 3
SQ=0
SQ=1
SQ=2
SQ=3
Storage
VCG Realignment
Demapping Arrival
SQ = 1
SQ = 0
FC = max
SQ = 1
SQ = 0
FC = max
SQ = 1
SQ = 0
FC = 0
SQ = 1
SQ = 0
FC = max
SQ = 1
SQ = 0
FC = 0
SQ = 1
SQ = 0
FC = 1
SQ = 1
SQ = 0
FC = max
SQ = 1
SQ = 0
FC = 0
SQ = 1
SQ = 0
FC = 1
SQ = 1
SQ = 0
FC = max
SQ = 1
SQ = 0
FC = 0
SQ = 1
SQ = 0
FC = 1
SQ = 1
SQ = 0
FC = 2
SQ = 1
SQ = 0
FC = 0
SQ = 1
SQ = 0
FC = 1
SQ = 1
SQ = 0
FC = 2
SQ = 1
SQ = 0
FC = 0
SQ = 1
SQ = 0
FC = 1
SQ = 1
SQ = 0
FC = 2
SQ = 1
SQ = 0
FC = 3
SQ=2 is one frame late!
Page 33
SQ = 1
FC = max
SQ = 3
FC = max
SQ = 1
FC = max
SQ = 3
FC = max
SQ = 1
FC = 0
SQ = 2
FC = max
SQ = 3
FC = 0
SQ = 1
FC = max
SQ = 2
FC = max
SQ = 3
FC = max
SQ = 1
FC = 0
SQ = 3
FC = 0
SQ = 1
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = max
SQ = 2
FC = max
SQ = 3
FC = max
SQ = 1
FC = 0
SQ = 3
FC = 0
SQ = 2
FC = 0
SQ = 1
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = max
SQ = 2
FC = max
SQ = 3
FC = max
SQ = 1
FC = 0
SQ = 3
FC = 0
SQ = 2
FC = 0
SQ = 1
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = 2
SQ = 2
FC = 1
SQ = 3
FC = 2
SQ = 1
FC = 0
SQ = 3
FC = 0
SQ = 2
FC = 0
SQ = 1
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = 2
SQ = 2
FC = 1
SQ = 3
FC = 2
SQ = 1
FC = 0
SQ = 3
FC = 0
SQ = 2
FC = 0
SQ = 1
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = 2
SQ = 2
FC = 1
SQ = 3
FC = 2
SQ = 1
FC = 3
SQ = 3
FC = 3
SQ = 2
FC = 2
Stop
Differential Delay
Problem:
Each individual container of a VCG might take a different
route through the network - Delay?
Propagation Delay (optical fiber):
is approximately 5 s/km
1000km extra path length = 5ms Differential Delay
Once around the earth Extra (42.000km) = 210ms DD
Page 34
Result: Differential Delay
Different physical path lengths will result in different
path delays for individual containers!
Solution:
A container storage & realignment process is necessary
to compensate for differential delay!
How the group starts:
Differential Delay Example
Example:
VC-4-2v group routed over TWO paths
Container SQ=0 1000km 5.0 ms propagation time
Container SQ=1 1075km 5.375 ms propagation time
Differential Delay = 5.375ms-5.0ms = 0.375ms (=3 frames)
SQ = 0
FC = 0
SQ = 0
FC = 0
SQ = 0
FC = 1
SQ = 0
FC = 0
SQ = 0
FC = 1
SQ = 0
FC = 2
SQ = 0
FC = 0
SQ = 0
FC = 1
SQ = 0
FC = 2
SQ = 0
FC = 3
SQ = 0
FC = 0
SQ = 0
FC = 1
SQ = 0
FC = 2
SQ = 0
FC = 3
SQ = 0
FC = 4
Page 35
Network
How the group arrives:
Storage Demapping
FC = 0
SQ = 1
FC = 0
FC = 0
SQ = 1
FC = 0
FC = 1
SQ = 1
FC = 1
FC = 0
SQ = 1
FC = 0
FC = 1
SQ = 1
FC = 1
FC = 2
SQ = 1
FC = 2
FC = 0
SQ = 1
FC = 0
FC = 1
SQ = 1
FC = 1
FC = 2
SQ = 1
FC = 2
FC = 3
SQ = 1
FC = 3
FC = 0
SQ = 1
FC = 0
FC = 1
SQ = 1
FC = 1
FC = 2
SQ = 1
FC = 2
FC = 3
SQ = 1
FC = 3
FC = 4
SQ = 1
FC = 4
SQ = 0
FC = 0
SQ = 0
FC = 0
SQ = 0
FC = 1
SQ = 0
FC = 0
SQ = 0
FC = 1
SQ = 0
FC = 2
SQ = 0
FC = 0
SQ = 1
FC = 0
SQ = 0
FC = 1
SQ = 0
FC = 2
SQ = 0
FC = 3
SQ = 0
FC = 0
SQ = 1
FC = 0
SQ = 1
FC = 1
SQ = 0
FC = 1
SQ = 0
FC = 2
SQ = 0
FC = 3
SQ = 0
FC = 4
SQ = 0
FC = 1
SQ = 1
FC = 1
SQ = 0
FC = 2
SQ = 1
FC = 2
SQ = 0
FC = 3
SQ = 0
FC = 4
SQ = 0
FC = 5
SQ = 0
FC = 2
SQ = 1
FC = 2
SQ = 0
FC = 3
SQ = 1
FC = 3
SQ = 0
FC = 4
SQ = 0
FC = 5
SQ = 0
FC = 6
Delay Times
Problem:
Whats the maximum differential delay time?
FC = 0
SQ=0
SQ=1
FC = 1
SQ=0
SQ=1
FC = max
SQ=0
SQ=1
FC = 2
SQ=0
SQ=1
No Delay
Both containers
arrive at the
Page 36
FC = 0
SQ=1
FC = 1
SQ=1
FC = max
SQ=1
FC = 2
SQ=1
FC = 0
SQ=0
FC = 1
SQ=0
FC = max
SQ=0
FC = 2
SQ=0
FC = 0
SQ=1
FC = 1
SQ=1
FC = max
SQ=1
FC = max-1
SQ=1
Total Differential Delay Time (s) =
1 x Frame Repetition Rate
arrive at the
same time!
Container SQ=1
arrives with
ONE frame delay
Max. Delay Compensation
FC = 0
SQ=0
FC = 1
SQ=0
FC = max
SQ=0
FC = 0
SQ=1
FC = 1
SQ=1
FC = max
SQ=1
Maximum Differential Delay Time =
FC=max frames
delay of SQ=1
FC = 0
SQ=1
Page 37
Maximum Differential Delay Time =
FC = max x Frame Repetition Rate
FC = 0
SQ=0
FC = 1
SQ=0
FC = max
SQ=0
FC = 2
SQ=0
FC = 0
SQ=1
FC = 1
SQ=1
FC = max
SQ=1
FC = 2
SQ=1
Member SQ=0 and SQ=1 did not start at the same time
Payload is LOST!
Too much Delay
FC = max+1 frames
VCG is out of synch!
Storage Capacity
Storage Example - worst case
SQ = 1
FC = 0
SQ = 0
FC = 0
SQ = 1
FC = 1
SQ = 0
FC = 1
SQ = 1
FC = 2
SQ = 0
FC = 2
SQ = 1
FC = max-1
SQ = 0
FC = max-1
SQ = 1
FC = max
SQ = 0
FC = max
SQ = max arrives the maximum Frame Counter value too late!
SQ = 1
FC = 0
SQ = 0
FC = 0
Page 38
Stop
FC = 0
SQ = max-1
FC = 0
FC = 1
SQ = max-1
FC = 1
FC = 2
SQ = max-1
FC = 2
FC = max-1
SQ = max-1
FC = max-1
FC = max
SQ = max-1
FC = max
SQ = max
FC = 0
Max. Storage Capacity = Size of one VC-n container x
Number of group members x
Maximum frame counter value x
FC = 0
SQ = max-1
FC = 0
SQ = max
FC = 0
Storage Space
Problem:
How much storage space would a new network element require?
Solution:
It depends on the maximum differential delay, which the network
element should be able to compensate for!
Maximum Differential Delay in ITU-T = 512ms
Page 39
Necessary Storage Capacity =
VC Container Capacity (Mbit/s) *
Number of Members in one VCG *
Maximum Differential Delay (s) *
Maximum Differential Delay in ITU-T = 512ms
105Mbit
VVirtual irtual
Where are the VC bytes?
Carried in one bit in K4-Byte
32 frame Multi-Frame
High Order VC Low Order VC
Information in H4 Byte
B3
C2
J1
VC-3 / VC-4
out of
J2
N2
V5
VC-2 / VC-11/VC-12
out of
VC-2-Xv / VC-11-Xv /VC-12-Xv
Page 41
F2
H4
F3
K3
C2
G1
N1
out of
VC-3-Xv / VC-4-Xv
N2
K4
Whats a multi-frame?
J2
N2
K4
V5
VC-2 / VC-11/VC-12
out of
Low Order VC
How to build a multi-frame control packet?
Filter from each K4 byte only bit no. 2
Store bit no. 2
After 32 VCs, one Virtual Concatenation
control information was received.
K4
b2
Filter
32x
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
Page 42
Frame
Counter
(FC)
Sequence
Indicator
(SQ)
Reserved...
1
b2
Filter
2
b2
3
b2
4
b2
5
b2
6
b2
7
b2
8
b2
9
b2
11
b2
12
b2
13
b2
14
b2
15
b2
16
b2
10
b2
17
b2
18
b2
19
b2
20
b2
21
b2
22
b2
23
b2
24
b2
25
b2
27
b2
28
b2
29
b2
30
b2
31
b2
32
b2
26
b2
...for LCAS
High Order VC - H4 byte
0
1
2
3
4
5
6
MFI1 MFI2
H4 Byte Multi-Frame
Bit 1 - 4 Bit 5 - 8
Reserved 0000
Reserved 0000
Reserved 0000
Reserved 0000
Reserved 0000
MFI1 (bit 1-4)
0 0 0 0
0 1 0 0
0 0 1 0
0 1 1 0
0 0 0 1
0 1 0 1
0 0 1 1
MFI2 (bit 1-4)
MFI2 (bit 5-8)
8 bit
Page 43
6
7
8
9
10
11
12
13
14
15
n
Reserved 0000
Reserved 0000
Reserved 0000
Reserved 0000
Reserved 0000
Reserved 0000
Reserved 0000
Reserved 0000
0 0 1 1
0 1 1 1
1 0 0 0
1 1 0 0
1 0 1 0
1 1 1 0
1 0 0 1
1 1 0 1
1 0 1 1
1 1 1 1
SQ (bit 1-4)
SQ (bit 5-8)
8 bit
Time for transmitting ONE multi-frame: 16 byte x 125s = 2ms
MFI 1 - Multi Frame Indicator 1
4 bits - Counter incremented at each individual frame
One MFI1 multi-frame = 16 frames
Counts from 0 to 15
MFI 2 - Multi Frame Indicator 2
8 bits - Counter incremented every 16 frames - after a complete
MFI1 multi-frame
High Order VC - H4 byte
Page 44
Counts from 0 to 255
High Order VC Frame Counter:
MFI1 x MFI2 = 16 x 255 = 4096
Max. tolerable Differential Delay = 4096 x 125 s = 512ms
SQ - Sequence Indicator
8 bits - Transmitted once every MFI 1 multi-frame
Max. number of High Order VCG members = 256
K4 byte (VC-2, 11, 12)
bit 1:Extended Signal label - 32 frame multi-frame
bit 2: Low order Virtual concatenation
1 7 2 3 4 5 6 8 9 12 10 11 13 19 14 15 16 17 18 20 21 24 22 23 25 31 26 27 28 29 30 32
Reserved
MFAS = Multiframe
alignment bits
0111 1111 110
Extended Signal
Label
0
1 7 2 3 4 5 6 8 9 12 10 11 13 19 14 15 16 17 18 20 21 24 22 23 25 31 26 27 28 29 30 32
Low Order VC - K4 byte
Page 45
bit 2: 32 frame MF should be in phase with b1 multi-frame
1 7 2 3 4 5 6 8 9 12 10 11 13 19 14 15 16 17 18 20 21 24 22 23 25 31 26 27 28 29 30 32
Reserved = 0
Frame
Count (FC)
Sequence
Indicator (SQ)
Time for transmitting ONE multi-frame:
Length of MF x Frame Repetition Rate
32 bit x 500s = 16ms
Low Order VC Frame Counter:
FC x Length of Multi-Frame x Frame Repetition Rate
FC - Multi Frame Indicator
5 bits - Counter incremented with each 32 bit multi-frame
Counts from 0 to 31
Low Order VC - K4 byte
Page 46
FC x Length of Multi-Frame x Frame Repetition Rate
Max. tolerable Differential Delay = 32 x 32 x 500s = 512ms
SQ - Sequence Indicator
6 bits - Transmitted once every 32 bit multi-frame
Max. number of Low Order VCG members = 64
Virtual Concatenation - Benefits
VC
Economical
Re-use core
network equipment
invest only at the
edge
Efficient &
Scalable
Fine granularity &
multi-path capability
Page 47
VC
BENEFITS
Well-known
SONET/SDH is well
engineered & reliable
& trained
Low
Investment
deployment only on
customer demand
Fast ROI
Challenges ahead...
How can path bandwidth be increased or decreased?
Dynamic Bandwidth Provisioning
..bring an additional truck on the road..
VC-3 #1 VC-3 #2
VC-3 #?
Page 48
VC-4 #1 VC-4 #3
FAILED
How can we ensure QoS for data services?
VCG - Protection one VC container fails - the whole
Virtual Concatenation Group (VCG) fails!
LLink ink
CCapacity apacity
AAdjustment djustment AAdjustment djustment
SScheme cheme
Virtual Concatenated Groups
Answer:
The containers do not know it!
Thats the job of the network management!
Question:
How does a container know that it belongs to a VCG?
Question:
Page 50
Answer:
They must all start at one port!
And They must all end at one port!
A
B
A
B
A A
VC-4
Virtual Container Indicator
Problem:
How to distinguish between VCG members of one group?
SQ=0
Solution:
Give each member an individual number plate!
Sequence Indicator (SQ)
Page 51
VC-4
VC-4
VC-4
SQ=1
SQ=2
SQ=3
Result: VCG members can now be distinguished and sorted!
Time Stamp Mechanism
VC-4 SQ=0
Problem:
How do we know that members arriving together started together?
Solution:
Give each VCG an individual number
Frame Counter (FC)
SQ=0 SQ=0 SQ=0 SQ=0 SQ=0 SQ=0 SQ=0 SQ=0 SQ=0 SQ=0
Page 52
VC-4
VC-4
VC-4
VC-4
SQ=0
SQ=1
SQ=2
SQ=3
FC = 0
SQ=0
SQ=1
SQ=2
SQ=3
FC = 1
SQ=0
SQ=1
SQ=2
SQ=3
FC = 0
SQ=0
SQ=1
SQ=2
SQ=3
FC = 1
SQ=0
SQ=1
SQ=2
SQ=3
FC = 0
SQ=0
SQ=1
SQ=2
SQ=3
FC = 2
SQ=0
SQ=1
SQ=2
SQ=3
FC = 1
SQ=0
SQ=1
SQ=2
SQ=3
FC = 0
SQ=0
SQ=1
SQ=2
SQ=3
FC = 2
SQ=0
SQ=1
SQ=2
SQ=3
FC = 3
SQ=0
SQ=1
SQ=2
SQ=3
Storage
VCG Realignment
Demapping Arrival
SQ = 1
SQ = 0
FC = max
SQ = 1
SQ = 0
FC = max
SQ = 1
SQ = 0
FC = 0
SQ = 1
SQ = 0
FC = max
SQ = 1
SQ = 0
FC = 0
SQ = 1
SQ = 0
FC = 1
SQ = 1
SQ = 0
FC = max
SQ = 1
SQ = 0
FC = 0
SQ = 1
SQ = 0
FC = 1
SQ = 1
SQ = 0
FC = max
SQ = 1
SQ = 0
FC = 0
SQ = 1
SQ = 0
FC = 1
SQ = 1
SQ = 0
FC = 2
SQ = 1
SQ = 0
FC = 0
SQ = 1
SQ = 0
FC = 1
SQ = 1
SQ = 0
FC = 2
SQ = 1
SQ = 0
FC = 0
SQ = 1
SQ = 0
FC = 1
SQ = 1
SQ = 0
FC = 2
SQ = 1
SQ = 0
FC = 3
SQ=2 is one frame late!
Page 53
SQ = 1
FC = max
SQ = 3
FC = max
SQ = 1
FC = max
SQ = 3
FC = max
SQ = 1
FC = 0
SQ = 2
FC = max
SQ = 3
FC = 0
SQ = 1
FC = max
SQ = 2
FC = max
SQ = 3
FC = max
SQ = 1
FC = 0
SQ = 3
FC = 0
SQ = 1
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = max
SQ = 2
FC = max
SQ = 3
FC = max
SQ = 1
FC = 0
SQ = 3
FC = 0
SQ = 2
FC = 0
SQ = 1
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = max
SQ = 2
FC = max
SQ = 3
FC = max
SQ = 1
FC = 0
SQ = 3
FC = 0
SQ = 2
FC = 0
SQ = 1
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = 2
SQ = 2
FC = 1
SQ = 3
FC = 2
SQ = 1
FC = 0
SQ = 3
FC = 0
SQ = 2
FC = 0
SQ = 1
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = 2
SQ = 2
FC = 1
SQ = 3
FC = 2
SQ = 1
FC = 0
SQ = 3
FC = 0
SQ = 2
FC = 0
SQ = 1
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = 2
SQ = 2
FC = 1
SQ = 3
FC = 2
SQ = 1
FC = 3
SQ = 3
FC = 3
SQ = 2
FC = 2
Stop
Differential Delay
Problem:
Every individual container of a VCG might take a different
route through the network - Delay?
Propagation Delay (optical fiber):
is approximately 5 s/km
1000km extra path length = 5ms Differential Delay
Page 54
Result: Differential Delay
Different physical path lengths will result in different
path delays for individual containers!
Solution:
A container storage & realignment process is necessary
to compensate for differential delay!
Los Angeles
Seattle
Dallas
Washington
Chicago
San Francisco
San Jose
Atlanta
New York
Boston
Kansas City
Denver
Columbus
Los Angeles
Seattle
Dallas
Washington
Chicago
San Francisco
San Jose
Atlanta
New York
Boston
Kansas City
Denver
Columbus
Location B
Bandwidth Provisioning - today
Page 55
Houston
Orlando
Houston
Orlando
Location A
50Mbit/s Ethernet Private Line (VC-3-1v/ STS-1-1v)
The customer now requires 100Mbit/s
But: Traffic will be interrupted to bring 100M into service!!
Operator manually sets up a 2
nd
path
using the network management system
100M = VC-3-2v / STS-1-2v
LCAS Overview
Link
Capacity
Adjustment
Extension for
Virtual Conc.
carried in
H4/K4 byte
Add/Remove
bandwidth
uninterrupted
Page 56
Adjustment
Scheme
End-to-end
Real-Time
Communication
Standardized ITU-T G.7042, referred by ANSI
Handshake
Protocol
between edge
NE
Los Angeles
Seattle
Dallas
Washington
Chicago
San Francisco
San Jose
Atlanta
New York
Boston
Kansas City
Denver
Columbus
Los Angeles
Seattle
Dallas
Washington
Chicago
San Francisco
San Jose
Atlanta
New York
Boston
Kansas City
Denver
Columbus
LCAS - Add Bandwidth hitless
Location B
NE
NE
Page 57
Houston
Orlando
Houston
Orlando
Operator manually provisions add. 50M path
Location A
Operator installs VC & LCAS edge equipment
LCAS protocol runs between the two edge NE!
NE negotiate - when the additional path gets valid
and into service!
LCAS Succeeds A connection with 100M is in service!
VC-4
Virtual Container (VC)
Terms, Terms, Terms
VC-4 #1
VC-4 #2
Start Point
Termination Point
Link
VC
VC
VC
Page 58
VCG
Virtual Concatenated
Group
VC-4 #2
VC-4 #3
Member
Number 3
of VCG
...is a connection through a network
from start of to the termination point for
a complete VCG or an individual
member of a VCG.
A Link
Control Packets - information packets
exchanged between source & sink.
GGeneralized eneralized
CControl ontrol
PPacket acket PPacket acket
VC & LCAS Control Packet
Frame
Counter
MFI
VCG
Sequence
Indicator
SQ
LCAS
Error
Protection
CRC
LCAS
Member
Status
MST
LCAS
Control
Commands
CTRL
LCAS
Source
Identifier
GID
LCAS
Resequence
Acknow-
ledgement
RS-Ack
Page 60
Virtual
Concatenation
Information
LCAS Information
Information Packets exchanged between the two
edge network elements to adjust the bandwidth.
Control Packet - MFI
CRC MST
MFI
SQ CTRL GID RS-Ack
MFI - Multi Frame Indicator Field
it is a frame counter which will be incremented with each frame
All VCG members will have the same counter value
reaching the maximum counter value the counter restarts at 0
Sink Source
Page 61
MFI is necessary for
realigning virtual concatenated containers of one VCG at the sink
determing the differential delay between members of the same VCG
MFI = 0 MFI = 1 MFI = 2 MFI = max MFI = 0 MFI = 1
Sink Source
Control Packet - SQ
CRC MST MFI
SQ
CTRL GID RS-Ack
SQ - Sequence Indicator Field
each member of a VCG has it own, unique sequence number
the values start at 0 - max. 63 (LO) or 255 (HO)
SQ = 0 SQ = 0 SQ = 0 SQ = 0 SQ = 0
Sink Source VCG
Page 62
SQ is necessary for
differentiating the members of a virtual concatenated group (VCG)
MFI = 0
SQ = 0
MFI = 0
SQ = 1
MFI = 1 MFI = 2 MFI = 255 MFI = 0
MFI = 1 MFI = 2 MFI = 255 MFI = 0
SQ = 0 SQ = 0 SQ = 0 SQ = 0
SQ = 1 SQ = 1 SQ = 1 SQ = 1
Member 0
Member 1
EOS
Sink Source
Control Packet - CTRL
CTRL - Control Field for LCAS
is used to transfer information from the source to sink
it contains the LCAS control commands to initiate or terminate the
bandwidth adaptation process
CRC MST MFI
SQ CTRL GID RS-Ack
Page 63
VCG Link
EOS
IDLE
ADD
NORM
Sink Source
CTRL - is used to
synchronize source and sink LCAS process
provide LCAS status information about every individual VCG
member
LCAS Control words
FIXED (0000) - Non LCAS Mode
Indication that LCAS mode is not used at the source- fixed bandwidth
CRC MST MFI
SQ CTRL GID RS-Ack
ADD (0001)- Increase bandwidth of a VCG
Page 64
ADD (0001)- Increase bandwidth of a VCG
A container, which is currently not a member of the group, but is
asking to become an active member of a VCG.
NORM (0010) - Normal Transmission
This container is an active member of a VCG and currently
transporting client payload
CRC MST MFI
SQ CTRL GID RS-Ack
IDLE (0101) - Currently not in use
LCAS Control words
EOS (0011) - End of sequence & Normal Transmission
This container is the last active member of a VCG and currently
transporting client payload.
Page 65
DNU (1111) - Do Not Use
The payload of this container cant be used, because the sink
reported FAIL status
But it is still a member of the VCG, but currently out of service
IDLE (0101) - Currently not in use
Pre-provisioned container, but currently not in use or about to be
removed from a group - is not carrying client payload.
At initiation of a new VCG, members should have CTRL=IDLE state
Control Packet - GID
CRC MST MFI
SQ
CTRL
GID
RS-Ack
GID - Group Identification Bit
is a security mechanism to ensure that all members are belonging
to the same VCG
every member of a VCG has the same GID bit value
GID content is a PRBS 2
15
-1
Page 66
GID - is used to
verify that all members are coming from the same source
identify all members of a VCG
Member 0
Member 1
MFI = 0
SQ = 0
GID = 0
MFI = 1
SQ = 0
GID = 0
MFI = 2
SQ = 0
GID = 1
MFI = 0
SQ = 1
GID = 0
MFI = 1
SQ = 1
GID = 0
MFI = 2
SQ = 1
GID = 1
MFI = 255
SQ = 0
GID = 0
MFI = 0
SQ = 0
GID = 1
MFI = 255
SQ = 1
GID = 0
MFI = 0
SQ = 1
GID = 1
Control Packet - MST
CRC
MST
MFI
SQ
CTRL GID RS-Ack
MST - Member Status field
reports the status for every member of a VCG from sink to source
(= back channel) with one bit
there are two MST states for each individual VCG member:
OK = 0 or FAIL = 1
Page 67
Member Status information
is spread across multiple frames.
corresponds directly to a certain VCG member
is always reported for the max. number of VCG members (64 or
256)
should report MST=FAIL on initiation of a new VCG
should switch to MST=OK on reception of ADD, NORM or EOS
Control Packet - MST Explained
CRC
MST
MFI
SQ
CTRL GID RS-Ack
Example:
VC-12-3v
MFI = x
SQ = 0
MFI = x
SQ = 1
MFI = x
SQ = 2
MFI = x
SQ = 0
MFI = x
SQ = 1
MFI = x
SQ = 2
Sink to Source Communication
Source to Sink
Page 68
Control Packet 8
MST = FAIL for SQ=63
Control Packet 0 MST = FAIL for SQ=3
MST = OK for SQ=0 Control Packet 0
Control Packet 0
MST = OK for SQ=1
Control Packet 0 MST = OK for SQ=2
Control Packet - RS-Ack
CRC MST MFI
SQ
CTRL GID RS-Ack
RS-Ack - Re-sequence Acknowledge bit
If any sequence number changes are detected at the sink the RS-
Ack Bit is toggled (from 0 to 1 or from 1 to 0)
BUT only after the status for ALL members have been evaluated
An RS-Ack toggle will be an indication for the source that the sink
has accepted the new member status.
Page 69
has accepted the new member status.
VC & LCAS Control Packet
CRC
MST MFI
SQ
CTRL GID RS-Ack
CRC - Cyclic Redundany Check
the content of a control packet is protected by a CRC
if errors are detected the control packet is rejected
Page 70
LLCAS CAS
summary summary summary summary
Control Packet Overview
Information
Direction
Source Sink
MFI
Multi-Frame Indicator is an counter
to distinguish several VCGs* from each other
necessary to compensate for Differential Delay
SQ
Sequence Indicator is an counter
to differentiate individual VC-n containers within a VCG*
to re-sequence VC-n containers at the termination point in
case that differential delay occured
Page 72
case that differential delay occured
CTRL
LCAS Control Words are
the actual commands which will show the status of
containers from a VCG* initiate bandwidth changes
FIXED - container in NON-LCAS mode
ADD - container which will be added to a VCG
REMOVE - container which will be removed from a VCG
NORM- container as part of an active VCG
EOS - last container of an active VCG
DNU - container with failures(do not use)
*VCG = Virtual Concatenated Group
Control Packet Overview
Information
Direction
Source Sink
GID
Group Identification Bit is
an additional verification mechanism to secure that all
incoming VCG members belong to one group
RS-Ack
Re-sequence acknowledgement is
an mechanism, where the sink reports to the source the
detection of any additions/removals to/from the VCG
Page 73
CRC
Cyclic Redundancy Check is a
protection mechanism to detect bit errors in the Control Packet
MST
Member Status Field is
an mechanism, where the sink reports to the source which
VCG members are currently and correctly received
detection of any additions/removals to/from the VCG
*VCG = Virtual Concatenated Group
CControl ontrol
PPacket acket
TTransport ransport TTransport ransport
HHigh & igh & LLow Order ow Order
Where are the LCAS bytes?
V5
J1
VC-3 / VC-4
LCAS info aligned with VC info
Carried in one bit in K4-Byte
High Order LCAS Low Order LCAS
LCAS info aligned with VC info
Information also in H4 Byte
Page 75
J2
N2
K4
V5
VC-2 / VC-11/VC-12
out of
F2
H4
F3
K3
B3
C2
G1
J1
N1
VC-3 / VC-4
out of
VC-3-nv / VC-4-nV
*CP = Control Packet
Low Order Control Packet
J2
N2
K4
V5
VC-2 / VC-11/VC-12
out of
Low Order VC & LCAS
How to build a multi-frame control packet?
Filter from each K4 byte only bit no. 2
Store bit no. 2
After 32 VCs, one complete VC & LCAS
control packet was received.
K4
b2
Filter
32x
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
K4
b2
Page 76
CRC
-3
Member Status
Sequence
Indicator
CTRL
G
I
D
Spare
R
S
-
A
C
K
Frame
Count
1
b2
Filter
2
b2
3
b2
4
b2
5
b2
6
b2
7
b2
8
b2
9
b2
11
b2
12
b2
13
b2
14
b2
15
b2
16
b2
10
b2
17
b2
18
b2
19
b2
20
b2
21
b2
22
b2
23
b2
24
b2
25
b2
27
b2
28
b2
29
b2
30
b2
31
b2
32
b2
26
b2
Information
LCAS Information
1 bit - per 32 bit multi-frame Content is a PRBS 2
15
-1
Receiver does not have to synchronize to PRBS
CTRL - LCAS Control Words
4 bits - with six possible control words currently defined
One control word is transmitted per 32 bit multi-frame
Low Order LCAS - K4 byte
Page 77
MST - Member status field
8 bits - Status of 8 VCG members is reported per control packet
Report time for all 63 member statuses: 128ms
128 ms = 8 packets x 16ms control packet time
RS- Ack - Re-Sequence Acknowledgement
1 bit - Transmitted once every 32 bit control packet
CRC - Cyclic Redundancy Check
3 bits - to detect errors in a control packet
High Order LCAS - H4 byte
0
1
2
3
4
5
6
MFI1 MFI2
H4 Byte Multi-Frame
Bit 1 - 4 Bit 5 - 8
MFI1 (bit 1-4)
0 0 0 0
0 1 0 0
0 0 1 0
0 1 1 0
0 0 0 1
0 1 0 1
0 0 1 1
MFI2 (bit 1-4)
MFI2 (bit 5-8)
8 bit
Reserved 0000
Reserved 0000
CRC-8
GID 000x
1 bit
CTRL 4 bit
Page 78
6
7
8
9
10
11
12
13
14
15
n
0 0 1 1
0 1 1 1
1 0 0 0
1 1 0 0
1 0 1 0
1 1 1 0
1 0 0 1
1 1 0 1
1 0 1 1
1 1 1 1
SQ (bit 1-4)
SQ (bit 5-8)
8 bit
Time for transmitting ONE multi-frame: 16 byte x 125s = 2ms
Reserved 0000
Reserved 0000
Reserved 0000
CRC-8
CRC-8
8 bit
Member Status (MST)
Member Status (MST)
8 bit
RS-Ack 000x
1 bit
1 bit - per multi-frame Content is a PRBS 2
15
-1
Receiver does not have to synchronize to PRBS
CTRL - LCAS Control Words
4 bits - with six possible control words currently defined
One control word is transmitted per multi-frame (16x H4)
High Order LCAS - H4 byte
Page 79
1 bit - Transmitted once every multi-frame
MST - Member status field
8 bits - Status of 8 VCG members is reported per multi-frame
Report time for all 256 member statuses: 64ms
64 ms = 256/8 x 2ms control packet time
CRC - Cyclic Redundancy Check
8 bits - to detect errors in a control packet
AAnn
EExample xample
To change the bandwidth on a link it is necessary to
Send information from Source to Sink
LCAS communication is uni-directional, every VCG link must be set-up
and commissioned separately,
BUT LCAS needs always a back channel! (Sink to Source)
One uni-directional VCG connection from source to sink
Commands & Directions
Send replies from Sink to Source
Page 81
Source to Sink Communication
MFI SQ CTRL GID CRC
Source Sink
MST RS-Ack
Example LCAS Handshake
Bi-directional connection between network element (NE) 1 & 2
Each H-4 byte in each VC-4 container carries every 16 frames
(= multi-frame) one control packet which contains the VC and
LCAS information for these links
VCG B consists of p VC-4 containers, e.g. p = 1 VC-4-1
VCG A consists of n VC-4 containers, e.g. n = 2 VC-4-2v
Page 82
Link of VCG B
Link of VCG A
NE 1
NE 2
VC-4-1v
VC-4 #0
VC-4-2v
VC-4 #1
VC-4 #0
Control Packets in H4
Information sent in
control packet x
of container n
in VCG A
Information Flow Chart
Information for status of
container n of VCG A
MFI_A
SQ(n)
CTRL(n)
CRC_x
GID_A
MST_B(n)
RS-Ack_B
Link of VCG A
NE 1 NE 2
Page 83
Information sent in
control packet y
of container p
in VCG B
Information for status of
container p of VCG B
MST_A(n)
RS-Ack_A
MFI_B
SQ(p)
CTRL(p)
CRC_y
GID_B
Link of VCG B
LCAS Protocol - is uni-directional
links in forward and backward direction are directional
independent
Changes in one direction (link) do not imply any changes in
the other direction (link)
But LCAS assumes that there is always at least ONE
container in the backward direction!
Backward Channel
Page 84
container in the backward direction!
Result
Therefore all member status information and RS-
acknowledgment bits are always multiplexed into only ONE
container!
SStandard tandard
LLink ink
Whats the status of Link A?
Counter from 0 to max, increased with every VCG send by NE 1
MFI
SQ
VC-4 No. 0 SQ=0 First container in VCG A
VC-4 No. 1 SQ=1 Second container in VCG
CTRL
VC-4 No. 0 CTRL=NORM Normal Transmission and container
No. 0 is part of VCG A
VC-4 No. 1 CTRL=EoS Last container in VCG A
VC-4 No. 255 Not part of any group! (Network Management)
Page 86
Link of VCG A
NE 1
NE 2
VC-4-2v
Link of VCG B
VC-4-1v
Add. One VC-4 currently not in use!
VC-4 No. 255 CTRL=IDLE Not equipped!
MST
Reports that on VCG A two members with SQ=0&1 are received!
RS-Ack
Nothing to report, as long as there are no member status changes!
AAdding dding
BBandwidth andwidth
Adding a new member
Container No. 0 & No. 1 build an VC-4-2v VCG
A third container is provisioned (end to end), but
currently not in use!
1
Back-
channel
VC-4
#1
VC-4
#0
VC-4-2v
VC-4
Not in use!
Status:
Page 88
Containers, which are not in use should have the
highest possible sequence indicator value (SQ=max).
SQ=255
CTRL=
IDLE
MST 0 & 1 = OK
2 to max = FAIL
RS-Ack = 0
SQ
CTRL
SQ=0
CTRL=
NORM
SQ=1
CTRL=
EoS
Status:
Adding a new member
VC-4
#1
VC-4
#0
VC-4
The network management system sends a request for
additional bandwidth to the NE 1 and wants to assign
unequipped container.
2
SQ SQ=0 SQ=1 SQ=2
Back-
channel
MST 0 & 1 = OK
2 to max = FAIL
Page 89
CTRL
CTRL=
NORM
CTRL=
EoS
CTRL=
ADD
next higher SQ value is assigned to the unequipped VC-4
In the control word an ADD request is send to NE 2
2 to max = FAIL
RS-Ack = 0
Adding a new member
After a certain time (propagation delay) NE 2 will detect a
new, correct container (SQ=2) with CTRL=ADD
3
VC-4
#1
VC-4
#0
VC-4
#2
Back-
channel
NE 2 waits for the next opportunity to report this
new member to NE 1 (once every 32 multi-frames with 16
frames each)
4
Page 90
MST 0/ 1/ 2= OK
3 to max = FAIL
RS-Ack = 0
SQ
CTRL
SQ=0
CTRL=
NORM
SQ=1 SQ=2
CTRL=
EoS
CTRL=
ADD
frames each)
NE 2 will send a member status = OK message for
container No. 2 to NE 1
MST (0, 1, 2) = OK, MST (all others) = fail
5
Adding a new member
NE 1 will save this new member status in a temporary
register, but does not make any changes to the VCG!
6
VC-4
#1
VC-4
#0
VC-4
#2
Back-
channel
NE 2 will toggle the RS-Ack Bit with the next start of a multi-
frame to indicate NE 1 that this new configuration can now go
alive
7
Page 91
alive
SQ
CTRL
SQ=0
CTRL=
NORM
SQ=1 SQ=2
CTRL=
EoS
CTRL=
ADD
RS-Ack = 1
MST 0/ 1/ 2= OK
3 to max = FAIL
Adding a new member
After receiving the toggled RS-Ack bit NE 1 will
take the new member status from the temporary
register as the new, valid one.
change the CTRL words for container 1 & 2!
8
VC-4
#1
VC-4
#0
VC-4
#2
Back-
channel
Page 92
SQ
CTRL
SQ=0
CTRL=
NORM
SQ=1 SQ=2
CTRL=
NORM
CTRL=
EOS
RS-Ack = 1
MST 0/ 1/ 2= OK
3 to max = FAIL
Adding a new member
After changing the Control Word of an SQ=2 container
to End of Sequence NE 1 will map valid payload into
THE NEXT VC-4 container!
9
VC-4
#1
VC-4
#0
VC-4
#2
Back-
channel
The new VC-4-3v group is now active and NE 2 will
demap the payload correctly!
10
Page 93
SQ
CTRL
SQ=0
CTRL=
NORM
RS-Ack = 1
SQ=1 SQ=2
CTRL=
NORM
CTRL=
EOS
MST 0/ 1/ 2= OK
3 to max = FAIL
The new VC-4-3v group is now active and NE 2 will
demap the payload correctly!
10
ADD Explained
Request from NMS to increase bandwidth on a existing link.
1 Source
Actions for the currently unequipped container:
a) assign a valid sequence indicator (SQ=currently highest +1)
b) change CTRL=ADD (from CTRL=IDLE)
2 Source
Sink replies with MST=OK after detection of the new member
3
Sink
Sink acknowledges the new status with the beginning of the next
multi-frame (RS-Ack toggles)
4
Sink
Page 94
multi-frame (RS-Ack toggles)
4
Sink
With reception of acknowledgement source will change
a) the status of the last member from CTRL=EoS to NORM
b) the status of the new member from CTRL=IDLE to EoS
5
Source
After the reception of the new member with CTRL=EoS Sink will
start the demapping process with the next container!
7
Sink
Source starts to map payload information in the next upcoming
container
6
Source
SState tate
DDiagramm iagramm
LCAS - ITU-T State Diagram
NMS LCAS Sk
Sk Sk
CTRL=ADD
CTRL=ADD
MST=OK
mem
a
(new)
mem
a +1
(new) mem
n-1
(EOS) Note 1
Note 2
Note 3
Note 4
Add cmnd
connectivity
check
connectivity
check
Page 96
CTRL=NORM
CTRL=EOS
CTRL=NORM CTRL=EOS
MST=OK
Note 5
Note 6
Note 7
LLink ink
FFailure ailure
Sink detects an failure of one member
Sink changes the member status of this member to FAIL
On detection of this new member status Source will set
CTRL from NORM or EoS to DNU (Do not use)
Sink does not demap the payload anymore.
Temporary Failure
Sink detects the clearance of the failure status
Page 98
Sink detects the clearance of the failure status
Sink sets the member status of this member to OK
On detection of this new member status Source will set
CTRL to NORM or EOS again
Sink will now demap th
Auto Recovery of VC links possible
Link Capacity Adjustment Scheme
LCAS
Cost Efficient
New NE necessary
only at the edge
Transparent to
core network
Enables Value
added services
Bandwidth on demand
Soft Protection
99.999% up-time
Page 99
LCAS
BENEFITS
Flexible &
scalable
Offers variable VC
bandwidth in real-
time!
Restoration
link protection &
recovery
Challenges ahead
Efficient & suited mappings for all diverse data
clients!
...one mapping fits all...?!?
SONET/SDH
Page 100
Rate adaptation between asynchronous clients
and synchronous transport network
Asynchronous
Rates
Synchronous
Rates
GGeneric eneric
FFrame rame
PProcedure rocedure PProcedure rocedure
S
O
N
E
T

M
U
X
/
D
E
M
U
X
N
a
t
i
v
e

I
n
t
e
r
f
a
c
e
s
New SONET/SDH at the
Edge
?
VC
LCAS
GFP
Ethernet
Ficon
Edge Core
Adaptation
Customer Operator
Page 102
SONET/
SDH
S
O
N
E
T

M
U
X
/
D
E
M
U
X
N
a
t
i
v
e

I
n
t
e
r
f
a
c
e
s
?
Thats New SONET/SDH
Virtual
Concatenation
Link
Capacity
Adjustment
Scheme
Generic
Frame
Procedure
LAPS
Ficon
Escon
Fibre
Channel
GFP Overview
Generic
Frame
Data En-
capsulation
for various
services
Rate
Adaptation
Mechanism
Page 103
Frame
Procedure
Asynch.
clients over
synchronous
networks
Standardized
ITU-T G.7041
referred by
ANSI
SANs
F
I
C
O
N
E
S
C
O
N
Ethernet
D
V
I
HDLC
Frame Relay POS
DATA (IP, IPX, MPLS,...)
RPR
F
i
b
r
e

C
h
a
n
n
e
l
Voice Video
Private
Lines
The Big picture
Page 104
ATM
HDLC
Fiber
GFP-T
SONET/SDH
WDM / OTN
GFP-F
GFP
GFP - Layer Model
GFP - Client Specific Aspects
(payload dependent)
GFP - Common Aspects
Ethernet IP/PPP
Fibre
Channel
Others Clients
GFP
Frame Mapped Transparent Mapped
ESCON
Page 105
(payload independent)
SONET/SDH
VC-n Path
OTN
ODUk Path
Others
(e.g. Fibre)
Transport
Generic Frame Procedure
G.7041 Generic Frame Procedure defines
Client encapsulation - for transport over
SONET/SDH or OTN networks
Frame formats - for various clients
Mapping Procedures - for client signals into
Page 106
GFP
Why do we need a new framing procedure?
simple and scalable traffic adaptation for different
transport rates
flexible approach for data transmission which
requires stringent delay, QoS
SStructure tructure ooff
GGFP FP -- FFrames rames GGFP FP -- FFrames rames
Core Header
GFP Frame Overview
Client Payload Field
Payload Headers gives type
of client and supports client
specific management
procedures
Includes CRC detection &
correction
Length 4 to 64 byte
Payload
Headers
Core Header contains the
length of the payload area
and start of frame info
and CRC-16 error detection
& correction
Length 4 byte
Page 108
Payload
Area
8 bit
GFP Payload Area transports
higher layer specific
information
Length 4 to 65535 byte
Client Payload Field
contains
client frames (GFP-F) or
client characters (GFP-T)
Client
Payload
Information
Optional Payload FCS
protects the client payload
information field
CRC-32 Length 4 byte
Optional
Payload FCS
GFP gets scrambled before transmission!
Core Header
PLI
PLI
cHEC
cHEC
Payload
Headers
4 byte
X=4-64 byte
4 byte
Page 109
Payload
Area
8 bit
Client
Payload
Information
Optional
Payload FCS
4 to 65535 byte
8 bit
0 to
65535-X byte
4 byte
GFP - Core Header
Core Header
PLI - PDU Length Indicator
16-bit field contains a binary number,
representing the length of the
payload area:
min.: 4 byte (PLI = 00 04hex)
max.: 65535 byte (PLI = FF FFhex)
PLI = 0hex to 3hex reserved for
control frames
PLI
PLI
cHEC
cHEC
1
1
1
1
1 2 3 4 5 6 7 8
Page 110
Payload
Area
cHEC - Core Header Error Control
contains a CRC-16 error control code to protect the integrity
of the core header.
It enables
to correct a single bit error
to detect multiple bit errors
GFP -Control Frames
GFP IDLE Frames
IDLE Frame
GFP Control Frames are used in the managment of
the GFP connection.
Four Control Frames are available
PLI= 00 00hex to PLI = 00 03hex
BUT only one Control frame is currently specified:
Page 111
GFP IDLE Frames
The smallest, possible GFP frame with
only 4 byte long
PLI = 00 00hex
IDLE frames are necessary
for rate adaptation process
robustness of the frame
synchronization process
IDLE Frame
PLI =00
PLI= 00
cHEC = 00
cHEC = 00
GFP Frame Hierachy
GFP Frames
Client Frames
PLI 04hex
Control Frames
PLI 03hex
Page 112
GFP - Payload Header
Payload Type Field
is mandatory for GFP client frames (PLI 4)
Provides information about
content & format of the Client Payload
Information
indicates different GFP frame types
Payload
Core Header
Client
Payload
Headers
Payload
Type
Extension
Page 113
indicates different GFP frame types
distinguishes between different services
in a multi-service environment
Payload
Area
Client
Payload
Information
Optional
Payload FCS
Extension
Header
Field
PTI - Payload Type Identifier
3-bit field, which indicates the type of
GFP client frame
Currently defined
PTI = 000 Client Data
PTI = 100 Client Management
PTI = Others Reserved
PFI - Payload FCS Indicator
Payload
Type
Extension
Header
Field
PTI
PFI
EXI
UPI
tHEC
tHEC
1
1
1
1
1 2 3 4 5 6 7 8
Page 114
PFI - Payload FCS Indicator
1-bit field indicates the
PFI = 1 Presence
PFI = 0 Absence
of the optional payload Frame Check Sequence (pFCS) field
EXI - Extension Header Identifier
4-bit field indicates the format of the Extension Header Field
Currently defined
EXI = 0000 Null Extension Header
EXI = 0001 Linear Frame
EXI = 0010 Ring Frame
EXI = Others Reserved
Field
UPI - User Payload Identifier
8-bit field identifies the type of client/service
encapsulated in the GFP Client Payload
Field
Interpretation of UPI values is different for
Client data frames (PTI=000) or
Client management frames (PTI=100)
More details on the next slides
Payload
Type
Extension
Header
Field
PTI
PFI
EXI
UPI
tHEC
tHEC
1
1
1
1
1 2 3 4 5 6 7 8
Page 115
tHEC - Type Header Error Control
16-bit error control code
to correct one bit error or
to detect multiple bit errors in the payload type field
Field
GFP Frame Hierachy
GFP Frames
Client Frames
PLI 04hex
PTI = 000bin PTI = 100bin
PLI = 00hex PLI = 01 to 03hex
Control Frames
PLI 03hex
Page 116
Client Data
Frames
Client
Management
Frames
Idle
Frames
Other Frames
(for further study)
Currently defined Client Data Frames - User Payload Identifier(UPI)
UPI = 00 & FF Reserved and not available
GFP - Client Data Frames
PTI
PFI
EXI
UPI
tHEC
tHEC
Indication in the Type field
PTI = 000
Clients and services are transported over GFP Client
Data Frames
Page 117
UPI = 00 & FF Reserved and not available
UPI = 01hex Ethernet (frame-mapped)
UPI = 02hex PPP (frame-mapped)
UPI = 03hex Fibre Channel (transparent-mapped)
UPI = 04hex FICON (transparent-mapped)
UPI = 05hex ESCON (transparent-mapped)
UPI = 06hex Gigabit Ethernet (transparent-mapped)
UPI = 07hex Reserved for future use
UPI = 08hex Multiple-Access Protocol over SDH (frame-mapped)
UPI = 09 to EF Reserved for future use
UPI = F0 to FE Reserved for proprietary use
GFP - Client Management Frames
Currently defined Management Frames
PTI
PFI
EXI
UPI
tHEC
tHEC
Indication in the Type field
PTI = 100
This functionality provides a mechanism to send
management information from the GFP source to the
GFP sink
Page 118
Currently defined Management Frames
UPI = 00 & FFhex Reserved and not available
UPI = 01hex Loss of Client Signal (Client Signal Fail)
UPI = 02hex Loss of Character Synchronization
UPI = 03 to FEhexFor future use
GFP Frame Hierachy
GFP Frames
Client Frames
PLI 04hex
PTI = 000bin PTI = 100bin
PLI = 00hex PLI = 01 to 03hex
Control Frames
PLI 03hex
Page 119
Client Data
Frames
Client
Management
Frames
Idle
Frames
Other Frames
(for further study)
Dependent on
Client
UPI =00hex to FFhex UPI = 01hex UPI = 02hex
Loss of Client
Signal
Loss of Client
Synchronization
UPI = 00hex or FFhex
Reserved
GFP - Extension Header
Extension Header Field
supports technology specific data link
headers, e.g.
virtual link identifier
source/destination adress
Class of Service
it is 0-60 byte long and indicated in the Type
field (EXI)
Payload
Core Header
Client
Payload
Headers
Payload
Type
Extension
Page 120
field (EXI)
Three Extension Header Variants are
currently defined for point-to-point or ring
configurations
EXI = 0000 Null Extension Header
EXI = 0001 Linear Frame
EXI = 0010 Ring Frame
EXI = Others Reserved
Payload
Area
Client
Payload
Information
Optional
Payload FCS
Extension
Header
Field
GFP - Null Extension Header
Null Extension Header (EXI = 0000 (0hex))
applies to logical point-to-point configuration, where
the transport path is dedicated to one client or
service only tHEC
tHEC
Type
Type
1
1
1
1
1 2 3 4 5 6 7 8
Page 121
the extension header field itself is not present
Extension
Header
Field
GFP - Linear Extension Header
CID - Channel ID
8-bit field to indentify up to 256 independent GFP
channels over the same link
CID
Spare
1
1
tHEC
tHEC
Type
Type
1
1
1
1
Linear Frame Extension Header (EXI = 0001)
applies to linear (point-to-point) configurations,
where several independent clients or services are
aggregated to one transport path
Page 122
Extension Header
Field
eHEC - Extension Header Correction
16-bit error control code
to correct on bit error
to to detect multiple bit errors in the extension
header field
eHEC
eHEC
Spare
1
1
1
Spare
8-bit field for future use
Extension Header for ring frame for further study
GFP - Client Payload Area
CPI - Client Payload Information Field
variable length field, which contains the client or service
GFP-F (frame mapped)
CPI field carries the client frames
GFP-T (transparent mapped)
CPI field carries (unframed) client characters
Payload
Core Header
Client
Payload
Payload
Headers
Page 123
CPI field carries (unframed) client characters
max. length: 65535 byte - payload header - pFCS
More payload spefics on the next slides!
Payload
Area
Client
Payload
Information
(CPI)
Optional
Payload FCS
pFCS - Payload Frame Check Sequence
Optional 32-bit control code to protect the client payload
information field
It is present if PFI=1 in the Type field (Payload
Header)
pFCS can only detect bit errors
PTI PFI EXI
UPI
tHEC
tHEC
GFP - Frames Overview
Core Header
PLI
PLI
cHEC
cHEC
Payload
Headers
Payload
Type
4
Page 124
CID
Spare
eHEC
eHEC
Payload
Area
8 bit
Client
Payload
Information
Optional
Payload FCS
Extension
Header
Field
4 - 65535
GGFP FP --
OOperation peration
MModes odes MModes odes
GFP Operation Modes
GFP-T (Transparent Mapped):
Client characters are directly mapped in GFP-T
00
GFP-F (Framed Mapped):
For packet oriented clients, e.g. Ethernet
One Client Packet = packed in one GFP frame (1:1)
Minimal overhead
Page 126
GFP IDLE Frame:
Rate Adaptation (stuffing)
GFP Management Frame:
under study
Client characters are directly mapped in GFP-T
frames e.g. Fibre Channel
Fixed length GFP frames
Minimal Latency
GFP Operation Modes
1GigE
GFP-F
Frame by Frame
GFP
Ethernet Frame
GFP GFP GFP
Eth
GFP GFP
Eth. Frame
variable
Page 127
GFP-T
1GigE
IDLE LE Eth Eth. Frame IDLE Ethernet Frame
Transparent
GFP
Transparent
GFP
Transparent
GFP GFP
GFP GFP Header or IDLE frames
Block by Block
fixed
GFP
GFP-F Client vs. Transport Rate
Variable Client Rate
GFP-F
Mbit/s
F
I
F
O
IDLEs
+
M
a
p
p
e
Constant Transport Rate
Mbit/s
Page 128
t
O
GFP-F Mapper
+
e
r
t
GFP-F IDLEs
Client
Ethernet
Fast Ethernet
Gigabit Ethernet
IP
PPP
GFP-T Client vs. Transport Rate
M
a
p
p
Decoder
/ Coder
100+x %
GFP-T
Mbit/s
Constant Client Data Rate
100 %
Mbit/s
Constant Transport Rate
Page 129
GFP-T Mapper
p
e
r
/ Coder
t
Effective Payload
Client IDLEs
Fibre Channel
ESCON
FICON
Gigabit Ethernet
10 GigE
Anything!
t
GFP Overhead
Effective Payload
Client IDLEs
GGFP FP --
FFraming raming
PProcedures rocedures PProcedures rocedures
GFP Procedures
GFP supports six basic procedures:
1. Frame delineation
2. Client multiplexing
3. Frame multiplexing
4. Header Scrambling
Page 131
4. Header Scrambling
5. Payload Scrambling
6. Client Management
GFP - Frame Level Processes
Frame
MUX
GFP IDLE
GFP Client
Management
Byte streams with
GFP Data Frames
with client-specific payload
Payload
Scrambler
Core Header
Scrambler
Byte Stream to
Transport Payload
Page 132
Frame
DEMUX
GFP IDLE
Frames Insertion
Transport Payload
GFP IDLE
Frames Termination
GFP Client
Management
GFP Data Frames
to client Byte streams
Payload
Descrambler
Core Header
check
Byte Stream from
Transport Payload
GFP - Frame Delineation
PLI
Payload
GFP
Variable length 4 to 65539 Byte
..... its all about synchronisation!
Page 133
GFP uses
the Payload Length Indicator and
the Core Header protection field
for frame synchronization
P
L
I
P
L
I
c
H
E
C
c
H
E
C
CRC-16
Payload Length Indicator
GFP - Frame Delineation
110100010010111110100100011010010101001111110010010100101001000101111010010101001010101010010111101
PLI cHEC
Comparer
2 byte 2 byte
CRC-16
Expected next Core Header
Page 134
CRC-16
1. HUNT State
Searching for a correct formated
4 byte Core Header
Byte by Byte search
Bit Error Correction = disabled
2. PreSync State
Jump to the next correct Core
Header using PLI info
Frame by frame search for x
consecutive correct cHECs
Bit Error Correction = disabled
Successful? - Yes
3. Sync State
Jump to the next frame using PLI
Single Bit Error Correction = enabled
Detection of Multiple Bit Errors?
PreSync
PreSync
Frame-by-Frame
GFP - Frame Delineation Diagram
next
cHEC
incorrect
PreSync
PreSync
Frame-by-Frame
X 1
consecutive
correct
cHECs
Page 135
IDLE frames participate in the synchronization process!
HUNT
correct
cHEC
detected
Multiple-Bit Errors
detected
(Incorrect HEC)
correct
cHEC
detected
Sync
Frame
-by-
Frame
Byte-by-Byte
PreSync
PreSync
Frame-by-Frame
GFP - Frame Delineation Diagram
next
cHEC
incorrect
PreSync
PreSync
Frame-by-Frame
X 1
consecutive
correct
cHECs
Page 136
IDLE frames participate in the synchronization process!
HUNT
correct
cHEC
detected
Multiple-Bit Errors
detected
(Incorrect HEC)
correct
cHEC
detected
Sync
Frame
-by-
Frame
Byte-by-Byte
GFP - Frame & Client Multiplexing
GFP Signals from multiple ports or clients are multiplexed
on a frame by frame basis
GFP IDLE cells are transmitted in case of no other clients
GFP - a mapper build inside
eHEC
eHEC
CID
Spare
1..256
signals
GFP Streams
with different clients
Page 137
eHEC
Linear Extension
Header
GFP
Mux
with different clients
IDLE
Insertion
CID=0 CID=2 CID=1 CID=1
CID=0 CID=0
CID=0
CID=1 CID=1
CID=1
CID=2 CID=2
CID=2
GFP - Scrambling
Core Header Scrambling
Reason:
Provides sufficient 01 transitions
Improves frame delineation process
XOR Scrambler
00 00 00 00
Core Header
Scrambler Code
B6 AB 31 E0
+
B6 AB 31 E0
IDLE Frame on transmission
Page 138
Improves frame delineation process
Reason:
Security against payload
information replicating the
scrambling word from frame
synchronous scramblers in
SONET/SDH or OTN
B6 AB 31 E0
Payload Scrambling
Client
Payload
Information
Payload
Headers
Optional
Payload FCS
X
43
+1 Scrambler
D1
+
D43
Scrambler is only enabled in SYNC STATE!
GFP - Client Management
A GFP source to GFP sink Client Signal Failure (CSF)
indication process is implemented:
CSF Detection is client specific!
GFP Source GFP Sink
Transmission
Detection of Client failure
at ingress?
no
Page 139
CSF Frames:
UPI=01 Loss of Client Signal or
UPI=02 Loss of Client Sync.
Declares Sink Client
Signal failure
Valid GFP Frame Received?
No CSF for Nx 1000ms?
Sends Client Mgmt. Frame
(PTI=100) every 100-1000ms
CSF
yes
at ingress?
Clear Failure Status
yes
no
Send IDLE Frames only
IDLE
Defect Handling
GFP Common Process
GFP Client Specific
(= Source Adaptation Process)
Ingress Client Process
(= Client Access Point)
GFP Common Process
GFP Client Specific
(= Source Adaptation Process)
Ingress Client Process
(= Client Access Point)
X
X
CSF
X
SSF
Page 140
Transport Network
GFP Common Process
(= Client Source Adaptation)
Transport Network
GFP Common Process
(= Client Source Adaptation)
Physical Connection
X
Point of Failure Detection
Failure Indication
Indicators:
CSF = Client Signal Fail
SSF = Server Signal Failure
TSF = Trail Signal Fail
X
X
TSF
GGFP FP -- F F
PPayload ayload
SSpecifics pecifics SSpecifics pecifics
Ethernet MAC Payload
7+1 Byte
Preamble
4 Byte
CRC
Payload
(und ggf. Padding)
6 Byte
Source
Address
6 Byte
Dest.
Address
2 Byte
Type /
Length
6 Byte
Source
Address
6 Byte
Dest.
Address
7+1 Byte
Preamble
4 Byte
CRC
Payload
(und ggf. Padding)
2 Byte
Type /
Length
46 ... 1500 Byte
2 Byte
Type =
8100
2 Byte
Prio, /
VLAN
Page 142
802.2 LLC
1Byte
DSAP
1Byte
SSAP
1Byte
CTRL
Payload
(und ggf. Padding)
802.2 SNAP
3 Byte
OUI
2 Byte
PrID
Payload
(und ggf. Padding)
8 7 6 5 4 3 2 1 0
1 0 0 1 0 0 0 0 0
0 0 0 0 0 0 0 0 0
VLAN IDENTIFIER
User
Priority
CFI
AA AA 03
000000 0800
IP Payload
(und ggf. Padding)
GFP & Ethernet MAC Payload
Source Address
Destination Address
Preamble
Start of Frame Delimeter
Bytes
7
1
6
6
tHEC
Type
PLI
cHEC
GFP Extension
Header
2
2
2
2
0-60
Bytes
Source Address
Destination Address
Page 143
Source Address
Length/Type
MAC Client
Pad
Frame Check Sequence
2
6
4
46-
1500
GFP
Payload
As
Client
Ethernet MAC Frame
GFP-F Frame
Source Address
Length/Type
MAC Client
Pad
GFP & Ethernet MAC Payload
tHEC
Type
PLI
cHEC
GFP Extension
Header
Source Address
Destination Address
Length/Type
E
t
h
e
r
n
e
t
G
F
P

H
e
a
d
e
r
Ethernet Inter-Packet-Gas are deleted before
encapsulation and restored after transmission
Byte alignment and bit identification is
maintained
Page 144
GFP
Payload
MAC Client
Pad
FCS
E
t
h
e
r
n
e
t
Ethernet to GFP-Framed
Up to 10M
Ethernet Stream
5M
7.5M
10M
t
1 2 3 4
2.5M
Pure Ethernet
GFP Packet
Payload
Core Header
Page 145
Pure Ethernet
Constant Stream
Result
GFP-F Packet GFP-IDLE Packet
00hex
00hex
00hex
00hex
Payload
cHEC
PLI
2
2
X
Scrambling!
GFP-Framed to VC
GFP-Framed
Packet Stream
5M
7.5M
10M
t
1 2 3 4
2.5M
GFP Stream
Byte-Interleaving
Page 146
GFP Stream
VC-12
#5
VC-12
#4
VC-12
#3
VC-12
#2
VC-12
#1
GFP Frames
in VC containers
Transport Thru the Network
Transport
IP & PPP Payload
Flag
Control
Address
Bytes
1
1
1
tHEC
Type
PLI
cHEC
GFP Extension
Header
2
2
2
2
0-60
Bytes
Control
Address
Page 147
Control
PPP Type
PPP Information
Pad
2
1
4
GFP
Payload
As
Client
PPP/HDLC Frame
GFP-F Frame
Control
PPP Type
PPP Information
Pad
PPP Payload
PPP Protocol
Bytes
1-2
1
tHEC
Type
PLI
cHEC
GFP Extension
Header
2
2
2
2
0-60
Bytes
PPP Protocol
Page 148
PPP Information
PPP Padding
(optional)
2
1
4
GFP
Payload
As
Client
PPP/HDLC Frame
GFP-F Frame
PPP Information
PPP Padding
(optional)
Ethernet to GFP-F Scheme
Ethernet Control
Character Termination,
e.g.
MAC Frame
Extraction
Ethernet Switch
or Bridge
MAC to GFP-F
Encapsulation
Control
Termination
Page 149
GFP-F stream mapped
to VC container
VC-n or
VC-n-Xv
Ethernet
Fast Ethernet
GigEthernet
10Gig Ethernet
PHY-x
Ethernet Decode/
Clock Recovery
Error Handling
GFP Source process detects client errors before transmission
Client packets should be discarded by the GFP process
No transmission of errored packets
GFP Source process detects client errors while in transmission
Page 150
GFP Source process detects client errors while in transmission
Padded up with all ones bit sequences
Complement all payload FCS (if present) and transmit
Result: GFP Sink process will discard errored packets
Or Client Process will discard errored packets
Generic Frame Procedure
GFP
Reliable
Easy & stabile
algorithm
Header Correction
Expandable
with no need for
new transport
equipment
Page 151
GFP
BENEFITS
New
Opportunities
Technological &
Economical
Compatible
works with basically
any higher layer
service and lower
layer network!
LLink ink
AAccess ccess
PProcedure rocedure PProcedure rocedure
SSDH DH
And what about LAPS?
Link
Access
Competitive
standard for
GFP
Much more
limited
capabilities
than GFP
Page 153
Access
Procedure
SDH
Only for SDH,
Only for CC
Similar to PoS/
HDLC
Standardized ITU-T X.85 & X.86, Asian Initiated Standard.
PProduct & roduct &
AApplications pplications AApplications pplications
Applications in the network
Native Data Services for the customer
Ethernet Private Lines
Virtual Local Area Networks
Storage Area Networks
Bandwidth on demand
Manually, Automatically or on schedule
Page 155
Customized QoS agreements
Premium, Business or Economy Class
Over-subscription
Multi-Path Traffic Routing
New Business Models are possible! See
examples at Appendix!
Acternas Solution
ONT-50
New SONET/SDH up to 2.5G
2.5G SONET/SDH Interfaces
High Order Virtual Concatenation
Basic LCAS Protocol Emulation
GFP Generation
GFP Analyses
Ethernet Frame Generation/Analyses
1
st
Release
April 2003
Page 156
Ethernet 1GigE Interfaces
Multi-port Interfaces
Enhancements onNew SONET/SDH
New VC, LCAS, GFP functionality
Acternas Solution
ONT-50
Page 157
Acternas Solution
ONT-50
Page 158
Acternas Solution
ONT-50
Page 159
New SONET - the evolution of SONET
Data Services - Ethernet, Fibre Channel & others
GFP - frames the data & adapts the rates
VC - offers right sized pipes in fine granularity
LCAS - makes VC easy & flexible on demand
Result :
Page 160
Ethernet
Ficon
Escon
Fibre
Channel
SONET/
SDH
M
U
X
/
D
M
U
X
N
a
t
i
v
e

I
n
t
e
r
f
a
c
e
s
?
GFP
Generic
Frame
Procedure
LCAS
Link
Capacity
Adjustment
Scheme
VC
Virtual
Concatination
Result :
SONET/SDH is flexible & data aware!
AApplications pplications
E
t
h
e
r
n
e
t

I
F
S
O
N
E
T

/

S
D
H
Testing Tasks - New SONET/SDH
VC
New Edge Network Element
LCAS
GFP
! ! !
Measurement
Access
Point
Measure.
Access
Point
Conversion
Page 162
E
t
h
e
r
n
e
t

I
F
S
O
N
E
T

/

S
D
H
! !
No direct measurement
access points!
!
!
Point
Only end-to-end measurements
Internal Loop Back
Testing Tasks - VC
Multiple Container Handling Tests
e.g. Overhead, Pointer, etc.
Test of various bandwidth configurations
STS-1
STS-1
STS-1
STS-1
VC-4
STS-1
STS-1 VC-4
RSOH
AU-4 Pointer
MSOH
VC-4-1 VC-4-2
VC-4-5 VC-4-6
VC-4-11 VC-4-12
VC-4-3 VC-4-4
VC-4-7 VC-4-8
VC-4-9 VC-4-10
Page 163
Delay Store
VC-4
#2
VC-4
#1
VC-4
#2
VC-4
#1
Re-Assemble
VC-4
#2
VC-4
#1
Segmentation
Segmentation and Re-assembly of the payload
Differential Delay generation and analysis
STS-1
VC-4
Re-configure
Map
MSOH
VC-4-15 VC-4-16 VC-4-13 VC-4-14
Testing Tasks - LCAS
Network Transparency Testing
Testing the Interworking with VC
Protocol Emulation for up and down stream
Add and remove VC bandwidth
Page 164
LCAS down stream
LCAS up stream
TX
RX
RX
TX
1 7 2 3 4 5 6 8 9 12 10 11 13 19 14 15 16 17 18 20 21 24 22 23 25 31 26 27 28 29 30 32
CRC
-3
Member Status
Frame
Count
Sequence
Indicator
CTRL
G
I
D
Spare
R
S-
A
C
K
Low Order LCAS
Control Frame
Testing Tasks - GFP
Header generation and analysis eg. correctable &
uncorrectable header
Rate Adaptation Testing to the transport
bandwidth
Generation of GFP management frames
Page 165
GFP Mapping & Demapping of service payload
SOH
STS Pointer
LOH
STS-1-1 STS-1-2 STS-1-3 STS-1-4
STS-1-5 STS-1-6 STS-1-7 STS-1-8
STS-1-9 STS-1-10 STS-1-11 STS-1-12
STS-1
STS-1
STS-1
STS-1
VC-4
Ethernet
C
o
r
e

H
e
a
d
e
r
E
t
h
e
r
n
e
t
P
a
y
l
o
a
d
Mapping Mapping Mapping
Overhead (OH) OH OH OH
SONET Virtual Concatenation GFP Ethernet
Bandwidth on demand
Bandwidth Call-by-Call
NG
NG
Network Management
VC-12-3v
LCAS
Page 166
Transport Network
NG
NG
ISP
Customers LAN
Customer
rents a 6M Internet connection (VC-12-3v)
calls to get additional 2M!
Operator
will provision additional VC-12 path
..and will hitless add it to existing connection via LCAS!
+VC-12
LCAS
Bandwidth on demand
Bandwidth on Schedule
Transport Network
NG
NG
100M 100M
900M
900M
100M
900M
Page 167
Location A Location B
Offer a fixed bandwidth schedule:
24/7 - Virtual Local Area Network service at 100M Ethernet
Every night for one hour - additional 900M ESCON service for
data backup
New revenue opportunities at low traffic hours!
900M
900M
900M
Bandwidth on demand
Ethernet Traffic
1
st
VC-12
2
nd
VC-12
3
rd
VC-12
Variable
VCG capacity
Automatic Bandwidth Allocation - pay as you grow!
Page 168
t
1 2 3 4
VCG capacity
Automatic Bandwidth Allocation:
Automatically, pre-provisioned VC capacity will be activated
No paid, but unused link capacity for the customer
Customized SLA possible!
Optimal bandwidth for the customer for min. $$
New revenues with pay per use & over-subscription!
New Protection Schemes
50 Mbit/s
Ethernet
VC-12-8v
VC-12-8v
50 Mbit/s
Ethernet
VC-12-9v
On Failure - 34 M
Regular - 50 M
Page 169
If different VCG members are diversely routed...
LCAS can provide a fault recovery mechanism add. to SONET
Failed VCG members will be removed
A connection at lower speed will remain!
Network Management has time to reroute the link!
Differentiated services on customer side!
Offers Customized soft protection at various
service levels!
LCAS Transmitter (TX) with non-LCAS Receiver (RX)
TX will send MFI and SQ according to G.707 or G.709
RX will ignore all other bits of the control packet
The reported member status (RX to TX) will be MST=0 = OK
Interworking
Does LCAS and non-LCAS virtual concatenation equipment
work together?
Page 170
Interworking possible
Non- LCAS Transmitter (TX) with LCAS Receiver (RX)
RX expects a CTRL word, which is not 0000 and a correct
CRC field
TX will send CTRL = 0000 and CRC = 0
The LCAS RX shall ignore all information except MFI and SQ
Interworking possible
GFP Technical Application
Ethernet over SDH/SONET
1GE ADM
H4
H4
H4
PLI
PLI
cHEC
cHEC
Type
Type
tHEC
tHEC
Ethernet Frame GFP Frame VC-4-3v STM-16
Page 171
1GE ADM
...
...
tHEC
H4
H4
H4
H4
H4
H4
H4
H4
H4
TThank hank yyou! ou!
Standards Standards Standards Standards
References
ITU-T
G.707/Y.1322 Network Node Interface for SDH (10/2000)
G.709 Network Node Interface for Optical Transport Networks
G.7041/Y.1303 Generic Frame Procedure (12/2001)
G.7042/Y.1305 LCAS for Virtually Concatenated Signals
(11/2001)
X.85 IP over SDH using LAPS
X.86 Ethernet over LAPS
Page 174
ANSI
T1.105 Synchronous Optical Network
Virtual Conc.
LCAS (also refers to ITU-T G.7042)
GFP refers to ITU-T G.7041
IEEE
Ethernet: 802.3
Abbreviations Abbreviations Abbreviations Abbreviations
Abbreviations
CC: Continguous Concatenation
cHEC: Core Header Error Check
CRC: Cyclic Redundancy Check
EOF: End of Frame
EoS: Ethernet over SONET
ESCON: Enterprise Systems
Connection
FCS: Frame Check Sequence
FD: Full Duplex
MAN: Metropolitan Area Network
MFI: Multi Frame Indicator
MSOH: Multiplexer Section Overhead
NE: Network Element
OTN: Optical transport Network
OSI: Open System Interconnect
PDU: Protocol Data Unit
PLI: PDU Length Indicator
PoS: Packet over Sonet
Page 176
FD: Full Duplex
FICON: Fibre Connection
GFP: Generic Frame Procedure
GFP-F: Frame mapped GFP
GFP-T: Transparent GFP
GMPLS: Generalized Mulitprotocol
Label Switching
IP: Internet Protocol
LAN: Local Area Network
LAPS: Link Access Procedure SDH
LCAS: Link Capacity Adjustment
Scheme
MAC: Media Access Control
PoS: Packet over Sonet
PPP: Point-to-Point Protocol
RSOH: Repeater Section Overhead
SAN: Storage Area Networks
SDH: Synchronous Digital Hierachy
TCP: Transport Control Protocol
TDM: Time Division Multiplexing
VC: Virtual Concatenation
VC-xc: Virtual Container
VCG: Virtual Container Group
WAN: Wide Area Network

Training New SDH All

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Training New SDH All

Uploaded by

Copyright:

Available Formats

NNew ew

You might also like