Showing posts with label IEEE. Show all posts
Showing posts with label IEEE. Show all posts

Monday, March 28, 2011

OSI Model : Layer 2 (DLC)

Further to last post on OSI model, let me continue with some information on it. There’re some key parameters that embedded in every layer in one traffic.

osimodel01

Legend :
DA=Destination Address
SA=Source Address
FCS=Frame Check Sequence based on Cyclic Redundancy Check (CRC)
SP=Source Port
DP=Destination Port

Layer 2 frame header Overview

layer2-frameheader

Offset 0-5 and Offset 6-11

ethernet-frames-802.3-snap-1

At layer 2 (Data Link Control Layer)  frame header, source & destination MAC address will be the key parameters ( as shown in the ASCII packet below ). It takes up 6 Bytes for each layer-2 DA & SA and start from offset 0000 in your sniffer’s pcap file.

*( Note : Sniffer will start the capture from Layer-2 DA & SA range, and normally Preamble & 32-bit FCS/CRC will be left )

layer2

Offset 12-13

The following 2 Bytes are allocated for the Ethertype, in the example above shows it’s IP type ( 0x0800 ). More info in IEEE Ethertype. This 2 Bytes will indicate the following layer-3 IP header type.

Beside the example here which is Ethernet Version 2 Frame, there’re also some other 802.3 type e.g. IEEE 802.3 LLC Frame, IEEE 802.3 SNAP Frame & Novell Netware 802.3 RAW Frame.

ethernet-frames-802.3-snap-2

Offset 15-17

If the 2 Bytes following the SA is greater than 05DC HEX ( 1500 Decimal ), the station will identified by Ethernet Version 2. Else, they’re assumed to be a length field. When the following 2 Bytes showing 802.3 length as 38 Decimal ( 26 HEX ) means the following Bytes will be LLC ( Logical Link Control ) header. This sub-layer is acts as an interface between MAC sublayer and the network layer.

Both DSAP ( Destination Source Service Access Point ) & SSAP ( Source Service Access Point ) will be taking up 1 Bytes respectively. This is simply to be the pointer to a memory buffer in the receiving station & of the sending process. Some example will DSAP/SSAP=43, means the following header will be BPDU ( Bridge Protocol Data Unit ).

HEX AA (DEC 170) values are usually employed for the DSAP and SSAP values. Netware uses a HEX 03 in the SNAP Control field and will use the 0x81-37 Ethernet Type value. Usually, the Organizational Code is coded as all 0s (0x00-00-00) and NetWare is no exception.

Offset 17 is simply the Control Byte.

ethernet-frames-802.3-snap-3

Offset 15-17 

The first 3 Bytes i.e. Offset 15-20 is the vendor code. Refers IANA assigned Ethernet-numbers.

Offset 21-22 is the local code, that typically indicate the IEEE Ethertype. This is where the backwards compatibility with Version II Ethernet is implemented.

VLAN (  Optional frame header )

802.1q VLAN tagged frame, is an IEEE standard, uses an additional header in the frames that identifies the VLAN. The 4 Bytes of 802.1q VLAN tag after Layer-2 DA & SA, the Offset 12-15, but it’s optional.

vlan1

VLAN tag takes up 32 bits in the frame header. The first 16 bits, which located at Offset 12-15 which same with the EtherType/Size field in the untagged frame, is the Tag Protocol Identifier (TPID).

The following 2 Bytes ( 16 bits ) is the Tag Control Identifies (TCI). Priority Code Point( (PCP) the 3-bit field which refers to the IEEE802.1p priority. This indicates the frame priority level, from value DEC 0 (Best Effort) to value DEC 7 (Highest). CFI, or known as Canonical Format Identifier, 1 bit field. CFI normally used to identify between Ethernet ( value 0 ) or Token Ring ( value 1 ).

Another 12-bit field specifying the VLAN to which frame belongs. A value of 0 means that the frame does not belong to any VLAN.

In the case of Q-in-Q ( IEEE802.1ad ), another additional 4 Bytes of VLAN tagging is needed in the frame header. The first 4 Bytes which next to SA will representing the S-TAG ( Service Tag ) and the following 4 Bytes will be representing the C-TAG ( Customer Tag ). IN this case, TPID of the outer S-TAG will be using 0x88A8 to identify it as Q-in-Q packet.

vlan-double1 

To be continued….

Related Post : OSI Model Standard

Sunday, August 31, 2008

IEEE 802.11r WiFi roaming standard approved!

The newest Wi-Fi protocol, 802.11r, which has become the de facto "Wireless VoIP standard", is now a published standard of the Institute of Electrical and Electronics Engineers (IEEE) standards board.

ieee802-11-logo On this day, 29th August 2008, the IEEE has formally announced that 802.11r is approved. According to Wikipedia, IEEE 802.11r-2008 or fast BSS transition (FT) is an amendment to the IEEE 802.11 standard to permit continuous connectivity aboard wireless devices in motion, with fast and secure handoffs from one base station to another managed in a seamless manner.

The arrival of 11r is timely. Voice over Wi-Fi is expected to generate increased interest as more dual-mode Wi-Fi/cellular solutions are delivered this year. 802.11f provides a fast enough hand-off for data services, but that can take a second or two if cryptography is being used, so 802.11r was kicked off in 2004 to provide consistent connections. The handoffs take place in less than 50 milliseconds, rather than the several seconds needed to negotiate a secured connection.

wifi

Given the need to integrate with 802.11i security and 802.11e QoS standards, developing a workable standard for fast roaming is challenging. Not surprisingly, 11r defines a complex architecture, though one that is not expected to require forklift upgrades of existing hardware. But getting all the software right will be difficult.

Related readings:

802.11r strengthens wireless voice