EETHERNET THERNET

OOVER VER
SSDH DH
END
Narket S Technology Drivers
New SONET/SDH Overview
virtual Concatenation (vC)
Link Capacity Adjustment Scheme (LCAS)
Ceneric Frame Procedure (CFP)
THE SITUTION
The economic situation in the Telecom
!ndustry has changed...
...and so has the technological approach to meet
new challenges!
THE FUTURE
SONET/SDH
Network
SONET/SDH for
VOICE
Services
Seen Status
One new network for both appIications!
N
Fully Routed
Optical P
Network
Optical P for
DT
Services
uture Network
THE STTUS TOD
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 speed than expected
network topoogies focusing on a IP/Ethernet ONLY
approach are shifted to longterm future.
The future today:
Bring SDH and Ethernet together!
NEW NETWORK REQUIREMENTS
Storage rea
Network (SN)
Virtual Private
Network
(VPN)
Edge Network
Core Network
Storage Server
N
N
PC
Server
SONET/SDH
Ethernet
Fibre Channel
RININ IT TOETHER
Operator wants:
W Reduce Operational Expenses
W Realize revenue-earning services
W &se bandwidth of Core Network
W ow investment immediate Returns
W Close the edge bottleneck!

Customer expects:
W "oS & BW at low costs
W Native Data nterfaces
W &se & mprove what he knows!
Edge
Core
N
SN
Voice
N Next ext eneration eneration
SSDH DH
OOverview verview
OIN INTO DETIS
Lets zoom in!
Campus
Ethernet
OpticaI Core OpticaI Core
Network Network
Remote
Servers
Storage
Servers
Fibre
ChanneI
SONET/SDH SONET/SDH
DWDM DWDM
SONET/
SDH
SONET/
SDH
SONET/
SDH
Campus
Ethernet
FICON
Core NE
Edge NE
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
N SDH at the
Edge
That's " N SDH "
?
VC
Virtual
Concatenation
LCS
Link
Capacity
Adiustment
Scheme
GP
Generic
Frame
Procedure
LPS
Ethernet
icon
Escon
ibre
Channe
Edge Core
daptation
Customer Operator
CUSTOMER NEEDS ETHERNET
Typical
Ethernet Traffic
Connections
Mbit/s
1 2 3 4
Ethernet Packet
ProbIem: How can we efficiently transport Ethernet over an
existing SDH network?
Example: For 10N available SDH Containers are...
VC-12 ...too smaII !
2.176 Mbit/s
VC-3
... inefficient
20%
48.38 Mbit/s
OR
100
25
50
75
time
Customer 3 = 100M
Customer 2 = 60M
Customer 1 = 10M
SDH INE RTES
10 M
Transport
10M Ethernet over SDH?
C-4-4c 0.599 bit/s
C-4-16c 2.396 bit/s
C-4-64c 9.584 bit/s
C-4-256c 38.338 bit/s
Contiguous Concatenation
Contiguous
Concatenation
onIy Iarge containers!
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 PayIoad Sizes
Standard
Containers
are inefficient!
Can't 5 x VC-12 be concatenated?
?
5x
VVirtuaI irtuaI
C Concatenation oncatenation
VC-n-v
C-4-4c 599.040 Mbit/s
C-4-16c 2.396 bit/s
C-4-64c 9.584 bit/s
C-4-256c 38.338 bit/s
Contiguous Concatenation
CONCTENTION?
Contiguous Concatenation
Offers concatenated payloads in fixed, large steps One towing truck (POH) for all containers
All containers are on one path thru the network
VC-4-4c
C4 C4 C4 C4
CONCTENTION?
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
MSOH
RSOH
U-4 Pointer
STM-N
CC: VC-4-c Container
Overhead N x 9 bytes Payload N x 261 bytes
VC-4-c, where =4, 16, 64, 256
VC-4-c
X x 261 bytes
X -1 1
J1
C2
1
H4
F3
K3
N1
C-4-c
F
i
x
e
d

