Overview of NG-SDH

Overview of NG-SDH
1
NG-SDH Overview Fujitsu and Fujitsu Customer Use Only
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
2
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!
3
New Customer Applications
Virtual Private Network

LAN (VPN) GFP-F
LAN
PC
Ethernet Server
Core Network
SONET/SDH
Fibre Channel GFP-T

Edge Network
Storage Area Network Storage Server

(SAN)
4
Ethernet vs. SONET/SDH
Ethernet SONET / SDH
Mass market Carrier Class market
Asynchronous Synchronous
Dynamic Bandwidth Fixed Bandwidth
Connection less Connection oriented
Best Effort Service High Quality of Service
How to solve all these challenges?
5
Worldwide Optical Network Equipment Market
18,000.0
16,000.0
14,000.0
12,000.0
Millions of U.S. Dollars
10,000.0
NewGen
Traditional SDH/SONET
8,000.0
6,000.0
4,000.0
2,000.0
0.0
1999 2000 2001 2002 2003 2004 2005 2006
Year Source: Gartner
6
New
SDH / SONET
Overview
AS et
LC er n
Eth
GFP
LA
PS VC
7
Going into Details
Campus B
Ethernet
FICON
Ethernet
SONET/
Campus A
SONET/ SDH
SDH
Optical Core
SONET/ Storage
Network
SONET/SDH SDH
Servers
DWDM
Fibre Remote
Servers
Edge NE Channel
Core NE
Let‘s zoom in!
8
New SONET/SDH at the Edge
Customer Operator
Edge Adaptation Core
SONET MUX/DEMUX
Ethernet
GFP VC LCAS
?
Native Interfaces
Ficon
Generic Virtual Link SONET/
Frame Concatenation Capacity SDH/
Escon Procedure Adjustment OTN
Scheme
Fibre LAPS
Channel
That’s “NG-SDH “
9
Customer needs Ethernet
Problem: How can we efficiently transport Ethernet over

an existing SONET/SDH network?
Mbit/s
Customer 3 = 100M
100
Typical
75 Ethernet Traffic
Customer 2 = 60M
50 Connections
Ethernet Packet
25
Customer 1 = 10M
time
1 2 3 4
Example: For 10M available SDH - Containers are...
VC-12 ...too small ! VC-3 ... inefficient

OR 20%
2.176 Mbit/s 48.38 Mbit/s
10
SDH Line Rates
Transport
10M Ethernet over SDH? SDH Payload Sizes
10 M C-11 1.600 Mbit/s
5x C-12
C-2
2.176 Mbit/s
6.784 Mbit/s
?
Standard
Containers C-3 48.384 Mbit/s
are inefficient! C-4 149.760 Mbit/s
Can’t 5 x VC-12 be concatenated?

Contiguous Contiguous Concatenation
Concatenation C-4-4c 0.599 Gbit/s
only large containers!
C-4-16c 2.396 Gbit/s
C-4-64c 9.584 Gbit/s
C-4-256c 38.338 Gbit/s
11
Concatenation -
Contiguous or
Virtual ?
12
STM-16 VC-4-1 VC-4-2
RSOH VC-4-3 VC-4-4
Contiguous AU-4 Pointers VC-4-5 VC-4-6 VC-4-7 VC-4-8
Concatenation VC-4-9 VC-4-10 VC-4-11 VC-4-12
VC-4-4c MSOH
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 VC-4-1 VC-4-2 VC-4-3 VC-4-4
RSOH
Virtual AU-4 Pointers

Pointers VC-4-5 VC-4-6 VC-4-7 VC-4-8
Concatenation VC-4-9 VC-4-10 VC-4-11 VC-4-12

VC-4-7v MSOH 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
13
VC Nomenclature
VC-n -X v
Virtual Container n Number of Indictor for
n=4, 3, 2, 12, 11 virtually Virtual
concatenated Concatenation
Defines the type of virtual
containers, which will be
containers
virtually concatenated. All X Virtual Containers v = virtual concat..
form together the c = contiguous concat..
“Virtual Concatenated
Group” (VCG)
Virtual Concatenated Group (VCG) of X VC-n containers!
14
VC Granularity and max. Capacity
Nomenclature Granularity Max. Capacity
VC-4 VC-4 –n v 149 M - 38.3G
VC-3 VC-3 –n v 48 M - 12.7 G
VC-2
VC-2 –n v 6.8 M - 434 M
VC-12
VC-12 –n v 2.2 M - 139 M
VC-11 VC-11 –n v 1.6M - 102 M
Maximum Concatenation: = 256 containers

