ETHERNET over SDH
Scope of the discussion
Ethernet
Ethernet over SDH : What and Why?
How EoS is achieved?
Ethernet frame structure
Generic Frame Procedure(GFP)
Virtual Concatenation (VCAT)
POH
Sequencing
Differential Delay compensation
Link Capacity Adjustment Scheme(LCAS)
LCAS frame format and messaging
Protocol(Ctrl, MST, Rs-Ack)
Scenarios(Addition, Deletion, Fault Detection)
Ethernet
The name comes from the physical concept of
ether
Family of frame based computer networking
technologies for local area networks(LAN)
Originally based on the idea of computers
communicating over a shared coaxial cable
acting as a broadcast transmission medium
Ethernet over SDH : What and Why
Already existing SDH networks
Data networks such as Ethernet typically have
not provided the integrated Operations,
Administration,Maintenance and Provisioning
(OAM&P) capabilities that have made
SONET/SDH so valuable to carriers.
Why Ethernet over SDH
Ethernet over SDH (EoS) was developed primarily to provide a simple, flexible and
cost-effective solution to customers offering Ethernet based services.
An EoS transport solution fundamentally addresses the following key issues
Generic Framing Procedure (GFP), Framing protocol to encapsulate Ethernet frames to
generate an SDH payload
Virtual Concatenation (VCAT), Bandwidth provisioning scheme. Bandwidth mapping
of the SDH payload to SDH channels, which are either high-order or low-order virtual
containers (VCs)
Link Capacity Adjustment Scheme (LCAS)
Link Integrity (LI)
Auto Negotiation (AN)
Flow Control, Rate shaping mechanism to avoid packet drops
Ethernet Frame
46-1500 bytes
Preamble
This is a stream of bits used to allow the transmitter and receiver to
synchronize their communication. The preamble is an alternating
pattern of binary 56 ones and zeroes.
Start Frame Delimiter
This is always 10101011 and is used to indicate the beginning of
the frame information.
Destination MAC
This is the MAC address of the machine receiving data. Network
Interface Card (NIC) listening to the wire is checking this field for it's
own MAC address.
Source MAC
This is the MAC address of the machine transmitting data.
Length
This is the length of the entire Ethernet frame in bytes. Although this field
can hold any value between 0 and 65,534, but for different Ethernet cards it
can be 1500 or 9216 or 9600 as that is usually the maximum transmission
frame size for most serial connections. Ethernet networks tend to use serial
devices to access the Internet.
Data
The data is inserted here. This is where the IP header and data is placed if
you are running IP over Ethernet. Contained within the data/padding section
of an IEEE 803.2 frame are four specific fields:
DSAP - Destination Service Access Point
SSAP - Source Service Access Point
CTRL - Control bits for Ethernet communication
NLI - Network Layer Interface
FCS
This field contains the Frame Check Sequence (FCS) which is calculated
using a Cyclic Redundancy Check (CRC). The FCS allows Ethernet to
detect errors in the Ethernet frame and reject the frame if it appears
damaged.
Generic Framing Procedure(GFP)
To begin with.
Technology to map Ethernet into VC-n
Provides a standard mapping/framing technique for
Layer 2 signals into SONET/SDH
standard for delineating octet-aligned, variable-length
client payloads for mapping into octet-synchronous
paths
uses a cell delineation scheme similar to ATM instead of
Flags like HDLC. It carries a fixed amount of overhead
per frame regardless of size. Transmission order is MSB
first
Advantages of GFP
GFP is more efficient than HDLC (High Level Data Link Control)
protocol , maintaining a fixed overhead
Traffic management and QoS control are significantly easier
GFP is more robust than HDLC and less susceptable to bit errors
GFP is supported by OTN (Optical Transport Network)/WDM
interfaces in addition to SONET/SDH
GFP permits multiple protocols from different ports or links to
share the same transport path,
resulting in more efficient use of available bandwidth
GFP supports Resilient Packet Ring operation and is inherently
more suitable for packet traffic.
GFP Modes
GFP-F Frame Mode - Direct replacement for HDLC :
Variable length packets, maps entire client frame into one GFP-F frame
Supports 10/100 Mbps , Gigabit , 10 Gigabit Ethernet
Fixed length packets , does not have to map complete Ethernet frame into GFP-T
thus reduces latency in the system
Supports 8B/10B block-coded clients :
Gigabit Ethernet, Fiber Channel ,FICON and ESCON
Framed Mapped
GFP
GFP Client Specific Aspect
(Client Dependent)
Transparent Mapped
GFP
GFP Common Aspect
(Client Independent)
SONET/SDH Path
OTN Path
Terms and Definitions:
Frame Mapped GFP:
A GFP mapping in which a client signal frame is mapped directly into one GFP frame.
Channel ID:
A one byte ID indicating a communications channel number used between GFP termination
points.
Client data Frame:
A GFP frame containing payload data from a client signal.
Client Management Frame:
A GFP frame containing information associated with the management of the GFP link.
Control Frame:
A GFP frame used to control the GFP connection.
Linear Frame:
A point-to-point-frame used to carry several independent links aggregated to a single
transport path. Each link has its own Channel ID (0-255).
Maximum Transmission Unit:
The maximum size of the GFP payload area in octets.
Source Port / Destination Port:
A logical addressable entity on a physical interface.
Superblock:
A transparent GFP Structure combining multiple 64B/65B codes along with a CRC-16.
Transparent GFP:
A GFP mapping in which block-coded client characters are mapped into a fixed length GFP
frame and transmitted immediately without waiting for an entire client data frame.
GFP Frame
1 2 3 4 5 6 7
8
1 2 3 4 5 6 7
8
PLI (15:8)
16-Bit Payload
Length Indicator
PLI (7:0)
cHEC Field
(CRC-16)
4
Core
Header
cHEC (15:8)
Payload Headers
(4-64 Bytes)
cHEC (7:0)
Notes:
4 -65535
Payload
Area
CLIENT
PAYLOAD
INFORMATION
FIELD
PLI Codes of 0-3 reserved for GFP control
frames
cHEC Polynomial = x16 + x12 + x5 + 1
cHEC calculated over Core header only.
Core header scrambled with B6AB31E0H
Optional Payload FCS
(CRC-32)
1 2 3 4 5 6 7
8
PTI
TYPE
GFP Payload Type Identifiers
000
Client Data
100
Client Management
Other
Reserved
Extension Header
Field
eHEC
Payload Headers
(4-64 Bytes)
EXI
UPI
tHEC
1 2 3 4 5 6 7
8
P
F
I
0
1
Notes:
GFP Payload FCS Indicator
FCS Absent
FCS Present
2-byte Payload Type field
CLIENT
PAYLOAD
INFORMATION
FIELD
PTI - Payload Type Identifier(3 bits)
PFI - Payload FCS Indicator (1 bit)
EXI - Extension Header Identifier (4 bits)
0000
GFP Extension Header Identifiers
Used for single
Null Extension Header client, point-to-point
applications
0001
Linear Frame
0010
Other
Ring Frame
Reserved
UPI - User Payload Identifier (8 bits)
Optional Payload FCS
(CRC-32)
GFP Client Frame Structure
Used for port
aggregation over a
single transport path
For further study
Notes:
2-byte Payload Type field
PTI - Payload Type Identifier(3 bits)
PFI - Payload FCS Indicator (1 bit)
PTI
P
F
I
UPI
EXI - Extension Header Identifier (4 bits)
UPI - User Payload Identifier (8 bits)
User Payload Identifiers for GFP Client Frames
PTI = 000
00H
Reserved- do not use
01H
Frame Mapped Ethernet
02H
Frame Mapped PPP
03H
Transparent Fiber Channel
04H
Transparent FICON
05H
Transparent ESCON
06H
Transparent Gb Ethernet
07H
Reserved for future use
Frame Mapped Multiple
08H
Access Protocol over SDH
(MAPOS)
09H thru EFH
Reserved for future use
F0H thru FEH
Reserved for proprietary use
GFP Client Management Frame User Payload
PTI = 100
00H
Reserved- do not use
Client Signal Fail (Loss of
01H
Client signal)
03H thru FEH
Reserved for future use
FFH
Reserved- do not use
EXI
1 2 3 4 5 6 7
8
tHEC (15:8)
TYPE
tHEC (7:0)
tHEC
1 2 3 4 5 6 7
8
Payload Headers
(4-64 Bytes)
Extension Header
Field
eHEC
Notes:
tHEC Polynomial = x16 + x12 + x5 + 1
CLIENT
PAYLOAD
INFORMATION
FIELD
Optional Payload FCS
(CRC-32)
tHEC calculated over all octets in the type
field excluding the tHEC bytes.
1 2 3 4 5 6 7
8
TYPE
tHEC
Extension Header
Field
1 2 3 4 5 6 7
8
eHEC
Payload Headers
(4-64 Bytes)
CID (7:0)
SPARE (7:0)
eHEC (15:8)
eHEC (7:0)
Notes:
CID - Channel ID (0-255)
CLIENT
PAYLOAD
INFORMATION
FIELD
eHEC Polynomial = x16 + x12 + x5 + 1
eHEC calculated over all octets in the
extension header field excluding the eHEC
bytes.
Extension Header Field
Type
# Octets
0
Null Extension Header
Linear Frame
2
Ring Frame
For Further Study
eHEC
0
2
---
Note: Extension Header Length is fixed according to
the application. Presently, only two applications are
defined.
Optional Payload FCS
(CRC-32)
1 2 3 4 5 6 7
8
1 2 3 4 5 6 7
8
Payload Headers
(4-64 Bytes)
CLIENT
PAYLOAD
INFORMATION
FIELD
Payload Information
Field
Payload
Information
Field
Optional
pFCS (31:0)
pFCS (31:24)
pFCS (23:16)
pFCS (15:8)
Optional Payload FCS
(CRC-32)
pFCS (7:0)
Notes:
Payload Information Field: Variable length (0 to 65535-X octets, where X is the size of the payload header)
pFCS is optional
pFCS Polynomial = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
pFCS calculated over all octets in the Payload Information.
Payload scrambling: self-synchronous uses x 43 + 1 polynomial (similar to LAPS)
1 2 3 4 5 6 7
8
16-Bit Payload
Length Indicator
cHEC Field
(CRC-16)
# of OCTETs
4
Core
Header
Notes:
GFP IDLE Frame contains only four bytes
Used for padding transmission container (similar to ATM)
PLI =0000H
cHEC = 0000H
Core header scrambled with B6AB31E0H
GFP Idle Frame Structure
1 2 3 4 5 6 7
8
PLI (15:8)
PLI (7:0)
cHEC (15:8)
cHEC (7:0)
IEEE 802.3 Ethernet MAC Frame
1 2 3 4 5 6 7
8
7
Preamble
1 Start of Frame Delimiter
6 Destination Address (DA)
6
Source Address (SA)
Length/Type
GFP Frame
1 2 3 4 5 6 7
8
PLI Field
cHEC Field
Type Field
tHEC Field
Extension Header
46-1500
MAC Client Data
GFP
PAD
4
FCS
Payload
Information
Field
GFP Ethernet Encapsulation Specified per ITU-T G.7041/Y.1303
0 - 60
Virtual Concatenation is an inverse multiplexing technique(also known as
byte slicing) used
to split SDH bandwidth into logical groups, which may be transported or
routed
independently
Virtual Concatenation breaks the contiguous bandwidth into individual
VCs, transports the
individual VCs and recombines these VCs to a contiguous bandwidth at the
end point of the
transmission
Motivation behind the concept
(Advantages)
Scalability : Allows bandwidth to be tuned in small increments on demand
to match desired data rate and avoid wastage. Traditional contiguous
concatenation comes in coarse increments.
Efficiency : More easily routed through a network and aids to eliminate
stranded bandwidth. Allows for more efficient usage of an existing
networks available bandwidth.
Compatibility : Requires only end nodes of the network to be aware of the
containers being virtually concatenated. Transparent to core network
elements.
Resiliency : Individual members of a virtually concatenated group can be
routed as diversely as possible across a network. So if one member is
lost, the others are likely to be operational albeit with a reduced
bandwidth.
Virtual Concatenation(VCAT)
Virtual Concatenation is a Management Plane-oriented protocol. Virtual
Concatenation of multiple paths involves:
Creating a link with a Source End (SE) and a Sink End (Sk) for the Virtually
Concatenated Group (VCG).
Identifying members of the VCG and assigning the physical path for each member.
Use of a Path Overhead (POH) byte by the SE in all the constituent members to
pass information to the Sk on:
the relative phase difference between arriving members of the VCG.
the sequence number of each arriving member.
Suitably-sized memory for buffering of all arriving members of a VCG at the Sk.
An optional method for hitlessly adjusting the payload allocated to VCGs (LCAS).
Management Plane
Intermediate
Network Element
Provisioning
Sink End
Provisioning
Source End
Provisioning
So
Sk
NE
NE
Source End
Sink End
Transport Plane
The process
The Management Plane identifies the VCG members,
assigns a physical path for each of them and tracks the
intermediate Sub-Network Connection (SNC) switching.
The So of the VCG then uses the link to pass a Path
Overhead (POH) byte to the Sk.
The byte conveys information about the relative phase
difference between each arriving member of the VCG
and indicates the physical delay incurred during transit.
By delivering the sequence number of each member,the
POH byte also informs the Sk of that member's position
in the original order of VCG members at the So.
A quick recap of the SDH
frame..
Concatenations
VCG container possibilities
SONET Name
SDH Name
Low - Order Containers
VT-1.5
VC-11
VT-2
VC-12
VT-3
--VT-6
VC-2
High - Order Containers
--TU-3/VC-3
STS-1 SPE
AU-3/VC-3
STS-3c SPE AU-4/VC-4
Min
Bandwidth
per Group
Mbps
Container
Columns
Maximum
Containers 'n'
per Group
3
4
6
12
64
64
64
64
1.600000
2.176000
3.328000
6.784000
84
84
260
256
256
256
48.384000
48.384000
149.760000
Max Bandwidth
Granularity
per Group
Mbps
Mbps
102.400000
139.264000
212.992000
434.176000
Notes
1.600000
2.176000
3.328000
6.784000
1,3
1,3
1,3
1,3
12386.304000 48.384000
12386.304000 48.384000
38388.560000 149.760000
2,4
2
2
Notes:
1) Number of containers limited by 6 bit field in K4 bit 2 multiframe structure.
2) Number of containers limited by 8 bit field in H4 byte multiframe structure.
3) TU pointer and TU-POH bytes excluded
4) The TU-3/VC-3 Container is a low order entity in terms of its position in the SDH hierarchy but is handled much
the same as an AU-3/VC-3 for VC & LCAS due to its size and structure
Higher Order VCAT
Path Signal Label : C2 Identifies type of payload being carried. All C2 bytes of
a VCG must be set the same in Virtual Concatenation applications.
Multiframe Alignment Signal: H4 used to identify individual frames in a
Multiframe Sequence for VT mappings (500 microseconds) or for Virtual
Concatenation applications (512 milliseconds).
Understanding Higher Order VCAT
Virtual Concatenation Process:
A multi-tier multiframe structure is used:
Higher Order VCG multiframe uses a two tier system
4096 frames in length (16 frames within 256 frames)
512 millisecond period
Up to 256 containers may be concatenated
Lower Order VCG multiframe uses a three tier system
4096 frames in length (32 frames within 32 frames built on a 500 usec. multiframe)
512 millisecond period
Up to 64 containers may be concatenated.
Multiframe position used to re-align data at destination (sink)
Tributaries of the group are assigned a sequence number:
0-63 for 1.5M to 6M containers
0-255 for VC-3/VC-4 containers
Sequence number used to recover data position sequence at destination (sink)
Information to be transmitted over the Concatenated group is transmitted by an inverse multiplexing scheme.
Bytes are distributed over the full group of active containers in order of sequence (0, 1, 2, etc.)
Distributed
Payload
POH
J1
B3
C2
G1
Multiframe
Sequence Bytes
(Frame Number and
Sequence Number)
F2
H4
J1
B3
C2
G1
F2
J1
B3
C2
G1
F2
H4
F3/Z3
H4
F3/Z3
K3/Z4
F3/Z3
K3/Z4
SQ# =0 N1/Z5
K3/Z4
SQ# =1 N1/Z5
SQ# =2 N1/Z5
All containers carry the same
multiframe Number but have
unique sequence numbers.
, pad, A, D,
pad
...
, ,pad,
B, E,
pad
,, ...pad, C,
F, pad ,
...
512 Millisecond Multiframe H4 byte structure
MFI-1 frame
Bits 5-8 of H4 Byte
Sequential count 0-F (4-bits)
16 frames in length (2 msec. Period)
Used to indicate purpose of information in Bits 1-4 of H4 byte
Frame 0 contains MFI-2 count bits 1-4
Frame 1 contains MFI-2 count bits 5-8
Frame 14 contains Sequence Indicator bits 1-4
Frame 15 contains Sequence Indicator bits 5-8
MFI-2:
Sequential count 0-FF (8-bits)
256 frames in length (512 msec period)
Used to compensate for wide propagation delay variations & realign data frames at
destination
Sequence Number (00-FF)
Used to identify member position of path signal within VCG for proper multiplexing
of recovered data
Lower order VCAT
The V5 byte signal label
There is insufficient space in the V5 overhead byte to define all
payload types in the normal Signal Label field .The
'101' code is used to designate an Extended Signal Label for
all additional types specified using bit 1 in the K4 byte.
The K4 byte
The K4/Z7 byte has several defined fields which
are used for different purposes.
The first two bits are used for Extended Signal
Label and Lower-Order Virtual Concatenation
Using these bits in conjunction, a 512millisecond multiframe is constructed for the
purpose of transporting payloads across the
network and reconstructing them at the
destination (Sink End).
K4 byte, Bit 1 usage
Bit 1 establishes a 32-bit multiframe period 16
milliseconds in length.
One bit of this sequence is received every 500
microseconds.
Bits 1 through 11 of this structure create a
framing pattern used to validate information
contained in both bit 1 and bit 2 of K4 for
extended applications
Bits 12-19 are used to define the Extended Signal
Label (payload type).
Bit 20 is always set to 0.
The remaining bits are reserved for future use
(set to 0).
K4 Byte, Bit 2 Usage
Bit 2 uses a 32-frame multiframe period of 16
milliseconds in length running in parallel to that
created by bit 1
The first 5 bits contain a frame count (00-1FH) which
runs continuously for a total period of 512
milliseconds.
As in HO VCAT applications, the frame number is
used for differential delay compensation and the
sequence number is used to identify the member
position of a path signal within a VCG for proper
multiplexing of recovered data at the destination.
Typical 500 Microsecond Multiframe Structure
Showing VT POH Bytes
Differential Delay
Differential Delay Compensation
Differential delay measures the difference in time among the
channels of a multi channel
with respect to the maximum differential delay allowed for a
signal to arrive at its destination.
VCAT standard allows a differential delay of up to 256ms to be
compensated by the receiver.
In practice, the maximum amount of differential delay that can be
compensated is
implementation specific.
Differential delay > the maximum value loss of data carrying
capability in that direction (no
point in keeping that channel in VCAT group)
VCAT allows that channel to be temporarily removed from the data
carrying channels.
The maximum differential delay supported on the TP01 card is 64
ms
The maximum differential delay supported on the TR01 card is 50
Link Capacity Adjustment Scheme
(LCAS) : Dynamic Bandwidth
Management
>LCAS provides a control mechanism for the "hitless" increasing
or decreasing of the capacity in a VCG link to meet the bandwidth
needs of the application.
>It also provides the capability to temporarily remove member
links that have experienced a failure.
>The LCAS assumes that, in cases of capacity initiation, increase,
or decrease, the modification of the end-to-end path of each
individual VCG member is the responsibility of the network and
element management systems.
>That is, LCAS provides a mechanism for bandwidth reprovisioning, but it is not the controlling mechanism that decides
when or why the operation is made.
Motivation behind the concept
Dynamic Scalability : Allows bandwidth to be dynamically tuned in small
increments on demand to match desired data rate and avoid wastage.
Efficiency : Allows for more efficient usage of an existing networks
available bandwidth by trimming bandwidth to match the subscribers
work schedules.
Compatibility : Backward compatible to Virtually Concatenated services
not offering LCAS. Transparent to core network elements. Interworking
between LCAS and non-LCAS nodes is facilitated.
Resiliency : Individual members of a virtually concatenated group can be
routed as diversely as possible across a network. So if one member is
lost, the others are likely to be operational albeit with a reduced
bandwidth
The Basics
New
protocol a companion to Virtual Concatenation.
An adaptation function operating within all SONET/SDH nodes in the path of
a given flow.
A real time control mechanism to increase/decrease capacity of a virtually
concatenated group without incurring hits to active traffic.
All provisioning capacity changes initiated and controlled by the Network
Operational Support System (OSS) and Element Management Systems (EMS).
Operation is unidirectional. Has to be repeated in opposite direction for bidirectional management.
Directional actions are independent and not required to be synchronized.
Can autonomously remove failed members temporarily from a group (not
hitless removal). When failure condition is remedied, LCAS will add members
back into the group (hitless addition).
Defined for:
High order SONET (STS-1/STS-3c SPEs) and SDH (VC-3/4) payloads.
Low order SONET (VT-1.5/2/3/6 SPEs) and SDH (VC-2/12/11) payloads.
LCAS Methodology
Bandwidth needs of Application may be trimmed as required
Control Packets used to increase or decrease VCG Capacity
Member links experiencing failures may be removed from group
Network Management System responsible for creating, destroying and managing VCGs
Control Packets
Synchronization of changes in link capacity managed via control packets
Control packets describe the status of the link for next control packet
Changes sent in advance so receiver may anticipate new configuration
Control packets are sent from SOURCE to SINK and from SINK to SOURCE
Forward direction (SOURCE to SINK)
Multiframe Indicator Field(s) - MFI
Sequence Indicator Field - SQ
Control Field - CTRL
Group Identification Bit - GID
Unused/Reserved - set to 0
CRC field
High Order LCAS - CRC-8
Low Order LCAS - CRC-3
Return direction (SINK to SOURCE)
Member Status Field - MST
Re-Sequence Acknowledge Bit - RS-ACK
Unused/Reserved - set to 0
CRC field
High Order LCAS - CRC-8
Low Order LCAS - CRC-3
The LCAS control messaging channel is signaled via the H4 path overhead byte, the
same byte that is used for VCAT. The following summarizes the parameters used in
VCAT and LCAS control messaging:
Indicator Field(s) - MFI: The mechanism employed between the VCG transmitter
and VCG receiver to determine the differential delay and use for realignment between members
in the same VCG
At source MFI is equal for all members of a VCG and is incremented each frame
At Sink, MFI is used to realign the payload for all members of the group. The MFI is
used to measure the differential delay between members of the same VCG.
For HO VCAT the range is 0-4095, and for LO VCAT the range is 0-31.
Multiframe
Sequence Indicator Field SQ : The number assigned to members within the VCG where the
number is unique within one VCG and sequential (corresponding to reassembly order of the
VCAT).
Contains the sequence number assigned to a specific member of a VCG.
Each member of the VCG is assigned a unique number starting at 0
At initiation, all members are assigned a SQ = FF.
The SQ range for HO VCAT is 0-255 (256 maximum members within one VCG), and 0-63 for
LO VCAT (64 maximum members within one VCG).
Group Identification Bit - GID
Used to identify the VCG
The GID bit of all members of a VCG will have the GID bit set equal in frames with the
same MFI #.
The contents of the GID is a PRBS = 215 - 1.
The GID is not valid for members sending an IDLE control.
Control Field CTRL : LCAS control command from transmitter to receiver VCG
The control field is used to transfer information from source to sink
Used to synchronize the sink with the source
Provides status of individual VCG members
Commands: FIXED, ADD, NORM, EOS, IDLE, and DNU
FIXED Indication of a fixed-bandwidth (non-VCAT) operation, non-LCAS mode
ADD Identified member that is to be added to the group.
NORM Normal transmission, steady-state no-change mode.
EOS End of sequence, return to normal transmission mode.
IDLE Member is not part of or is about to be removed from this group.
DNU Do not use this member of VCG. The receiver has detected a failure.
Member Status Field MST : Member status (MST): A summary status report of all members of a VCG (OK or
FAIL) from the receiver back to the transmitter
Information passed from sink to source regarding all members of a VCG (0 = Normal / 1= FAIL)
The SQ number supplied by the source is key to the MST responses by the sink.
At initiation of a VCG all MST values shall be set to FAIL
Re-Sequence Acknowledge Bit - RS-ACK : Indication from receiver to transmitter that the changes initiated from
the transmitter have been accepted and that the transmitter can begin accepting the new member status information
Used by the sink to acknowledge changes in the sequence number
Bit changed from 0 to 1 or from 1 to 0
Change occurs after status of all members are evaluated
The source uses the RS-ACK as a validation of its requested change
Unused/Reserved - set to 0
CRC field - CRC-8 : Validation check to protect the integrity of each VCAT control message. If the CRC check fails,
the VCAT overhead contents are not used.
Simplifies process for accepting change requests
CRC failure - request is rejected / CRC Pass - request accepted immediately (no debounce)
K4 Byte, Bit 1: Same with or without LCAS
Extended
LO
Sig. Label Vir. Concat.
1
K4
Byte
(1/500
microseconds)
APS
APS
ERDI
10 11 12 13 14 15
16 17 18 19 20
MFAS
32-Frame Multiframe
(16 millisecond period)
Note: The Multiframe phases
for Bit #1 and Bit #2 are aligned
ERDI
ERDI
21 22 23 24 25 26 27 28 29
0
Extended Signal
Label
MSB
(bit 12-15)
0000
0000
0000
0000
0000
0000
0000
0000
0000
1111
1111
Data Link
30 31 32
R
Reserved
LSB
(bit 16-19)
0000
0111
1000
1001
1010
1011
1100
1101
1110
1110
1111
Hex Code
00H
INTERPRETATION
Reserved
07H
08H
09H
0AH
0BH
0CH
0DH
0EH
Mapping Under Development
ATM Mapping
HDLC/PPP Mapping
HDLC/LAPS Mapping
Virtually Concatenated Test Signal per O.181
GFP mapping
Spare
FEH
FFH
Reserved
LCAS Procedures
Addition of a member to a VCG
Source sends an CTRL=ADD
First member to respond with MST = OK is allocated the next higher
Sequence number
The former high SQ number is given a CTRL= NORM
The New high SQ number is given a CTRL= EOS
Multiple members may be added in one sequence of commands
Payload will be added to the new member following the frame
containing the CRC for the packet with the NORM/EOS CTRL command
for that member
Temporary Removal of a Member
When the source detects a MST=FAIL for a particular member, that member is
removed from the VCG
The source will replace either a CTRL=NORM or a CTRL=EOS with a CTRL=DNU
Following Container frames will contain all 0s as payload
The sink will discontinue processing payload for a member upon receiving a CTRL=
DNU
Recovery from temporary removal
When the source detects a MST=OK for the failed member, that member is
reconnected to the VCG
The source will replace the CTRL=DNU with either a CTRL=NORM or a CTRL=EOS
Following Container frames will contain data as payload
The sink will resume processing payload for a member upon receiving a CTRL=
NORM or CTRL=EOS
Deletion of a Member
When members are deleted from a VCG, remaining members are renumbered
If the highest SQ number is deleted, the next highest number has its CTRL=EOS
If any other member is deleted, all remaining members shall adjust their
sequence number.
Call Flow for member deletion :
1. The NMS issues a decrease command.
2. The source then sends a CTRL message to the sink telling its last member that it is
now the last of a three- member VCG.
3. The source then sends two CTRL messages, with the IDLE indication and member
SQ, to the sink.
4. . The sink then indicates, independently for each member, that the member is now
down via an MST message with the FAIL indication.
5. Finally, an RS-ACK indicates that it has resequenced the VCG.
Removing the Last Member of a
Sequence in a VCG
The NMS issues a decrease command.
The source then sends a CTRL message to the sink
telling its second-to-last member that it is now the last of
the VCG.
The source then sends two CTRL messages with the
IDLE indication and the last member's SQ to the sink.
The MST message with the FAIL state indication is used,
as is an RS-Ack indicating that it has resequenced the
VCG.
Failure Notification of the last
member in VCG
The MST message with the FAIL state indication is sent
to the source.
The source then relays this information to the NMS via a
FAIL status message.
Via a CTRL message, the source tells the sink that the
offending member should not be used with a DNU
indication.
The source then tells the new last member that it is
indeed now the last member with the EOS indication.
Failure of a VCG member, not a last
member
The MST message with the FAIL state indication is sent to the source.
Note: As soon as the FAIL is detected, the sink will immediately begin
reassembly of the concatenated group using only the working members. For
a time (propagation time from sink to source + reaction time of the source +
propagation time from source to the sink) the reassembled data will be
erroneous because it is sent on to all members as it was before the fault.
The source then relays this information to the NMS via a FAIL status
message
Via a CTRL message, the source tells the sink that the offending member
should not be used with a DNU indication.
Note: The source will stop sending data on the erroneous member, since
it will have been reported back as MS = FAIL and consequently the failed
member will have been set to DNU. The LCAS source at the receiving end
does not know when the data integrity has been reestablished. This is dealt
with at a higher layer.
The source then tells the new last member that it is indeed now the last
member using the EOS indication.
The sink then sends an MST message indication that the VCG is now OK.
Finally, the source tells the sink to run in NORMAL mode.
APPENDIX
ABBREVIATIONS USED
ATM: Asynchronous Transfer Mode
cHEC: Core HEC
CID: Channel ID
CoS: Class of Service
CRC: Cyclic Redundancy Check
CSF: Client Signal Fail
DE Discard Eligibility
DP: Destination Port
DST: Destination
eHEC: Extension HEC
EOF: End of Frame
ESCON: Enterprise Systems Connection
FCS: Frame Check Sequence
FICON: Fiber Connection
Frame: An HDLC data structure
GFP: Generic Framing Procedure
GFP-F: Frame mapped GFP
GFP-T: Transparent GFP
HDLC: High Level Data link control
ICMP: Internet Control Message Protocol
IP: Internet Protocol
IPv4 / IPv6: Internet Protocol version 4 / version 6
ISDN: Integrated Services Digital Network
LAN: Local Area Network
LAP: Link Access Procedure
LAPB: Link Access Procedure - Balanced
LAPD: Link Access Procedure - D Channel
LAPF: Link Access Procedure - Frame Relay
LCC: Last Control Character
LLC: Logical Link Control
LOL: Loss of Light
MAC: Media Access Control
MAPOS: Multiple Access Protocol Over SONET/SDH
MTU: Maximum Transmission Unit
O&AM: Operations, Administration & Maintenance
ODU: Optical Data Unit
PDU: Protocol Data Unit
PFI: Payload FCS Identifier
PLI: Payload Length Indicator
PPP: Point-to-point Protocol
PTI: Payload Type Identifier
RD: Running Disparity
RFC: Request for Comment
SAP: Service Access Point
SAPI: Service Access Point Identifier
SBCON: Single-Byte Command Code Sets Connection
SDU: Service Data Unit
SP: Source Port
SRC: Source
TCP: Transmission Control Protocol
tHEC: Type HEC
TTL Time to Live
UDP: User Datagram Protocol
UI: Unnumbered Information
UITS: Unacknowledged Information Transfer Service
UPI: User Payload Identifier
CRC: Cyclic Redundancy Check
CTRL: Control
DNU: Do Not Use
EOS: End of Sequence
GID: Group Identifier
LCAS: Link Capacity Adjustment Scheme
MFI: Multiframe Indicator
MST Member Status
NORM: Normal Operating Mode
RS-Ack: Re-sequence Acknowledge
Sk: Sink
So: Source
SQ: Sequence Indicator
TSD: Trail Signal Degraded
TSF: Trail Signal Failed
VCG: Virtual Concatenated Group
References
ITU-T G.707(SDH)
ITU-T G.7041(GFP)
ITU-T G.7042(LCAS)
IEEE 802.3
Understanding VCAT and LCAS in SONET and
SDH(White paper by Transwitch)
Leveraging Transport For Data Services With
VCAT and LCAS (
http://www.cisco.com/en/US/netsol/ns341/ns396/ns114/ns99/networking_solutio
ns_white_paper09186a00801e121e.shtml
)