29422920 overview-of-ng-sdh

1 Fujitsu and Fujitsu Customer Use OnlyNG-SDH Overview
Overview of NG-SDH

Agenda
 Network status today and future
 Virtual Concatenation (VC)
 Link Capacity Adjustment Scheme (LCAS)
 Generic Frame Procedure (GFP)
 Testing tasks
 ITU-T standardization
 Instrument presentation

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/WAN’s and well known at all enterprises worldwide!
 Data traffic is still growing, but only at a slower speed than
expected
 All network topologies focusing on an IP/Ethernet ONLY
approach are shifted to long-term future.
 The future today:
 Bring SONET/SDH and Ethernet together!

Storage Area Network
(SAN)
New Customer Applications
Virtual Private Network
(VPN)
Edge Network
Core Network
Storage Server
LAN
LAN
PC
Server
SONET/SDH
Ethernet
Fibre Channel
GFP-F
GFP-T

Mass market Carrier Class market
Asynchronous Synchronous
Dynamic Bandwidth Fixed Bandwidth
Connection less Connection oriented
Best Effort Service High Quality of Service
Ethernet vs. SONET/SDH
Ethernet SONET / SDH
How to solve all these challenges?

Worldwide Optical Network Equipment Market
0.0
2,000.0
4,000.0
6,000.0
8,000.0
10,000.0
12,000.0
14,000.0
16,000.0
18,000.0
1999 2000 2001 2002 2003 2004 2005 2006
Year
MillionsofU.S.Dollars
NewGen
Traditional SDH/SONET
Source: Gartner

New
SDH / SONET
Overview

Going into Details
Campus A
Ethernet
Optical Core
Network
Remote
Servers
Storage
Servers
Fibre
Channel
SONET/SDH
DWDM
SONET/
SDH
SONET/
SDH
SONET/
SDH
Campus B
Ethernet
FICON
Let‘s zoom in!
Core NE
Edge NE

SONET/
SDH/
OTN
SONETMUX/DEMUX
NativeInterfaces
New SONET/SDH at the Edge
?
That’s “NG-SDH “
VC
Virtual
Concatenation
LCAS
Link
Capacity
Adjustment
Scheme
GFP
Generic
Frame
Procedure
LAPS
Ethernet
Ficon
Escon
Fibre
Channel
Edge CoreAdaptation
Customer Operator

Customer needs Ethernet
Typical
Ethernet Traffic
Connections
100
25
50
75
Mbit/s
time
1 2 3 4
Ethernet Packet
Problem: How can we efficiently transport Ethernet over an
existing SONET/SDH network?
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 3 = 100M
Customer 2 = 60M
Customer 1 = 10M

SDH Line Rates
10 M
Transport
10M Ethernet over SDH?
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 ConcatenationContiguous
Concatenation
only large 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 Payload Sizes
Standard
Containers
are inefficient!
Can’t 5 x VC-12 be concatenated?
?5x

Concatenation -
Contiguous or
Virtual ?

AU-4 Pointers
MSOH
RSOH
VC-4-5 VC-4-6 VC-4-7 VC-4-8
VC-4-9 VC-4-10 VC-4-11 VC-4-12
VC-4-13 VC-4-14 VC-4-15 VC-4-16
VC-4-1 VC-4-2 VC-4-3 VC-4-4
STM-16
Contiguous
Concatenation
VC-4-4c
AU-4 Pointers
MSOH
RSOH VC-4-1 VC-4-2 VC-4-3 VC-4-4
VC-4-5 VC-4-6 VC-4-7 VC-4-8
VC-4-9 VC-4-10 VC-4-11 VC-4-12
VC-4-13 VC-4-14 VC-4-15 VC-4-16
The block has to start at defined positions in the payload
The block consists of consecutive VC-4-ns
There is only one pointer
STM-16
Virtual
Concatenation
VC-4-7v
AU-4 Pointers
MSOH
RSOH
VC-4-5 VC-4-6 VC-4-7 VC-4-8
VC-4-9 VC-4-10 VC-4-11 VC-4-12
VC-4-13 VC-4-14 VC-4-15 VC-4-16
VC-4-1 VC-4-2 VC-4-3 VC-4-4
Pointers
MSOH
RSOH VC-4-1 VC-4-2 VC-4-3 VC-4-4
VC-4-5 VC-4-6 VC-4-7 VC-4-8
VC-4-9 VC-4-10 VC-4-11 VC-4-12
VC-4-13 VC-4-14 VC-4-15 VC-4-16
The blocks can start at any position in the payload
The block consists of distributed VC-ns
Each container has it‘s own pointer