Max. Capacity: = 256 x granularity
15
SDH - Virtual Concatenation
data SDH efficiency

Ethernet 10 Mbit/s C-12-5v 92%
ATM 25 Mbit/s C-12-12v 98%
C-12-46v 100%
Fast Ethernet 100 Mbit/s
C-3-2v 100%
ESCON 200 Mbit/s C-3-4v 100%
400 Mbit/s C-3-8v 100%
Fibre Channel
800 Mbit/s C-4-6v 89%
Gigabit Ethernet 1 Gbit/s C-4-7v 95%
10 Gb Ethernet 10 Gbit/s C-4-64v 100%
Example:
100M Ethernet VC-12-46v
STM-1
8x E1 Services = 64 x VC-12
VC-12-5v
2x 10M Ethernet VC-12-5v
More services integrated- by using VC!

16
Virtual
Concatenation
+
Differential
Delay
17
Virtual Concatenated Groups
Question:
How does a container know that it belongs to a VCG?
Answer:
The containers do not know it!
That’s the job of the network management!
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 A
B B
18
Virtual Container Indicator
Problem:
How to distinguish between VCG members of one group?
Solution:
Give each member an individual “number plate”!
 Sequence Indicator (SQ)
VC-4 SQ=0
VC-4 SQ=1
VC-4 SQ=2
VC-4 SQ=3
Result: VCG members can now be distinguished and sorted!

19
Time Stamp Mechanism
Problem:
How do we know that members arriving together started together?
Solution:
Give each VCG an individual number
 Frame Counter (FC)
VC-4 SQ=0
SQ=0 SQ=0 SQ=0 SQ=0
VC-4 SQ=1
SQ=1 SQ=1 SQ=1 SQ=1
VC-4 SQ=2
SQ=2 SQ=2 SQ=2 SQ=2
VC-4 SQ=3
SQ=3 SQ=3 SQ=3 SQ=3
FC = 3
0
1
2 FC = 2
0
1 FC = 1
0 FC = 0
20
Transporting Concatenated Signals
Contiguous Concatenation
C-4 C-4
C-4 C-4
C-4 C-4 C-4 C-4
C-4 C-4 One Path C-4 C-4

NE NE
Core Network VC-4-4c
Virtual Concatenation
VC-4
Path 1 #1
Differential Delay
VC-4 VC-4 VC-4
#1 #1 #1
VC-4 VC-4
VC-4 #2
#2 #2
VC-4 VC-4-2v
Path 2 #2
21
VCG Reassembly
Way 1 Arrival Demapping

Storage
Way 2 SQ = 0 SQ = 0 SQ = 0
FC = 3
0
1
2 FC
FC= =max
0
1
2 FC
FC= =max
0
1
SQ = 1 SQ = 1 SQ = 1
FC = 3
0
1
2 FC
FC= =max
0
1
2 FC
FC= =max
0
1
Way 3 - delayed SQ = 2 SQ = 2 SQ = 2
FC
FC= =max
0
1
2 FC
FC= =max
0
1 FC
FC= =max
0
1
SQ = 3 SQ = 3 SQ = 3
FC = 30
1
2 FC
FC= =max
0
1
2 FC
FC= =max
0
1
Way 4
22
NG-SDH Overview Fujitsu and Fujitsu Customer Use Only Stop
VC
Framing
23
Where are the VC bytes?
High Order VC Low Order VC

• Information in H4 Byte
•Carried in one bit in K4-Byte
• 16 frame Multi-Frame
• 32 frame Multi-Frame
J1 V5 VC-2 / VC-11/VC-12
B3 VC-3 / VC-4
J2 out of
out of VC-2-Xv / VC-11-Xv /VC-12-Xv
C2 VC-3-Xv / VC-4-Xv N2
G1 K4
F2
H4
F3
K3
N1
24
High Order VC - H4 byte - non LCAS
H4 Byte Multi-Frame
Bit 1 - 4 Bit 5 - 8
MFI1 (bit 1-4) MFI1 MFI2
MFI2 (bit 1-4) 0 0 0 0 0
8 bit
MFI2 (bit 5-8) 0 0 0 1 1
Reserved “0000” 0 0 1 0 2
Reserved “0000” 0 0 1 1 3
Reserved “0000” 0 1 0 0 4
Reserved “0000” 0 1 0 1 5
Reserved “0000” 0 1 1 0 6
Reserved “0000” 0 1 1 1 7
n
Reserved “0000” 1 0 0 0 8
Reserved “0000” 1 0 0 1 9
Reserved “0000” 1 0 1 0 10
Reserved “0000” 1 0 1 1 11
Reserved “0000” 1 1 0 0 12
Reserved “0000” 1 1 0 1 13
SQ (bit 1-4) 1 1 1 0 14
8 bit
SQ (bit 5-8) 1 1 1 1 15
Time for transmitting ONE multi-frame: 16 byte x 125µs = 2ms