S
t
u
f
f
3
F2
MSOH
RSOH
U-4 Pointer
STM-N
VC: VC-4-v Container
Overhead N x 9 bytes Payload N x 261 bytes
VC-4-v, where = 1..256
261 bytes
1
VC-4
J1
C2
1
H4
F3
K3
N1
3
F2
VC-4
J1
C2
1
H4
F3
K3
N1
3
F2
VC-4
J1
C2
1
H4
F3
K3
N1
3
F2
X frames
virtual Concatenation is standardized
with SONET containers (ANS! T.10S) or
SDH containers (!TUT C.707)
virtual Concatenation provides
a scheme to build rightsized SONET/SDH
containers
virtual Concatenation offers
a very fine granularity
VIRTU CONCTENTION
(VC OR VCT)
VC NOMENCTURE
VC-n
VirtuaI Container n
n=4, 3, 2, 12, 11
Defines the type of virtual
containers, which will be
virtually concatenated.
-
Number of
virtuaIIy
concatenated
containers
ll X Virtual Containers
form together the
"VirtuaI Concatenated
roup" (VC)
v
Indictor for
VirtuaI
Concatenation
v = virtual
concatenation
c = contiguous
concatenation
VirtuaI Concatenated roup (VC) of VC-n containers!
HIH ND OW ORDER VC
High Order virtual Concatenation
W refers to virtually concatenated...
VC-4
VC-3
containers
Low Order virtual Concatenation
W refers to virtually concatenated...
VC-11
VC-12
VC-2
containers
VC-4-V RNURIT
VC ranuIarity
VCG Payload
Capacity
Maximum
Minimum
VCs:
VC-4-1v Payload Size 149,76 Mbit/s
VC-4-2v Payload Size 299,52 Mbit/s
VC-4
Exampe High Order VC:
VC-4 Container Size 150,3 Mbit/s
VC-4 Payload Size 149,76 Mbit/s
VC-4-7v Payload Size 1048,3 Mbit/s
VC-4-256v Payload Size 38338 Mbit/s
VC-12-V RNURIT
Example Low Order vC:
VC-12 Container Size 2,240 Mbit/s
VC-12 Payload Size 2,176 Mbit/s
Minimum
VC ranuIarity
vCCs:
vC121v Payload Size 2,176 Nbit/s
vC122v Payload Size 4,3S2 Nbit/s
VCG Payload
Capacity
Maximum
VC-12-5v Payload Size 10,88 Mbit/s
VC-12-64v Payload Size 139,26 Mbit/s
VC-12
VC RNURIT ND M.
CPCIT
Nomenclature Cranularity Nax. 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-12 -n v 2.2 M - 139 M
VC-11 -n v 1.6M - 102 M
VC-4
VC-3
VC-2
VC-12
VC-11
Maximum Concatenation: = 256 containers
Max. Capacity: = 256 x granuIarity
VC RTE EFFICIENCIES
Ethernet (10M) VC3 20% VC-12-5v 92%
100M Ethernet
STM-1
64 x VC-12
VC-12-5v
VC-12-46v
2x 10M Ethernet
VC-12-5v
8x E1 Services
Exampe:
More services integrated- by using VC!
Fast Ethernet (100M) VC-4 67% VC-12-46v 100%
Data Rates Efficiency w/o vC US!NC vC
Gigabit Ethernet (1G) VC-4-16c 42% VC-4-7v 85%
ESCON (200M) VC-4-4c 33% VC-3-4v 100%
Fibre Channel (800M) VC-4-16c 33% VC-4-6v 89%
TRNSPORTIN CONCTENTED
SINS
VC-4-2v
v!RTUAL CONCATENAT!ON
VC-4
#2
VC-4
#1
VC-4
#1
Path 2
Path 1
VC-4
#2
DifferentiaI DeIay
VC-4
#2
VC-4
#1
VC-4
#2
VC-4
#1
CONT!CUOUS CONCATENAT!ON
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
VVirtuaI irtuaI
C Concatenation oncatenation
TechnicaI TechnicaI
DetaiIs DetaiIs
VIRTU CONCTENTED ROUPS
Answer:
The containers do not know it!
That's the job of the network management!
$uestion:
How does a container know that it belongs to a vCC?
$uestion:
Which containers can belong to the same group?
Answer:
They must all start at one port!
And they must all end at one port!