VC Nomenclature
VC-n
Virtual Container n
n=4, 3, 2, 12, 11
Defines the type of virtual
containers, which will be
virtually concatenated.
-X
Number of
virtually
concatenated
containers
All X Virtual Containers
form together the
“Virtual Concatenated
Group” (VCG)
v
Indictor for
Virtual
Concatenation
v = virtual concat..
c = contiguous concat..
Virtual Concatenated Group (VCG) of X VC-n containers!

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-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 granularity

SDH - Virtual Concatenation
C-12-5v
C-12-12v
C-12-46v
C-3-2v
C-3-4v
C-3-8v
C-4-6v
C-4-7v
SDH
92%
98%
100%
100%
100%
100%
89%
95%
C-4-64v 100%
Ethernet
ATM
ESCON
Fibre Channel
Fast Ethernet
Gigabit Ethernet
data
10 Mbit/s
25 Mbit/s
200 Mbit/s
400 Mbit/s
800 Mbit/s
100 Mbit/s
1 Gbit/s
10 Gb Ethernet 10 Gbit/s
efficiency
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!

Virtual
Concatenation
+
Differential
Delay

Virtual Concatenated Groups
Answer:
The containers do not know it!
That’s 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?
Answer:
They must all start at one port!
And they must all end at one port!
A
B
A
B
A A

VC-4
VC-4
VC-4
VC-4
Virtual Container Indicator
Problem:
How to distinguish between VCG members of one group?
SQ=0
SQ=1
SQ=2
SQ=3
Solution:
Give each member an individual “number plate”!
 Sequence Indicator (SQ)
Result: VCG members can now be distinguished and sorted!

Time Stamp Mechanism
VC-4
VC-4
VC-4
VC-4
SQ=0
SQ=1
SQ=2
SQ=3
Problem:
How do we know that members arriving together started together?
Solution:
Give each VCG an individual number
 Frame Counter (FC)
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

Transporting Concatenated Signals
VC-4-2v
Virtual Concatenation
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
Contiguous Concatenation
VC-4-4c
C-4 C-4
C-4 C-4
C-4 C-4
C-4 C-4
NENE
One Path
C-4 C-4
C-4 C-4
Core Network

Storage
DemappingArrival
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
Way 1
Way 2
Way 3 - delayed
Way 4
VCG Reassembly

VC
Framing

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
F2
H4
F3
K3
B3
C2
G1
J1
N1
VC-3 / VC-4
out of
VC-3-Xv / VC-4-Xv
J2
N2
K4
V5 VC-2 / VC-11/VC-12
out of
VC-2-Xv / VC-11-Xv /VC-12-Xv

High Order VC - H4 byte - non LCAS
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
MFI1 MFI2
n
H4 Byte Multi-Frame
Bit 1 - 4 Bit 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 000
0 100
0 010
0 110
0 001
0 101
0 011
0 111
1 000
1 100
1 010
1 110
1 001
1 101
1 011
1 111
MFI2 (bit 1-4)
MFI2 (bit 5-8)
8 bit
SQ (bit 1-4)
SQ (bit 5-8)
8 bit
Time for transmitting ONE multi-frame: 16 byte x 125µs = 2ms

Higher Order Path H4: MFI1 / MFI2
MFI2 (8)
0
1
2
The complete
multiframe has
MFI1=16 * MFI2=256
= 4096 steps.
Target for delay
compensation of 512ms
0
1
2
4095
255
0
1
15
MFI1 (4)
0
1
15
0

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
Counts from 0 to 255
High Order VC Frame Counter:
MFI1 x MFI2 = 16 x 256 = 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
High Order VC - H4 byte

K4 byte (VC-2, 11, 12)
bit 1:Extended Signal label - 32 frame multi-frame
bit 2: Low order Virtual concatenation
bit 2: 32 frame MF should be in phase with b1 multi-frame
1 72 3 4 5 6 8 9 1210 11 13 1914 15 16 17 18 20 21 2422 23 25 3126 27 28 29 30 32
Reserved
MFAS = Multiframe
alignment bits
0111 1111 110
Extended Signal
Label
0
1 72 3 4 5 6 8 9 1210 11 13 1914 15 16 17 18 20 21 2422 23 25 3126 27 28 29 30 32
Reserved = 0
Frame
Count (FC)
Sequence
Indicator (SQ)
Low Order VC - K4 byte
Time for transmitting ONE multi-frame:
Length of MF x Frame Repetition Rate
32 bit x 500µs = 16ms