25
Higher Order Path H4: MFI1 / MFI2
MFI1 (4) MFI2 (8)

0 0 0
1 1
2
15
0 1
1 4095
15 The complete
0 multiframe has
2
MFI1=16 * MFI2=256
= 4096 steps.
Target for delay
255 compensation of 512ms
26
High Order VC - H4 byte
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
27
Low Order VC - K4 byte
K4 byte (VC-2, 11, 12)
bit 1:Extended Signal label - 32 frame multi-frame

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
MFAS = Multiframe
Extended Signal
alignment bits 0 Reserved
Label
0111 1111 110
bit 2: Low order Virtual concatenation
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Frame Sequence
Reserved = 0
Count (FC) Indicator (SQ)
bit 2: 32 frame MF should be in phase with b1 multi-frame
Time for transmitting ONE multi-frame:

Length of MF x Frame Repetition Rate
32 bit x 500µs = 16ms
28
Low Order VC - K4 byte
FC - Multi Frame Indicator

5 bits - Counter incremented with each 32 bit multi-frame
Counts from 0 to 31
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
SQ - Sequence Indicator
6 bits - Transmitted once every 32 bit multi-frame
Max. number of Low Order VCG members = 64
29
Virtual Concatenation - Benefits
Economical Efficient &

Re-use core Scalable
network equipment Fine granularity &
 invest only at the multi-path capability
edge
VC
BENEFITS
Low
Investment Well-known
deployment only on SONET/SDH is well
customer demand engineered & reliable
 Fast ROI & trained
30
Challenges ahead...
 How can path bandwidth be increased or decreased?

  Dynamic Bandwidth Provisioning
 “..bring an additional truck on the road..”
VC-3 #2 VC-3 #1
VC-3 #?
 How can we ensure QoS for data services?

  VCG - Protection one VC container fails - the whole Virtual
Concatenation Group (VCG) fails!
VC
-4 #
2
VC-4 #3 VC-4 #1
FAILED
31
Link
Capacity
Adjustment
Scheme
32
Bandwidth Provisioning - today
Seattle
Chicago
Boston
Columbus New York
Kansas City Washington

Denver
San Francisco
San Jose
Los Angeles
Atlanta Location B
Dallas
Location A Houston Orlando
 50Mbit/s Ethernet Private Line (VC-3-1v/ STS-1-1v)
 The customer now requires 100Mbit/s

 Operator manually sets up a 2nd path
 using the network management system
 100M = VC-3-2v / STS-1-2v
But: Traffic will be interrupted to bring 100M into service!!
33
LCAS - Add Bandwidth hitless
Seattle
er net Link
M Eth
Chicago
100 NE Boston
Columbus New York
P rotocolCity
Kansas Washington
San Francisco
Denver LCAS
San Jose
NE
Los Angeles
Atlanta Location B
Dallas
Location A Houston Orlando
 Operator installs VC & LCAS edge equipment
 Operator manually provisions additional 50M path
 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!
34
Generalized
Control
Packet
35
VC & LCAS Control Packet
VCG LCAS LCAS LCAS

LCAS LCAS
Frame Sequence Control Source Resequence
Member Error
Counter Indicator Commands Identifier Acknow-
Status Protection
ledgement
MFI SQ CTRL GID RS-Ack MST CRC
Virtual
Concatenation LCAS Information
Information
Information Packets exchanged between the two

edge network elements to adjust the bandwidth.
36
Control Packet - MFI
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
MFI = 0 MFI = 1 MFI = 2 MFI = max MFI = 0 MFI = 1
MFI is necessary for

 realigning virtual concatenated containers of one VCG at the sink
 determing the differential delay between members of the same VCG
37
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)
VCG Sink Source
SQ = 0 SQ = 0 SQ = 0 SQ = 0 SQ = 0
Member 0
MFI = 0 MFI = 1 MFI = 2 MFI = 255 MFI = 0
Member 1 SQ = 1 SQ = 1 SQ = 1 SQ = 1 SQ = 1
SQ is necessary for
 differentiating the members of a virtual concatenated group (VCG)
38
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
Sink EOS Source

NORM
ADD VCG Link
IDLE
CTRL - is used to
 synchronize source and sink LCAS process
 provide LCAS status information about every individual VCG member
39
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
40
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.
 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
 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”