B

VIRTU CONTINER INDICTOR
Problem:
How to distinguish between vCC members of one group?
SQ=0
SQ=1
SQ=2
SQ=3
Solution:
Cive each member an individual number plate!
Sequence Indicator (SQ)
VC-4
VC-4
VC-4
VC-4
TIME STMP MECHNISM
VC-4
VC-4
VC-4
VC-4
Problem:
How do we know that members arriving together started together?
Solution:
Cive each vCC an individual number
Frame Counter (FC)
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
VC REINMENT
Demapping
rrivaI
SQ = 1
FC = max
SQ = 0
FC = max
SQ = 3
FC = max
SQ = 1
FC = max
SQ = 0
FC = max
SQ = 3
FC = max
SQ = 1
FC = 0
SQ = 0
FC = 0
SQ = 2
FC = max
SQ = 3
FC = 0
SQ = 1
FC = max
SQ = 0
FC = max
SQ = 2
FC = max
SQ = 3
FC = max
SQ = 1
FC = 0
SQ = 0
FC = 0
SQ = 3
FC = 0
SQ = 1
FC = 1
SQ = 0
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = max
SQ = 0
FC = max
SQ = 2
FC = max
SQ = 3
FC = max
SQ = 1
FC = 0
SQ = 0
FC = 0
SQ = 3
FC = 0
SQ = 2
FC = 0
SQ = 1
FC = 1
SQ = 0
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = max
SQ = 0
FC = max
SQ = 2
FC = max
SQ = 3
FC = max
SQ = 1
FC = 0
SQ = 0
FC = 0
SQ = 3
FC = 0
SQ = 2
FC = 0
SQ = 1
FC = 1
SQ = 0
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = 2
SQ = 0
FC = 2
SQ = 2
FC = 1
SQ = 3
FC = 2
SQ = 1
FC = 0
SQ = 0
FC = 0
SQ = 3
FC = 0
SQ = 2
FC = 0
SQ = 1
FC = 1
SQ = 0
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = 2
SQ = 0
FC = 2
SQ = 2
FC = 1
SQ = 3
FC = 2
SQ = 1
FC = 0
SQ = 0
FC = 0
SQ = 3
FC = 0
SQ = 2
FC = 0
SQ = 1
FC = 1
SQ = 0
FC = 1
SQ = 3
FC = 1
SQ = 1
FC = 2
SQ = 0
FC = 2
SQ = 2
FC = 1
SQ = 3
FC = 2
SQ = 1
FC = 3
SQ = 0
FC = 3
SQ = 3
FC = 3
SQ = 2
FC = 2
Stop
SQ=2 is one frame Iate!
DIFFERENTI DE
Problem:
Each individual container of a vCC might take a different
route through the network Delay?
Result: Differential Delay
Different physical path lengths will result in different path delays for individual
containers!
Propagation Delay (optical fiber):
is approximately S s/km
1000km extra path length = Sms Differential Delay
Once around the earth Extra (42.000km) = 210ms DD
Solution:
A container storage S realignment process is necessary
to compensate for differential delay!
How the group starts:
Network
How the group arrives:
Storage Demapping
Differential Delay Example
ExampIe:
VC-4-2v group routed over TWO paths
W Container S"=0 1000km 5.0 ms propagation time
W Container S"=1 1075km 5.375 ms propagation time
Differential Delay = 5.375ms-5.0ms = 0.375ms (=3 frames)
SQ = 0
FC = 0
SQ = 1
FC = 0
SQ = 0
FC = 0
SQ = 1
FC = 0
SQ = 0
FC = 1
SQ = 1
FC = 1
SQ = 0
FC = 0
SQ = 1
FC = 0
SQ = 0
FC = 1
SQ = 1
FC = 1
SQ = 0
FC = 2
SQ = 1
FC = 2
SQ = 0
FC = 0
SQ = 1
FC = 0
SQ = 0
FC = 1
SQ = 1
FC = 1
SQ = 0
FC = 2
SQ = 1
FC = 2
SQ = 0
FC = 3
SQ = 1
FC = 3
SQ = 0
FC = 0
SQ = 1
FC = 0
SQ = 0
FC = 1
SQ = 1
FC = 1
SQ = 0
FC = 2
SQ = 1
FC = 2
SQ = 0
FC = 3
SQ = 1
FC = 3
SQ = 0
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
DE TIMES
Problem:
hat's the maximum differential delay time?
FC = 0
SQ=0
FC = 0
SQ=1
FC = 1
SQ=0
FC = 1
SQ=1
FC = max
SQ=0
FC = max
SQ=1
FC = 2
SQ=0
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
TotaI DifferentiaI DeIay Time (s) =
1 x Frame Repetition Rate
No DeIay
oth containers
arrive at the
same time!
Container SQ=1
arrives with
ONE frame deIay
M. DE COMPENSTION
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 DifferentiaI DeIay 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
PayIoad is OST!
FC=max frames
deIay of SQ=1
FC = 0
SQ=1
Too much DeIay
FC = max+1 frames
VC is out of synch!
WHERE RE THE VC TES?
WCarried in one bit in K4-Byte
32 frame Multi-Frame
High Order vC Low Order vC
W nformation in H4 Byte
16 frame Multi-Frame
2
H4
3
K3
B3
C2
G1
11
N1
VC-3 / VC-4
out of
VC-3-Xv / VC-4-Xv
12
N2
K4
V5
VC-2 / VC-11/VC-12
out of
VC-2-Xv / VC-11-Xv /VC-12-Xv
WHT'S MUTI-FRME?
12
N2
K4
V5
VC-2 / VC-11/VC-12
out of
VC-2-Xv / VC-11-Xv /VC-12-Xv
Low Order vC
rame
Counter
(C)
Sequence
Indicator
(SQ)
Reserved...
How to buiId a muIti-frame controI packet?
W Filter from each K4 byte only bit no. 2
W Store bit no. 2
W fter 32 VCs, one Virtual Concatenation
W control information was received.
1
K4
b2
FiIter
2
32x
K4
b2
3
K4
b2
4
K4
b2
5
K4
b2
6
K4
b2
7
K4
b2
8
K4
b2
9
K4
b2
11
K4
b2
12
K4
b2
13
K4
b2
14
K4
b2
15
K4
b2
16
K4
b2
10
K4
b2
17
K4
b2
18
K4
b2
19
K4
b2
20
K4
b2
21
K4
b2
22
K4
b2
23
K4
b2
24
K4
b2
25
K4
b2
27
K4
b2
28
K4
b2
29
K4
b2
30
K4
b2
31
K4
b2
32
K4
b2
26
K4
b2
...for CS
High Order vC H4 byte
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
MFI1 MFI2
n
H4 yte MuIti-Frame
it 1 - 4 it 5 - 8
Reserved "0000"
Reserved "0000"
Reserved "0000"
Reserved "0000"
Reserved "0000"
Reserved "0000"
Reserved "0000"
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
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
MFI2 (bit 1-4)
MFI2 (bit 5-8)
8 bit
SQ (bit 1-4)
SQ (bit 5-8)
8 bit
Time for transmitting ONE multiframe: 16 byte x 12Ss = 2ms
NF! 1 Nulti Frame !ndicator 1
4 bits Counter incremented at each individual frame
One NF!1 multiframe = 16 frames
Counts from 0 to 1S
NF! 2 Nulti Frame !ndicator 2
8 bits Counter incremented every 16 frames after a complete NF!1 multiframe
Counts from 0 to 2SS
High Order vC Frame Counter:
NF!1 x NF!2 = 16 x 2SS = 4036
Nax. tolerable Differential Delay = 4036 x 12S s = S12ms
S$ Sequence !ndicator
8 bits Transmitted once every NF! 1 multiframe
Nax. number of High Order vCC members = 2S6
HIH ORDER VC - H4 TE
OW ORDER VC - K4 TE
K4 byte (VC-2. 11. 12)
-it 1:Extended Signal la-el - 32 Irame multi-Irame
-it 2: Low order Virtual concatenation
-it 2: 32 Irame MF should -e in phase with -1 multi-Irame
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
MS Mutiframe
aignment bits
0111 1111 110
Extended Signa
Labe
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
Reserved 0
rame
Count (C)
Sequence
Indicator (SQ)
Time for transmitting ONE muIti-frame:
ength of MF x Frame Repetition Rate
32 bit x 500s = 16ms
Low Order VC rame Counter:
FC x Length oI Multi-Frame x Frame Repetition Rate
Max. tolera-le DiIIerential Delay 32 x 32 x 500s 512ms
C - Multi Frame Indicator
5 -its - Counter incremented with each 32 -it multi-Irame
Counts Irom 0 to 31
OW ORDER VC - K4 TE
SQ - Sequence Indicator
6 -its - Transmitted once every 32 -it multi-Irame
Max. num-er oI Low Order VCG mem-ers 64
ow
Investment
deployment only on
customer demand
Fast RO
VC
ENEFITS
EconomicaI
Re-use core
network
equipment
invest only at the
edge
WeII-known
SONET/SDH is
well engineered &
reliable & trained
Efficient &
ScaIabIe
Fine granularity
& multi-path
capability
VIRTU CONCTENTION
ENEFITS
CHENES HED...
How can path bandwidth be increased or decreased?
Dynamic Bandwidth Provisioning
'..-ring an additional truck on the road..
VC-3 #1 VC-3 #2
VC-3 #?
VC-4 #1 VC-4 #3
ILED
How can we ensure QoS for data services?
VCG - Protection one VC container Iails - the whole Virtual
Concatenation Group (VCG) Iails!
INK INK
C CPCIT PCIT
DJUSTMENT DJUSTMENT
SSCHEME CHEME
CS OVERVIEW
Extension for
VirtuaI Conc.
carried in H4/K4
byte
dd/Remove
bandwidth
uninterrupted
Standardized ITU-T .7042, referred by NSI
Link
Capacity
Adjustment
Scheme
End-to-end
ReaI-Time
Communication
Handshake
ProtocoI
between edge NE
VC & CS CONTRO PCKET
rame
Counter
MI
VCG
Sequence
Indicator
SQ
VirtuaI
Concatenation
Information
LCS
Error
Protection
CRC
LCS
Member
Status
MST
LCS
Contro
Commands
CTRL
LCS
Source
Identifier
GID
LCS
Resequence
cknow-
edgement
RS-ck
CS Information
!nformation Packets exchanged between the
two edge network elements to adjust the
bandwidth.
CONTRO PCKET OVERVIEW
Information
Direction
Source Sink
MI
Muti-rame Indicator is an counter
W to distinguish several VCGs* Irom each other
W necessary to compensate Ior DiIIerential Delay
SQ
Sequence Indicator is an counter
W to diIIerentiate individual VC-n containers within a VCG*
W to re-sequence VC-n containers at the termination point in case that
diIIerential delay occured
CTRL
LCS Contro Words are
W the actual commands which will show the status oI containers Irom a
VCG* initiate -andwidth changes
W IXED - container in NON-LCAS mode
W DD - container which will -e added to a VCG
W REMOVE - container which will -e removed Irom a VCG
W NORM - container as part oI an active VCG
W EOS - last container oI an active VCG
W DNU - container with Iailures('do not use)
`VCG Virtua Concatenated Group
CONTRO PCKET OVERVIEW
GID
Group Identification Bit is
W an additional veriIication mechanism to secure that all incoming VCG
mem-ers -elong to one group
CRC
Cycic Redundancy Check is a
W protection mechanism to detect -it errors in the Control Packet
MST
Member Status ied is
W an mechanism, where the sink reports to the source which VCG mem-ers are
currently and correctly received
RS-ck
Re-sequence acknowedgement is
W an mechanism, where the sink reports to the source the detection oI any
additions/removals to/Irom the VCG
`VCG Virtua Concatenated Group
HERE ARE THE LCAS BYTES?
12
N2
K4
V5
VC-2 / VC-11/VC-12
out of
VC-2-Xv / VC-11-Xv /VC-12-Xv
2
H4
3
K3
B3
C2
G1
11
N1
VC-3 / VC-4
out of
VC-3-nv / VC-4-nV
CP = ControI Packet
W CS info aligned with VC info
W Carried in one bit in K4-Byte
W 32 frame Multi-Frame
High Order CS ow Order CS
W CS info aligned with VC info
W nformation also in H4 Byte
W 16 frame Multi-Frame
MST - Mem-er status Iield
8 -its - Status oI 8 VCG members is reported per control packet
Report time Ior all 63 mem-er statuses: 128ms
128 ms 8 packets x 16ms control packet time
GID - Group Identification Bit
1 -it - per 32 -it multi-Irame Content is a PRBS 2
15
-1
Receiver does not have to synchronize to PRBS
CTRL - LCAS Control Words
4 -its - with six possi-le control words currently deIined
One control word is transmitted per 32 -it multi-Irame
OW ORDER CS - K4 TE
RS- ck - Re-Sequence Acknowledgement
1 -it - Transmitted once every 32 -it control packet
CRC - Cyclic Redundancy Check
3 -its - to detect errors in a control packet
C!D Croup !dentification Bit
1 bit per multiframe Content is a PRBS 2
1S
1
Receiver does not have to synchronize to PRBS
CTRL LCAS Control ords
4 bits with six possible control words currently defined
One control word is transmitted per multiframe (16x H4)
H!CH ORDER LCAS H4 BYTE
RS Ack ReSequence Acknowledgement
1 bit Transmitted once every multiframe
NST Nember status field
8 bits Status of 8 vCC members is reported per multiframe
Report time for all 2S6 member statuses: 64ms
64 ms = 2S6/8 x 2ms control packet time
CRC Cyclic Redundancy Check
8 bits to detect errors in a control packet
"DD" EPINED
Request from NMS to increase bandwidth on a existing link.
1 Source
ctions for the currentIy unequipped container:
a) assign a vaIid sequence indicator (S"=currently highest
+1)
b) change CTR=DD (from CTR=DE)
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-ck toggIes)
4 Sink
With reception of acknowledgement source will change
a) the status of the Iast member from CTR=EoS to NORM
b) the status of the new member from CTR=DE to EoS
5
Source
fter the reception of the new member with CTR=EoS Sink will
start the demapping process with the next container!
7
Sink
Source starts to map payIoad information in the next
upcoming container
6
Source
SState tate
D Diagramm iagramm
CS - ITU-T STTE DIRM
NMS CS Sk
Sk Sk
CTR=DD
CTR=DD
CTR=NORM
CTR=EOS
CTR=NORM CTR=EOS
MST=OK
MST=OK
mem
a
(new)
mem
a +1
(new) mem
n-1
(EOS) Note 1
Note 2
Note 3
Note 4
Note 5
Note 6
Note 7
dd cmnd
connectivity
check
connectivity
check
ink ink
FFaiIure aiIure
Sink detects an faiure of one member
Sink changes the mem-er status oI this mem-er to IL
On detection oI this new mem-er status Source will set CTRL Irom
NORM or EoS to DNU (Do not use)
Sink does not demap the payload anymore.
TEMPORR FIURE
Sink detects the cearance of the faiure status
Sink sets the mem-er status oI this mem-er to OK
On detection oI this new mem-er status Source will set CTRL to NORM or
EOS again
Sink will now demap the payload anymore.
INK CPCIT DJUSTMENT SCHEME
CS
ENEFITS
FIexibIe &
scaIabIe
Offers variable VC
bandwidth in real-
time!
Cost Efficient
New NE necessary
only at the edge
Transparent to core
network
EnabIes VaIue
added services
Bandwidth on demand
Soft Protection
99.999% up-time
Restoration
Virtual Concatenation
link protection &
recovery
eneric eneric
FFrame rame
PProcedure rocedure
NEW SONET/SDH AT THE
Edge
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
?
That's " New SONET/SDH "
VC
Virtual
Concatenation
LCS
Link
Capacity
Adiustment
Scheme
GP
Generic
Frame
Procedure
LPS
Ethernet
icon
Escon
ibre
Channe
Edge Core
daptation
Customer Operator
SNs
TM