Low Order VC Frame Counter:
FC x Length of Multi-Frame x Frame Repetition Rate
Max. tolerable Differential Delay = 32 x 32 x 500µs = 512ms
FC - Multi Frame Indicator
5 bits - Counter incremented with each 32 bit multi-frame
Counts from 0 to 31
Low Order VC - K4 byte
SQ - Sequence Indicator
6 bits - Transmitted once every 32 bit multi-frame
Max. number of Low Order VCG members = 64

Virtual Concatenation - Benefits
VC
BENEFITS
Economical
Re-use core
network equipment
 invest only at the
edge
Well-known
SONET/SDH is well
engineered & reliable
& trained
Efficient &
Scalable
Fine granularity &
multi-path capability
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 #1VC-3 #2
VC-3 #?
VC-4 #1VC-4 #3
FAILED
 How can we ensure QoS for data services?
  VCG - Protection one VC container fails - the whole Virtual
Concatenation Group (VCG) fails!

Link
Capacity
Adjustment
Scheme

Los Angeles
Seattle
Dallas
Washington
Chicago
San Francisco
San Jose
Houston Orlando
Atlanta
New York
Boston
Kansas City
Denver
Columbus
Los Angeles
Seattle
Dallas
Washington
Chicago
San Francisco
San Jose
Houston Orlando
Atlanta
New York
Boston
Kansas City
Denver
Columbus
Location A
Location B
Bandwidth Provisioning - today
 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 2nd path
 using the network management system
 100M = VC-3-2v / STS-1-2v

Los Angeles
Seattle
Dallas
Washington
Chicago
San Francisco
San Jose
Houston Orlando
Atlanta
New York
Boston
Kansas City
Denver
Columbus
Los Angeles
Seattle
Dallas
Washington
Chicago
San Francisco
San Jose
Houston Orlando
Atlanta
New York
Boston
Kansas City
Denver
Columbus
LCAS - Add Bandwidth hitless
 Operator manually provisions additional 50M path
Location A
Location B
 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!
NE
NE
 LCAS Succeeds  A connection with 100M is in service!

Generalized
Control
Packet

VC & LCAS Control Packet
Frame
Counter
MFI
VCG
Sequence
Indicator
SQ
Virtual
Concatenation
Information
LCAS
Error
Protection
CRC
LCAS
Member
Status
MST
LCAS
Control
Commands
CTRL
LCAS
Source
Identifier
GID
LCAS
Resequence
Acknow-
ledgement
RS-Ack
LCAS Information
Information Packets exchanged between the two
edge network elements to adjust the bandwidth.

Control Packet - MFI
CRCMSTMFI 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”
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
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 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
Sink SourceVCG
Member 0
Member 1

VCG Link
EOS
IDLE
ADD
NORM
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
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
 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

 DNU (1111) - Do Not Use
 The payload of this container can’t 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
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.

Control Packet - GID
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 215-1
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
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
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 - 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.
CRC - Cyclic Redundany Check
 the content of a control packet is protected by a CRC
 if errors are detected the control packet is rejected

Control
Packet
Transport
High & Low Order

Where are the LCAS bytes?
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
• 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

Low Order Control Packet
CRC
-3
Member Status
Sequence
Indicator
CTRL
G
I
D
Spare
R
S
-
A
C
K
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.
Frame
Count
1
K4
b2Filter
32x
2
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
Information
LCAS Information

High Order LCAS - H4 byte
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
MFI1 MFI2
n
H4 Byte Multi-Frame
Bit 1 - 4 Bit 5 - 8
MFI1 (bit 1-4)
0 000
0 100
0 010
0 110
0 001
0 101
0 011
0 111
1 000
1 100
1 010
1 110
1 001
1 101
1 011
1 111
MFI2 (bit 1-4)
MFI2 (bit 5-8)
8 bit
SQ (bit 1-4)
SQ (bit 5-8)
8 bit
Time for transmitting ONE multi-frame: 16 byte x 125µs = 2ms
Reserved “0000”
Reserved “0000”
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
GID “000x”1 bit
CTRL4 bit

“ADD” Explained
Request from NMS to increase bandwidth on a existing link.1Source
Actions for the currently unequipped container:
a) assign a valid sequence indicator (SQ=currently highest +1)
b) change CTRL=ADD (from CTRL=IDLE)
2Source
Sink replies with MST=OK after detection of the new member3Sink
Sink acknowledges the new status with the beginning of the next
multi-frame (RS-Ack toggles)4Sink
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
5Source
After the reception of the new member with CTRL=EoS Sink will
start the demapping process with the next container!7Sink
Source starts to map payload (traffic) information in the next
upcoming container6Source