41
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
Member 0 GID = 0 GID = 0 GID = 1 GID = 0 GID = 1

SQ = 0 SQ = 0 SQ = 0 SQ = 0 SQ = 0
Member 1 GID = 0 GID = 0 GID = 1 GID = 0 GID = 1
SQ = 1 SQ = 1 SQ = 1 SQ = 1 SQ = 1
GID - is used to
 verify that all members are coming from the same source
 identify all members of a VCG
42
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
43
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
44
Control
Packet
Transport
High & Low Order
45
Where are the LCAS bytes?
High Order LCAS Low Order LCAS

• LCAS info aligned with VC info • LCAS info aligned with VC info
• Information also in H4 Byte • Carried in one bit in K4-Byte
• 16 frame Multi-Frame • 32 frame Multi-Frame
J1 V5
B3 VC-3 / VC-4 VC-2 / VC-11/VC-12
J2 out of
out of
C2 VC-3-nv / VC-4-nV N2 VC-2-Xv / VC-11-Xv /VC-12-Xv
G1 K4
F2
H4
F3
K3 *CP = Control Packet
N1
46
Low Order Control Packet
Low Order VC & LCAS
How to build a multi-frame control packet?
V5
VC-2 / VC-11/VC-12 • Filter from each K4 byte only bit no. 2
J2 out of • Store bit no. 2
N2 VC-2-Xv / VC-11-Xv /VC-12-Xv • After 32 VCs, one complete VC & LCAS
K4 control packet was received.
32x K4 K4 K4K4 K4K4 K4K4 K4 K4K4K4 K4 K4 K4 K4 K4 K4 K4K4 K4K4 K4K4 K4 K4K4K4 K4 K4 K4K4
Filter b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2 b2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
R
G S
Frame Sequence - CRC
CTRL I Spare Member Status
Count Indicator A -3
D C
K
Virtual Concatenation LCAS Information

Information
47
High Order LCAS - H4 byte
H4 Byte Multi-Frame
Bit 1 - 4 Bit 5 - 8
MFI1 (bit 1-4) MFI1 MFI2
MFI2 (bit 1-4) 0 0 0 0 0
8 bit
MFI2 (bit 5-8) 0 0 0 1 1
4 bit CTRL 0 0 1 0 2
1 bit GID “000x” 0 0 1 1 3
Reserved “0000” 0 1 0 0 4
Reserved “0000” 0 1 0 1 5
CRC-8 0 1 1 0 6
8 bit CRC-8 0 1 1 1 7
n
Member Status (MST) 1 0 0 0 8
8 bit Member Status (MST) 1 0 0 1 9
1 bit RS-Ack “000x” 1 0 1 0 10
Reserved “0000” 1 0 1 1 11
Reserved “0000” 1 1 0 0 12
Reserved “0000” 1 1 0 1 13
SQ (bit 1-4) 1 1 1 0 14
8 bit
SQ (bit 5-8) 1 1 1 1 15
Time for transmitting ONE multi-frame: 16 byte x 125µs = 2ms

48
“ADD” Explained
Source 1 Request from NMS to increase bandwidth on a existing link.
Actions for the currently unequipped container:

Source 2 a) assign a valid sequence indicator (SQ=currently highest +1)
b) change CTRL=ADD (from CTRL=IDLE)
Sink 3 Sink replies with MST=OK after detection of the new member
Sink acknowledges the new status with the beginning of the next
Sink 4 multi-frame (RS-Ack toggles)
With reception of acknowledgement source will change
Source 5 a) the status of the last member from CTRL=EoS to NORM
b) the status of the new member from CTRL=IDLE to EoS
Source starts to map payload (traffic) information in the next

Source 6 upcoming container
After the reception of the new member with CTRL=EoS Sink will
Sink 7 start the demapping process with the next container!
49
LCAS - ITU-T State Diagram
Note 1 memn-1(EOS) mema(new) mema +1(new)

NMS LCAS Sk Sk Sk
Add cmnd
Note 2
Note 3 CTRL=ADD
CTRL=ADD connectivity
check
connectivity
Note 4 MST=OK check
Note 5
CTRL=NORM CTRL=EOS
Note 6 MST=OK
Note 7
CTRL=NORM CTRL=EOS
50
Temporary Failure
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.
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
51
LCAS
summary
52
Information Flow Chart
Information sent in MFI_A

control packet x Information for status of
of container n SQ(n) container n of VCG A
in VCG A CTRL(n) MST_B(n)
GID_A
RS-Ack_B
CRC_x
NE A NE B
Link of VCG A
Link of VCG B
Information sent in MST_A(n) MFI_B