I
C
O
N
E
S
C
O
N
Ethernet
D
V
I
HDLC
rame Reay POS
DT (IP. IPX. MPLS....)
RPR
iber
GP-T

i
b
r
e

C
h
a
n
n
e

SONET/SDH
WDM / OTN
Voice Video
Private
Lines
GP-
GP
THE I PICTURE
FP - ER MODE
GP - Cient Specific spects
(payload dependent)
GP - Common spects
(payload independent)
SONET/SDH
VC-n Path
OTN
ODUk Path
Others
(e.g. ibre)
Ethernet IP/PPP
ibre
Channe
Others Cients
GP
Transport
rame Mapped Transparent Mapped
ESCON
ENERIC FRME PROCEDURE
C.7041 Ceneric Frame Procedure defines
Client encapsulation for transport over SONET/SDH or OTN networks
Frame formats for various clients
Napping Procedures for client signals into CFP
hy 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, OoS
SStructure tructure oof f
FP FP - - FFrames rames
CFP FRANE OvERv!E
Payoad
rea
8 bit
Core Header
FP PayIoad rea transports
higher layer specific information
ength 4 to 65535 byte
CIient PayIoad FieId contains
client frames (GFP-F) or
client characters (GFP-T)
Cient
Payoad
Information
PayIoad Headers gives type of
client and supports client specific
management procedures
ncludes CRC detection &
correction
ength 4 to 64 byte
Payoad
Headers
Core Header contains the length of
the payload area
and start of frame info
and CRC-16 error detection &
correction
ength 4 byte
OptionaI PayIoad FCS protects the
client payload information field
CRC-32 ength 4 byte
Optiona
Payoad CS
FP gets scrambIed before transmission!
CFP PAYLOAD HEADER
Payoad Type ied
is mandatory Ior GFP client Irames (PLI K4)
Provides inIormation a-out
content & format oI the Client Payload
InIormation
indicates different GP frame types
distinguishes -etween diIIerent services in a
multi-service environment
Payoad
Type
Extension
Header
ied
Payoad
rea
Core Header
Cient
Payoad
Information
Payoad
Headers
Optiona
Payoad CS
FP - POD HEDER
PTI - Payoad Type Identifier
3--it Iield, which indicates the type oI GFP
client Irame
Currently deIined
PTI 000 Client Data
PTI 100 Client Management
PTI Others Reserved
PI - Payoad CS Indicator
1--it Iield indicates the
PFI 1 Presence
PFI 0 A-sence
oI the optional payload Frame Check Sequence (pFCS) Iield
EXI - Extension Header Identifier
4--it Iield indicates the Iormat oI the Extension Header Field
Currently deIined
EXI 0000 Null Extension Header
EXI 0001 Linear Frame
EXI 0010 Ring Frame
EXI Others Reserved
Payoad
Type
Extension
Header
ied
PTI
PFI
EXI
UPI
tHEC
tHEC
1
1
1
1
1 2 3 4 5 6 7 8
CFP Payload Header
UPI - User Payoad Identifier
8--it Iield identiIies the type oI client/service
encapsulated in the GFP Client Payload Field
Interpretation oI UPI values is diIIerent Ior
Client data Irames (PTI000) or
Client management Irames (PTI100)
More details on the next slides
tHEC - Type Header Error Contro
16--it error control code
to correct one -it error or
to detect multiple -it errors in the payload type Iield
Payoad
Type
Extension
Header
ied
PTI
PFI
EXI
UPI
tHEC
tHEC
1
1
1
1
1 2 3 4 5 6 7 8
FP FP - -
OOperation peration
M Modes odes
FP OPERTION MODES
GP IDLE rame:
Rate daptation (~stuffing)
GP Management rame:
under study
GP-T (Transparent Mapped):
Client characters are directly mapped in GFP-T Irames e.g. Fi-re Channel
Fixed length GFP Irames
Minima Latency
00
GP- (ramed Mapped):
For packet oriented clients, e.g. Ethernet
One Client Packet packed in one GFP Irame (1:1)
Minima overhead
CFP OPERAT!ON NODES
FP-T
1igE IDLE LE Eth Eth. rame IDLE Ethernet rame
FP-F
rame by rame
GP Ethernet rame GP GP GP Eth GP GPEth. rame
Transparent GP Transparent GP Transparent GP GP
GP
FP Header or IDE frames
Bock by Bock
fixed
variabIe
GP
FP FP - - FF
PPayIoad ayIoad
SSpecifics pecifics
ETHERNET MC POD
46 ... 1500 yte
7+1 Byte
PreambIe
4 Byte
CRC
PayIoad
(und ggf. Padding)
6 Byte
Source
ddress
6 Byte
Dest.
ddress
2 Byte
Type /
ength
802.2 C
1Byte
DSP
1Byte
SSP
1Byte
CTR
PayIoad
(und ggf. Padding)
802.2 SNP
3 Byte
OUI
2 Byte
PrID
PayIoad
(und ggf. Padding)
6 Byte
Source
ddress
6 Byte
Dest.
ddress
7+1 Byte
PreambIe
4 Byte
CRC
PayIoad
(und ggf. Padding)
2 Byte
Type /
ength
2 Byte
Type =
8100
2 Byte
Prio, /
VN
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
VN DENTFER
&ser
Priority
CF
03
000000 0800
IP PayIoad
(und ggf. Padding)
FP & ETHERNET MC POD
tHEC
Type
PLI
cHEC
GP Extension
Header
GP
Payoad
2
2
2
2
0-60
s
CIient
ytes
Source ddress
Destination ddress
Preambe
Start of rame Deimeter
Length/Type
MC Cient
Pad
rame Check Sequence
ytes
7
1
2
6
6
4
46-
1500
Ethernet MC Frame
FP-F Frame
Source ddress
Destination ddress
Length/Type
MC Cient
Pad
rame Check Sequence
FP & ETHERNET MC POD
tHEC
Type
PLI
cHEC
GFP Extension
Header
GFP
Payload
Source Address
Destination Address
Length/Type
MAC Client
Pad
FCS
E
t
h
e
r
n
e
t
G
F
P