LCAS - ITU-T State Diagram
NMS LCAS Sk Sk Sk
CTRL=ADD
CTRL=ADD
CTRL=NORM CTRL=EOS
CTRL=NORM CTRL=EOS
MST=OK
MST=OK
mema(new) mema +1(new)memn-1(EOS)Note 1
Note 2
Note 3
Note 4
Note 5
Note 6
Note 7
Add cmnd
connectivity
check
connectivity
check

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
 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
Auto Recovery of VC links possible

LCAS
summary

Information sent in
control packet x
of container n
in VCG A
Information sent in
control packet y
of container p
in VCG B
Information Flow Chart
Information for status of
container p of VCG B
Information for status of
container n of VCG A
MFI_A
SQ(n)
CTRL(n)
CRC_x
GID_A
MST_A(n)
RS-Ack_A
MST_B(n)
RS-Ack_B
MFI_B
SQ(p)
CTRL(p)
CRC_y
GID_B
Link of VCG B
Link of VCG A
NE A NE B

Control Packet OverviewInformation
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
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 OverviewInformation
Direction
Source  Sink
GID
Group Identification Bit is
• an additional verification mechanism to secure that all
incoming VCG members belong to one group
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
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
*VCG = Virtual Concatenated Group

Link Capacity Adjustment Scheme
LCAS
BENEFITS
Flexible &
scalable
Offers variable VC
bandwidth in real-
time!
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
Restoration
link protection &
recovery

Challenges ahead
 Rate adaptation between asynchronous clients and
synchronous transport network
Asynchronous
Rates
Synchronous
Rates
 Efficient & suited mappings for all diverse data clients!
 “...one mapping fits all...?!?”
SONET/SDH

Generic
Frame
Procedure

SONET/
SDH
SONETMUX/DEMUX
NativeInterfaces
New SONET/SDH at the Edge
?
That’s “ New SONET/SDH “
VC
Virtual
Concatenation
LCAS
Link
Capacity
Adjustment
Scheme
GFP
Generic
Frame
Procedure
LAPS
Ethernet
Ficon
Escon
Fibre
Channel
Edge CoreAdaptation
Customer Operator

GFP - Layer Model
GFP - Client Specific Aspects
(payload dependent)
GFP - Common Aspects
(payload independent)
SONET/SDH
VC-n Path
OTN
ODUk Path
Others
(e.g. Fibre)
Ethernet IP/PPP
Fibre
Channel
OthersClients
GFP
Transport
Frame Mapped Transparent Mapped
ESCON

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 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

Structure of
GFP - Frames

Payload
Area
8 bit
Core Header
GFP Payload Area transports
higher layer specific
information
 Length 4 to 65535 byte
GFP Frame Overview
Client Payload Field
contains
client frames (GFP-F) or
client characters (GFP-T)
Client
Payload
Information
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
Optional Payload FCS
protects the client payload
information field
 CRC-32 Length 4 byte
Optional
Payload FCS
GFP gets scrambled before transmission!

GFP - Common Aspects
Payload
Area
Core Header
8 bit
PLI
PLI
cHEC
cHEC
Client
Payload
Information
Payload
Headers
Optional
Payload FCS
4 byte
4 to 65535 byte
8 bit
X=4-64 byte
0 to
65535-X byte
4 byte
4 byte

GFP - Core Header
Payload
Area
Core Header
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
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

GFP -Control Frames
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 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:

GFP - Payload Header
Payload Type Field
Provides information about
 content & format of the Client Payload Information
 indicates different GFP frame types
 distinguishes between different services in a multi-
service environment
Payload
Area
Core Header
Client
Payload
Information
Payload
Headers
Optional
Payload FCS
Payload
Type
Extension
Header
Field
Extension Header Field
 supports technology specific data link headers,
e.g.
 virtual link identifier
 source/destination address
 Class of Service
 Three Extension Header Variants are currently
defined for point-to-point or ring configurations

GFP - Payload Header
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
 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
Payload
Type
Extension
Header
Field
PTI PFI EXI
UPI
tHEC
tHEC
1
1
1
1
1 2 3 4 5 6 7 8
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
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

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)
 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
Core Header
Client
Payload
Information
Payload
Headers
Optional
Payload FCS
Payload
Type
Extension
Header
Field

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
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
CID
Spare
1
1
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
Spare
 8-bit field for future use