control packet y
of container p RS-Ack_A SQ(p)
in VCG B CTRL(p)
Information for status of
GID_B
container p of VCG B
CRC_y
53
Information Control Packet Overview
Direction
Source  Sink
Multi-Frame Indicator is an counter
MFI
• to distinguish several VCGs* from each other
• necessary to compensate for Differential Delay
Sequence Indicator is an counter

SQ • 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
LCAS Control Words are
CTRL
• 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
54
Control Packet Overview
Information
Direction
Source  Sink
Group Identification Bit is
GID • an additional verification mechanism to secure that all
incoming VCG members belong to one group
Re-sequence acknowledgement is
RS-Ack • an mechanism, where the sink reports to the source the
detection of any additions/removals to/from the VCG
Member Status Field is

MST • an mechanism, where the sink reports to the source which
VCG members are currently and correctly received
Cyclic Redundancy Check is a

CRC
• protection mechanism to detect bit errors in the Control Packet
*VCG = Virtual Concatenated Group
55
Link Capacity Adjustment Scheme
Enables Value Cost Efficient

added services New NE necessary
Bandwidth on demand only at the edge
”Soft” Protection Transparent to
99.999% up-time core network
LCAS
BENEFITS
Flexible &
scalable Restoration
Offers variable VC Virtual Concatenation
bandwidth in real- link protection &
time! recovery
56
Challenges ahead
 Efficient & suited mappings for all diverse data clients!

 “...one mapping fits all...?!?”
SONET/SDH
 Rate adaptation between asynchronous clients and

synchronous transport network
Asynchronous Synchronous
Rates Rates
57
Generic
Frame
Procedure
58
New SONET/SDH at the Edge
Customer Operator
Edge Adaptation Core
SONET MUX/DEMUX
Ethernet
GFP VC LCAS
?
Native Interfaces
Ficon
Generic Virtual Link SONET/
Frame Concatenation Capacity SDH
Escon Procedure Adjustment
Scheme
Fibre LAPS
Channel
That’s “ New SONET/SDH “

59
GFP - Layer Model
Fibre
Clients Ethernet IP/PPP ESCON Others
Channel
GFP - Client Specific Aspects

Frame Mapped (payload dependent) Transparent Mapped
GFP
GFP - Common Aspects
(payload independent)
Transport SONET/SDH OTN Others

VC-n Path ODUk Path (e.g. Fibre)
60
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
61
Structure of
GFP - Frames
62
GFP Frame Overview
Payload Headers gives type
Core Header contains the of client and supports client
length of the payload area specific management
Core Header procedures
 and start of frame info
 and CRC-16 error detection  Includes CRC detection &
& correction Payload correction
 Length 4 byte Headers  Length 4 to 64 byte
Client Payload Field

Client
Payload contains
Payload
Area client frames (GFP-F) or
Information client characters (GFP-T)
GFP Payload Area
transports higher layer
specific information Optional
 Length 4 to 65535 byte Optional Payload FCS
Payload FCS
protects the client payload
information field
8 bit  CRC-32 Length 4 byte
GFP gets scrambled before transmission!

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

 16-bit field contains a binary number,
PLI 1
representing the length of the payload
cHEC 1 area:
Core Header cHEC 1  min.: 4 byte (PLI = 00 04hex)
 max.: 65535 byte (PLI = FF FFhex)
12345678  PLI = 0hex to 3hex reserved for control
frames
Payload cHEC - Core Header Error Control

Area  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
65
GFP -Control Frames
 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:
IDLE Frame GFP IDLE Frames

 The smallest, possible GFP frame with only 4
PLI =00 byte long
PLI= 00  PLI = 00 00hex
cHEC = 00  IDLE frames are necessary
 for rate adaptation process
cHEC = 00  robustness of the frame synchronization
process
66
GFP - Payload Header
Payload Type Field

Provides information about
Core Header  content & format of the Client Payload Information
 indicates different GFP frame types
Payload Payload  distinguishes between different services in a multi-
Headers Type service environment
Payload
Client Extension
Area
Payload Header Extension Header Field
Information Field  supports technology specific data link headers,
e.g.
 virtual link identifier
 source/destination address
Optional  Class of Service
Payload FCS  Three Extension Header Variants are currently
defined for point-to-point or ring configurations
67
GFP - Payload Header
PTI - Payload Type Identifier
123 4 5678  3-bit field, which indicates the type of GFP client frame
PTI PFI EXI 1 Currently defined
 PTI = 000 Client Data
Payload UPI 1  PTI = 100 Client Management
 PTI = Others  Reserved
