The IP over ATM Mailing List Archive by date

[Tim Dwight <0006078043@mcimail.com>]

There is always the option of defining a "service specific convergence
sublayer (SSCS)", which could strip off information made redundant
by the connection-oriented nature of ATM, at the sending side, and
put it back in on the receiving side.  This might include:

     - protocol version    ( 4 bits)
     - header length       ( 4 bits)  // optional
     - type of service     ( 8 bits)  // optional
     - header checksum     (16 bits)
     - destination address (32 bits)  // optional

This list is probably flawed, but it's a rough estimate to get the
ball rolling.  Some of these may never need to be transported over
an ATM VCC, others may be excludable only in some configurations. 
For example, the destination address may be excludable if the VCC 
terminates at a host which does not perform IP routing.  The TOS field
may be excluded if the sender (and anybody whose datagrams may be routed
by the sender) doesn't support it.

In the ATM connection setup, at the SSCS layer of the AAL, we could
negotiate which header fields are to be carried.  Those not carried,
would either have to have default values, value-to-use conveyed in the
signaling, or be re-creatable at the destination.   I favor the latter
2 options more than the first, but list it for completeness.

FYI, the SSCS is a sub-sub-layer of the ATM Adaptation Layer.  AAL
is divided into the convergence sublayer and the segmentation/reassembly
sublayer.  The convergence sublayer is further divided into service-specific
(SSCS) and common part (CPCS).  Most applications use the 'NULL' SSCS;
i.e., they don't use one.  Frame Relay has one, I think.


Tim Dwight
MCI