Extension Header for ring frame  for further study

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
Linear Extension
Header
1..256
signals
GFP
Mux
GFP Streams
with different clients
IDLE
Insertion
CID=0CID=2 CID=1CID=1
CID=0 CID=0
CID=0
CID=1CID=1 CID=1
CID=2 CID=2
CID=2

CID
Spare
eHEC
eHEC
PTI PFI EXI
UPI
tHEC
tHEC
GFP - Frames Overview
Payload
Area
Core Header
8 bit
PLI
PLI
cHEC
cHEC
Client
Payload
Information
Payload
Headers
Optional
Payload FCS
Payload
Type
Extension
Header
Field
4
4 - 65535

GFP -
Operation
Modes

GFP IDLE Frame:
 Rate Adaptation (“stuffing”)
GFP Management Frame:
 under study
GFP Operation Modes
GFP-T (Transparent Mapped):
 Client characters are directly mapped in GFP-T
frames e.g. Fibre Channel
 Fixed length GFP frames
 Minimal Latency
00
GFP-F (Framed Mapped):
 For packet oriented clients, e.g. Ethernet
 One Client Packet = packed in one GFP frame (1:1)
 Minimal overhead

GFP Operation Modes
GFP-T
1GigE IDLELE EthEth. Frame IDLEEthernet Frame
GFP-F
Frame by Frame
GFPEthernet FrameGFP GFP GFP EthGFPGFPEth. Frame
TransparentGFP TransparentGFP TransparentGFP GFP
GFP GFP Header or IDLE frames
Block by Block
fixed
variable
GFP

GFP-F Client vs. Transport Rate
Variable Client Rate
GFP-F
t
Mbit/s
F
I
F
O
IDLEs
GFP-F Mapper
+
M
a
p
p
e
r
Constant Transport Rate
t
Mbit/s
GFP-F IDLEs
Client
Ethernet
Fast Ethernet
Gigabit Ethernet
IP
PPP

GFP-T mapping procedure
1GigE IDLELE EthEth. Frame IDLEEthernet Frame
1. Decoding: 1 GbE GFP
Data Codes Data Bytes (8 Bit)
Control Codes Control Code Indicator (4 Bit)
8B/10B Codewords
2. 64B/65B Block Code
Leading bit
8-byte block
Re-arranging of leading bits to the end

GFP-T mapping procedure
3. CRC-16 calculation
CRC-16
GFP Core header
&
Payload header
Superblocks Superblocks Superblocks* * * *
Optional GFP FCS
4. Superblock formation and GFP OH

GFP-T Client vs. Transport Rate
GFP-T Mapper
M
a
p
p
e
r
Decoder
/ Coder
100+x %
GFP-T
t
Mbit/s
Effective Payload
Constant Client Data Rate
100 %
Client IDLEs
Fibre Channel
ESCON
FICON
Gigabit Ethernet
10 GigE
Anything!
t
Mbit/s
GFP Overhead
Constant Transport Rate
Effective Payload
Client IDLEs

GFP-F
&
GFP-T

GFP-F vs. GFP-T
GFP-F GFP-T
• used for connections where
efficiency and flexibility are key
• 1:1 relation between service
frame/paket and GFP frame
• buffering necessary, this
increases latency
• preferred option for GE and IP
• good for statistical multiplex services
• for applications that are sensitive to
latency or unknown physical layers
• all code words from physical layer
are transported
• primarily targeted at SANs

GFP -
Framing
Procedures

GFP - Frame Delineation
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
PLI
Payload Length Indicator
PayloadGFP
Variable length 4 to 65539 Byte
..... it’s all about synchronisation!

GFP - Frame Delineation
01001111110010010100101001000101111010010101001010101010010111101
PLI cHECComparer
2 byte 2 byte
CRC-16
1. HUNT State
• Searching for a correct formated
4 byte Core Header
• Byte by Byte search
• Bit Error Correction = disabled
Expected next Core Header
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? - Yes3. Sync State
• Jump to the next frame using PLI
• Single Bit Error Correction = enabled
• Detection of Multiple Bit Errors?

GFP - F
Payload
Specifics

GFP & Ethernet MAC Payload
Source Address
Destination Address
Preamble
Start of Frame Delimeter
Length/Type
MAC Client
Pad
Frame Check Sequence
Bytes
7
1
2
6
6
4
46-
1500
tHEC
Type
PLI
cHEC
GFP Extension
Header
GFP
Payload
2
2
2
2
0-60
As
Client
Bytes
Ethernet MAC Frame GFP-F Frame
Source Address
Destination Address
Length/Type
MAC Client
Pad
 Ethernet Inter-Packet-Gaps are deleted before