Type tHEC 1
tHEC 1
PFI - Payload FCS Indicator
Extension  1-bit field indicates the
 PFI = 1  Presence
Header  PFI = 0  Absence
Field  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
UPI - User Payload Identifier

 8-bit field identifies the type of client/service encapsulated in
tHEC - Type Header Error Control the GFP Client Payload Field
 16-bit error control code  Interpretation of UPI values is different for
 to correct one bit error or  Client data frames (PTI=000) or
 Client management frames (PTI=100)
 to detect multiple bit errors in the payload type field
 More details on the next slides
68
GFP - Extension Header
Extension Header Field

 supports technology specific data link headers,
Core Header e.g.
 virtual link identifier
Payload Payload  source/destination adress
Headers Type  Class of Service
 it is 0-60 byte long and indicated in the Type
field (EXI)
 Three Extension Header Variants are currently
Payload
Client Extension defined for point-to-point or ring configurations
Area
Payload Header
Information Field  EXI = 0000  Null Extension Header
 EXI = 0001  Linear Frame
 EXI = 0010  Ring Frame
 EXI = Others  Reserved
Optional
Payload FCS
69
GFP - Linear Extension Header
Linear Frame Extension Header (EXI = 0001)
 applies to linear (point-to-point) configurations, where
Type several independent clients or services are aggregated
1 to one transport path
Type 1
tHEC 1 CID - Channel ID
tHEC 1  8-bit field to indentify up to 256 independent GFP
channels over the same link
CID 1
Spare 1 Spare
eHEC 1  8-bit field for future use
eHEC 1
Extension Header eHEC - Extension Header Correction
Field  16-bit error control code
 to correct on bit error
 to to detect multiple bit errors in the extension header
field
Extension Header for ring frame  for further study

70
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 CID 1..256

Spare signals
GFP Streams eHEC
with different clients eHEC
CID=0
CID=0 CID=0
Linear Extension
Header
CID=1 CID=1 CID=1
GFP CID=1 CID=2 CID=1 CID=0
Mux
CID=2
CID=2 CID=2
IDLE
Insertion
71
GFP - Frames Overview
PLI
PTI PFI EXI
PLI
UPI
cHEC
tHEC
4 Core Header cHEC
tHEC
Payload
Payload Type
Headers
Payload
Area Client
Payload Extension
Information Header
Field CID
4 - 65535
Spare
Optional eHEC
Payload FCS eHEC
8 bit
72
GFP -
Operation
Modes
73
GFP Operation Modes
GFP-F (Framed Mapped):

 For packet oriented clients, e.g. Ethernet
00
 One Client Packet = packed in one GFP frame (1:1)
 Minimal overhead
GFP-T (Transparent Mapped):

 Client characters are directly mapped in GFP-T
frames e.g. Fibre Channel
 Fixed length GFP frames
 Minimal Latency
GFP IDLE Frame:
 Rate Adaptation (“stuffing”)
GFP Management Frame:

 under study
74
GFP Operation Modes
variable
GFP-F GFP Ethernet Frame GFP GFP Eth. FrameGFP GFP GFP Eth
Frame by Frame
1GigE LE Ethernet Frame IDLE Eth. Frame IDLE Eth
Block by Block
GFP-T GFP Transparent GFP Transparent GFP Transparent GFP
fixed
GFP GFP Header or IDLE frames GFP
75
GFP-F Client vs. Transport Rate
GFP-F
Variable Client Rate Constant Transport Rate
Mbit/s Mbit/s
M
F a IDLEs
I p
F p
+
O e
t r t
Ethernet GFP-F Mapper GFP-F IDLEs
Fast Ethernet
Gigabit Ethernet Client
IP
PPP
76
GFP-T mapping procedure
1GigE LE Ethernet Frame IDLE Eth. Frame IDLE Eth
8B/10B Codewords
1. Decoding: 1 GbE GFP

Data Codes Data Bytes (8 Bit)
Control Codes Control Code Indicator (4 Bit)
2. 64B/65B Block Code
8-byte block
Leading bit
Re-arranging of leading bits to the end
77
GFP-T mapping procedure
3. CRC-16 calculation
CRC-16
4. Superblock formation and GFP OH
Superblocks Superblocks **** Superblocks
GFP Core header Optional GFP FCS