H
e
a
d
e
r
Ethernet !nterPacketCas are deleted
before encapsulation and restored after
transmission
Byte alignment and bit identification is
maintained
ETHERNET TO FP-FRMED
Up to 10M
Ethernet Stream
5M
7.5M
10M
t
1 2 3 4
2.5M
Pure Ethernet
GP Packet
Payoad
Core Header
Constant Stream
Resut
GP- Packet GP-IDLE Packet
00hex
00hex
00hex
00hex
Payoad
cHEC
PLI
2
2

ScrambIing!
FP-FRMED TO VC
GP-ramed
Packet Stream
5M
7.5M
10M
t
1 2 3 4
2.5M
GP Stream
VC-12
#5
VC-12
#4
VC-12
#3
VC-12
#2
VC-12
#1
GP rames
in VC containers
Transport Thru the Network
Transport
Byte-Intereaving
ETHERNET TO CFPF SCHENE
Ethernet Control
Character Termination,
e.g.
Ethernet Switch
or ridge
MC to FP-F
EncapsuIation
MC Frame
Extraction
FP-F stream mapped
to VC container
ControI
Termination
VC-n or
VC-n-v
Ethernet
Fast Ethernet
GigEthernet
10Gig Ethernet
PH-x
Ethernet Decode/
CIock Recovery
ERROR HNDIN
CFP Source process detects client errors before
transmission
Client packets should be discarded by the CFP process
No transmission of errored packets
CFP Source process detects client errors while in
transmission
Padded up with all ones bit sequences
Complement all payload FCS (if present) and transmit
Result: CFP Sink process will discard errored packets
Or Client Process will discard errored packets
ENERIC FRME PROCEDURE
FP
ENEFITS
ReIiabIe
Easy & stabile
algorithm
Header Correction
New
Opportunities
Technological &
Economical
ExpandabIe
with no need for
new transport
equipment
CompatibIe
works with basically
any higher layer
service and lower
layer network!