encapsulation and restored after transmission
 Byte alignment and bit identification is maintained

IP & PPP Payload
Flag
Control
Address
PPP Type
PPP Information
Pad
Bytes
1
2
1
1
4
tHEC
Type
PLI
cHEC
GFP Extension
Header
GFP
Payload
2
2
2
2
0-60
As
Client
Bytes
PPP/HDLC Frame GFP-F Frame
Control
Address
PPP Type
PPP Information
Pad

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
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
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
Byte-Interleaving

Generic Frame Procedure
GFP
BENEFITS
Reliable
Easy & stabile
algorithm
Header Correction
New
Opportunities
Technological &
Economical
Expandable
with no need for
new transport
equipment
Compatible
works with basically
any higher layer
service and lower
layer network!

Other
Encapsulation
Methods

HDLC, LAPS & GFP frame
Flag
(1byte)
Address.
(1 byte)
Control.
(1 byte)
CRC
(4 byte)
Payload
HDLC
Flag
(1byte)
Flag
(1byte)
Address.
(1 byte)
Control.
(1 byte)
SAPI
(1 byte)
CRC
(4 byte)
Payload
LAPS
Flag
(1byte)
SAPI
(1 byte)
Core Header
(4byte)
Payload
Header
(4 – 64 byte)
Client
payload
Optional
Payload FCS
(4 bye)
GFP - frame

HDLC, LAPS & GFP frame
HDLC LAPS GFP
Advantages  variable frame
length, depending
on payload length
variable frame
length,
depending on
payload length
 flexible for a large
number of services
 simple and stable
synchronization
 variable frame length
 additional service features
e.g. multiplexing
Disadvantages  only Ethernet
and IP payload
 unstable
synchronization
 only Ethernet
and IP payload
 unstable
synchronization
 fairly large OH

GFP vs. LAPS
• GFP is more efficient thatn LAPS
 constant overhead for any payload
 allows easier traffic management and QoS control
• GFP is more robost than LAPS
 single bit errors in the PLI & the cHEC does
not cause loss of alignment
 in LAPS a single bit error causes misalingment
• GFP minimizes system bandwidth requirements
 allows multiple protocols to be transported via the
same transport path
Allows multiplexing of several types of protocols
on a frame by frame basis
• GFP supports RPR operation and is more suitable for packet traffic
 new SONET/SDH functionalities like VC,
LCAS work more efficiently with GFP

The Evolution

“New SONET/SDH” - the evolution of SONET/SDH
Ethernet
Ficon
Escon
Fibre
Channel
SONET/
SDH
MUX/DMUX
NativeInterfaces
?GFP
Generic
Frame
Procedure
LCAS
Link
Capacity
Adjustment
Scheme
VC
Virtual
Concatination
 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 :
 SONET/SDH is flexible & data aware!

Standards

Standardisation (I)
ITU-T
• G.707/Y.1322 Network Node Interface for SDH
 standardisation of Virtual Concatenation for high-order
and low-order
 definition of the H4 (for high-order path) and the K4 byte
(for low order path) structure
• G.7041/Y.1303 Generic Frame Procedure
 standardisation of rate adaptation mechanism for different protocols e.g.
Ethernet, Fibre Channel, IP, etc.
 standardisation of two GFP modes e.g. transparent and frame-mapped GFP
• G.7042/Y.1305 LCAS for Virtually Concatenated Signals
• standardisation of dynamic bandwidth adaptation
• Definition of hitless adding/removing of Virtual Containers

Standardisation (II)
• X.86 Ethernet over LAPS
 describes the Ethernet mapping into SDH frames
 analogy to HDLC/PPP framing
• X.85 IP over SDH using LAPS
 describes the IP mapping into SDH frames
 analogy to HDLC/PPP framing
IEEE
• Ethernet: 802.x
 standardisation of various Ethernet types
 definition of interface specifications

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
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
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 SDH/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

29422920 overview-of-ng-sdh

29422920 overview-of-ng-sdh

Recommandé

Contenu connexe

Tendances

Tendances(20)

Similaire à 29422920 overview-of-ng-sdh

Similaire à 29422920 overview-of-ng-sdh(20)

Plus de bui thequan

Plus de bui thequan(16)

Dernier

Dernier(20)

29422920 overview-of-ng-sdh