&
Payload header
78
GFP-T Client vs. Transport Rate
GFP-T
Constant Client Data Rate Constant Transport Rate
Mbit/s Mbit/s
M
a
100 % Decoder p
100+x %
/ Coder p
e
t r t
Effective Payload
GFP-T Mapper GFP Overhead
Client IDLEs
Client IDLEs
Fibre Channel
ESCON Effective Payload
FICON
Gigabit Ethernet
10 GigE
Anything!
79
GFP-F
&
GFP-T
80
GFP-F vs. GFP-T
GFP-F GFP-T
• used for connections where • for applications that are sensitive to
efficiency and flexibility are key latency or unknown physical layers
• 1:1 relation between service • all code words from physical layer
frame/paket and GFP frame are transported
• buffering necessary, this • primarily targeted at SANs

increases latency
• preferred option for GE and IP
• good for statistical multiplex services
81
GFP -
Framing
Procedures
82
GFP - Frame Delineation
..... it’s all about synchronisation!
Variable length 4 to 65539 Byte
GFP Payload
PLI
Payload Length Indicator
c c
P P
H H
L L
E E GFP uses
I I
C C •the Payload Length Indicator and
•the Core Header protection field
CRC-16 for frame synchronization
83
GFP - Frame Delineation
Comparer PLI cHEC

2 byte 2 byte
01001111110010010100101001000101111010010101001010101010010111101
Expected next Core Header

CRC-16
1. HUNT State
• Searching for a correct formated 2. PreSync State
4 byte Core Header • Jump to the next correct Core
• Byte by Byte search Header using PLI info
• Bit Error Correction = disabled • Frame by frame search for x
consecutive correct cHECs
• Bit Error Correction = disabled
3. Sync State • Successful? - Yes
• Jump to the next frame using PLI
• Single Bit Error Correction = enabled
• Detection of Multiple Bit Errors?
84
GFP - F
Payload
Specifics
85
Bytes
GFP & Ethernet MAC Payload
PLI 2
cHEC 2
Bytes Type 2
tHEC 2
7 Preamble 0-60
GFP Extension
1 Start of Frame Delimeter Header
6 Destination Address Destination Address

6 Source Address Source Address
2 Length/Type Length/Type
GFP As
MAC Client Payload Client
MAC Client
46-
1500 Pad Pad
4 Frame Check Sequence Frame Check Sequence
Ethernet MAC Frame GFP-F Frame
 Ethernet Inter-Packet-Gaps are deleted before

encapsulation and restored after transmission
 Byte alignment and bit identification is maintained
86
IP & PPP Payload
Bytes
PLI 2
cHEC 2
Type 2
Bytes tHEC 2
GFP Extension 0-60
1 Flag Header
1 Address Address
1 Control Control
2 PPP Type PPP Type
GFP As
PPP Information PPP Payload
Information Client
Pad Pad
4 Frame Check Sequence Frame Check Sequence
PPP/HDLC Frame GFP-F Frame
87
Ethernet to GFP-Framed
Up to 10M
Ethernet Stream
Core Header 10M

7.5M
5M
GFP Packet Payload
2.5M
t
1 2 3 4
Pure Ethernet
GFP-F Packet GFP-IDLE Packet

Result PLI 2 00hex
cHEC 2 00hex
00hex Scrambling!
00hex
X
Payload
Constant Stream
88
GFP-Framed to VC
GFP-Framed
Packet Stream
10M
Byte-Interleaving 7.5M
5M
2.5M
t
1 2 3 4
GFP Stream
GFP Frames VC-12 VC-12 VC-12 VC-12 VC-12
in VC containers #1 #2 #3 #4 #5
Transport
Transport Thru the Network
89
Generic Frame Procedure
Reliable Expandable
Easy & stabile with no need for
algorithm new transport
Header Correction equipment
GFP
BENEFITS
Compatible New
works with basically
any higher layer Opportunities
service and lower Technological &
layer network! Economical
90
Other
Encapsulation
Methods
91
HDLC, LAPS & GFP frame
HDLC LAPS GFP - frame
Flag Flag Core Header
(1byte) (1byte) (4byte)
Address. Address.
(1 byte) (1 byte) Payload
Header
Control. Control.
(1 byte) (1 byte) (4 – 64 byte)
SAPI
(1 byte) Client
SAPI payload
Payload
(1 byte)
Optional
Payload FCS
Payload (4 bye)
CRC
(4 byte)
Flag
(1byte)
CRC
(4 byte)
Flag
(1byte)
92
HDLC, LAPS & GFP frame
HDLC LAPS GFP
Advantages  variable frame variable frame  flexible for a large

length, depending length, number of services
on payload length depending on  simple and stable
payload length synchronization
 variable frame length
 additional service features
e.g. multiplexing
Disadvantages  only Ethernet  only Ethernet  fairly large OH

and IP payload and IP payload
 unstable  unstable
