Ethernet over SONET/SDH

A previous web page looked at IP over SDH using POS - Packet-over-SONET/SDH - for speeds up to 1Gb/s. However it closed with the disadvantages of carrying IP over POS. It would be preferable if the ethernet MAC frames could be encapsulated in their entirety, and sent over the SONET/SDH link. The advantages would include -

the IP packet doesn`t have to be extracted from the ethernet MAC frame - this reduces hardware complexity
it also reduces the latency caused by the extra signal processing
Quality of Service and VLAN tagging can be retained

EoS

POS is based on the use of PPP to encapsulate the IP packets.

EoS - Ethernet-over-Sonet/SDH - is based on a different protocol, this is usually GFP - Generic Framing Procedure - but it is not the only one that could be used.

GFP takes the stream of ethernet MAC frames, and turns them into a synchronous stream of data. This stream is then mapped into virtual containers, which are then assembled into the STM frame.

The virtual containers that could be used are VC-11, VC-12, VC-3, and VC-4. Typically, the different ethernet speed will use -

10Mb/s ethernet - could use VC-12
100Mb/s ethernet - could use VC-3
1Gb/s ethernet - could use VC-4

As you can see from these, ethernet over GFP over SONET/SDH is about carrying ethernet up to and including 1Gb/s. 10Gb/s ethernet doesn`t need GFP, as it can generate SONET/SDH frames directly, for itself.

GFP

General Framing Procedure is a bit like PPP in some respects - it encapsulates a higher level protocol in a GFP frame.

The higher level protocols that can be encapsulated include ethernet MAC frames and Fibre Channel, and even IP over PPP.

GFP has two effective layers -

GFP-Client Specific Aspects - the upper layer which is dependent on what kind of payload GFP is carrying
GFP-Common Aspects - the lower layer, which is independent of the kind of payload

As well as these two effective layers, GFP has two modes of operation :-

Frame-mapped GFP - in this mode the whole of one incoming upper layer frame is stored in a buffer, and then mapped into a GFP frame in its entirety - this process adds quite a lot of latency
Transparent GFP - in this mode an incoming block-coded upper layer data stream is streamed into the GFP frames - this process introduces very much less latency

As well as these two layers, and the two modes of operation, GFP has three types of frame -

GFP user frame - this is the type of GFP frame that contains the data
GFP control frame - carries control information
GFP idle frame - this is a minimalist variety of frame with no payload section, it is used as a filler frame for some uses of GFP

GFP user frames

The GFP user frame is octet aligned, and like many other protocols, the GFP user frame has two basic sections -

the Core Header - this is always 4 octets
the Payload section - this can vary in size from 4 octets, up to 65535 octets

In GFP, in each octet, bit 1 is the MSB, and bit 8 is the LSB, and bit 1 is transmitted first. So this matches the bit sequence used in SDH, but is the opposite to the bit sequence used in the ethernet MAC frame.

The Core Header

The 4 octets are used as follows -

the first two octets are known as the PLI - PDU Length Indicator - and they indicate how many octets are in the following payload section - so their value can range from 4 up to 65536
octets 3 and 4 are known as the Core HEC field, and are used for single-bit and multi-bit error protection within the Core Header

The PLI octets can also have values of 0, 1, 2, or 3 - these four values are used in various kinds of GFP control frames.

An interesting thought about this is - if the first two octets can have any value between 0 and 65536, how does the receiving node know that it is the start of the frame ? There is no start-of-frame flag or preamble.

The payload section

The payload section is where the data from the higher layer protocol is carried. However it isn`t just data that is in there, as the payload section is divided up into three sections :-

payload header - this can be between 4 and 64 octets long, and contains information specific to the upper layer protocol being carried - the payload header is made up of 4 layers, which are described below
payload - this is where the whole of the upper layer frame is carried - it is variable in size
payload fcs - this is optional, and if used, consists of 4 octets

The whole of the payload section can be up to 65536 octets in length, but that includes the payload header and the payload fcs.

The payload header

As stated above, the payload header is itself built up of 4 layers -

the Type field - this is 2 octets, and is again made up of different parts, described below
tHEC field - this is 2 octets, and provides an integrity check for the Type field
GFP extension headers - this section can be up to 60 octets - its contents tend to be defined by the type field above, so are very specific to the type of the upper layer protocol
another tHEC field - this is again 2 octets, and provides an integrity check for the contents of the extension headers field - these 2 octets are included in the 60 octet maximum size of the extension headers field

The payload header Type field

The payload header Type field is used to indicate the type of content and the format of the GFP payload field. As stated above, the payload header Type field is itself built up of 4 layers -

PTI - payload type identifier - 3 bits
PFI - payload FCS indicator - 1 bit
EXI - extension header identifier - 4 bits
UPI - user payload identifier - 8 bits

The standard isn`t too clear about what all these various fields do, and it appears that some of their functions aren`t even specified yet.

However we seem to have got to the end of all the nesting of sub-sections. So that was the user frame. It does appear that the control frames and idle frames are just sub-sets of the user frame.

Idle frames

GFP must provide full frames on a regular basis to the next layer down - probably SONET or SDH. So if the upper layer protocol is not delivering any content to GFP, then GFP uses the idle frames to fill the virtual containers.

Scrambling

The whole of the payload section is scrambled using the 1 + x43 polynomial.

The whole of the core header section is also scrambled, but it is done seperately from the payload section, and uses a different mechanism, which maximises the 0-1 transitions during the idle periods.

Ethernet over GFP

Ethernet is carried over GFP using the frame mapped mode of operation, so a whole ethernet MAC frame is buffered, and fed in to a GFP frame.

When this is done, the

interframe gap idle control characters
MAC frame preamble
MAC frame start-of-frame delimiter

are discarded. Everything else is retained, including the QoS and VLAN tagging.

As the maximum payload capacity of the GFP frame is 65536 bytes, this is way in excess of the maximum size of ethernet MAC frames, and even of ethernet jumbo frames, so ethernet MAC frames are easily accommodated within the GFP frames.

website design by ron-t

website hosting by freevirtualservers.com

+ +