Browse Prior Art Database

ENCRYPTION/COMPRESSION SYNCHRONIZATION FOR LLC PROTOCOLS

IP.com Disclosure Number: IPCOM000008724D
Original Publication Date: 1998-Jun-01
Included in the Prior Art Database: 2002-Jul-05
Document File: 5 page(s) / 249K

Publishing Venue

Motorola

Related People

Jay Dawdy: AUTHOR

Abstract

Due to the security and bandwidth concerns that exist for data communications users today, new systems that support packet data, must employ some sort of encryption and or compression of data packets. These packets are usually transmitted between endpoints using a reliable L2 protocol.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 29% of the total text.

Page 1 of 5

0 M

MOTOROLA Technicul Developments

ENCRYPTION/COMPRESSION SYNCHRONIZATION

FOR LLC PROTOCOLS

by Jay Dawdy

INTRODUCTION

  Due to the security and bandwidth concerns that exist for data communications users today, new systems that support packet data, must employ some sort of encryption and or compression of data packets. These packets are usually transmitted between endpoints using a reliable L2 protocol.

  Commonly, a standardized or "off the shelf' L2 protocol is used with little and many times no modi- fications. This saves on development time but unfortunately separates reliable data transfer from the point of compression/encryption. This creates some new problems to solve.

  The primary problem is that compressed/ encrypted packets need to have reliable data transfer from the point where encryption/compression of a packet begins to where the packet is finally uncom- pressed/decrypted. With current methods, point to point reliability ends at L2 and requires L3 to do the additional work of ensuring synchronization between the L3 endpoints. This is commonly accomplished by a combination of monitoring L2 link establishments and L3 resynchronization

messages. This solution has two inherent problems.

1) Both transmit and receive compression tables must be resynchronized when a L2 link estab- lishment occurs because:

a) A given L2 endpoint can only know with any certainty if it has lost data from its transmit, window. The receive window is always uncertain and therefore the receive table must always be resynchronized.

b) Even if the local L2 loses no transmit data between it and its peer, this does not guaran- tee that data was not lost between L2 and L3 at the peer; therefore, the transmit table must

always be resynchronized.

All of this leads to unnecessary resynchronization.

2) Problem 1 could be avoided by re-establishing the link and then having L3 send a resync message stating whether or not resynchronization is required. This message would have to be sent reliably and it would have to be sent after every re-establishment even if resynchronization is not required. This is because L3 would have no way of knowing when NOT to expect the resync mes- sage. The main problem with this solution that at least one additional message has to be sent in both directions upon every re-establishment. This additional overhead is very undesirable in bandwidth limited environments such as wireless.

SOLUTION

  The solution discussed here is based upon making modifications to the information contained in chapters 3 and 4 of Link Access Protocol-iDEN Version D00.00.03.

  This solution provides a means to make LAPi aware of the L3 encryption state in addition to its own link state. This information is conveyed to and received from the L2 peer upon L2 link establishment and normal terminations. This results in a protocol with the following two features:

I) Resynchronization need only be done for the tables that are required since the peer syn- chronization stat...