synchronization synchronization
93
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
94
The Evolution
95
“New SONET/SDH” - the evolution of SONET/SDH
 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!
Native Interfaces
Ethernet LCAS
MUX/DMUX
GFP VC
?
Ficon Link
Generic Virtual Capacity SONET/
Escon Frame Concatination Adjustment SDH
Procedure Scheme
Fibre
Channel
96
Standards
97
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
98
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
99
Abbreviations
100
Abbreviations
CC: Continguous Concatenation
cHEC: Core Header Error Check MAN: Metropolitan Area Network
CRC: Cyclic Redundancy Check MFI: Multi Frame Indicator
EOF: End of Frame MSOH: Multiplexer Section Overhead
EoS: Ethernet over SONET NE: Network Element
ESCON: Enterprise Systems Connection OTN: Optical transport Network
FCS: Frame Check Sequence OSI: Open System Interconnect
FD: Full Duplex PDU: Protocol Data Unit
FICON: Fibre Connection PLI: PDU Length Indicator
GFP: Generic Frame Procedure PoS: Packet over SDH/Sonet
GFP-F: Frame mapped GFP PPP: Point-to-Point Protocol
GFP-T: Transparent GFP RSOH: Repeater Section Overhead
GMPLS: Generalized Mulitprotocol SAN: Storage Area Networks
Label Switching SDH: Synchronous Digital Hierachy
IP: Internet Protocol TCP: Transport Control Protocol
LAN: Local Area Network TDM: Time Division Multiplexing
LAPS: Link Access Procedure SDH VC: Virtual Concatenation
LCAS: Link Capacity Adjustment VC-xc: Virtual Container
Scheme VCG: Virtual Container Group
MAC: Media Access Control WAN: Wide Area Network
101

Overview of NG-SDH

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Overview of NG-SDH

Încărcat de

Drepturi de autor:

Formate disponibile

Overview of NG-SDH

 Network status today and future

 SDH/ SONET - is the deployed technology in the core

Virtual Private Network

Fibre Channel GFP-T

Storage Area Network Storage Server

Ethernet SONET / SDH

Mass market Carrier Class market

Dynamic Bandwidth Fixed Bandwidth

Connection less Connection oriented

Best Effort Service High Quality of Service

How to solve all these challenges?

Problem: How can we efficiently transport Ethernet over

VC-12 ...too small ! VC-3 ... inefficient

Can’t 5 x VC-12 be concatenated?

Contiguous AU-4 Pointers VC-4-5 VC-4-6 VC-4-7 VC-4-8

Concatenation VC-4-9 VC-4-10 VC-4-11 VC-4-12

The block has to start at defined positions in the payload

Virtual AU-4 Pointers

Concatenation VC-4-9 VC-4-10 VC-4-11 VC-4-12

The blocks can start at any position in the payload

Virtual Concatenated Group (VCG) of X VC-n containers!

Nomenclature Granularity Max. Capacity

VC-4 VC-4 –n v 149 M - 38.3G

VC-3 VC-3 –n v 48 M - 12.7 G

VC-11 VC-11 –n v 1.6M - 102 M

Maximum Concatenation: = 256 containers

data SDH efficiency

More services integrated- by using VC!

Result: VCG members can now be distinguished and sorted!

C-4 C-4 One Path C-4 C-4

Core Network VC-4-4c

Way 1 Arrival Demapping

High Order VC Low Order VC

Time for transmitting ONE multi-frame: 16 byte x 125µs = 2ms

MFI1 (4) MFI2 (8)

MFI 2 - Multi Frame Indicator 2

High Order VC Frame Counter:

K4 byte (VC-2, 11, 12)

bit 1:Extended Signal label - 32 frame multi-frame

bit 2: 32 frame MF should be in phase with b1 multi-frame

Time for transmitting ONE multi-frame:

FC - Multi Frame Indicator

Low Order VC Frame Counter:

Economical Efficient &

 How can path bandwidth be increased or decreased?

 How can we ensure QoS for data services?

Kansas City Washington

Location A Houston Orlando

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

Location A Houston Orlando

 Operator installs VC & LCAS edge equipment

 Operator manually provisions additional 50M path

 LCAS protocol runs between the two edge NE!

VCG LCAS LCAS LCAS

MFI SQ CTRL GID RS-Ack MST CRC

Information Packets exchanged between the two

MFI SQ CTRL GID RS-Ack MST CRC

MFI - Multi Frame Indicator Field

MFI = 0 MFI = 1 MFI = 2 MFI = max MFI = 0 MFI = 1

MFI is necessary for