The IP over ATM Mailing List Archive by date

[laubach@terra.com21.com (Mark Laubach)]

I've just submitted an 80 page protocol contribution to IEEE 802.14
working group for an ATM-based MAC over hybrid fiber-coax cable TV
networks.  While this doesn't directly apply here, the exercise has
drummed in the notion about protocol layering; that is if you don't present
a procotol that is pcl (politically correctly layered) the various layer
pundits will chew you to bits and you'll never get anything through
the voting and approval process......

W.r.t. TCP checksum avoidance.  This is above the IP layer and as such,
probably  better done with at an IP signalling layer.  This working group
is IP over ATM and not TCP over IP over ATM.  This WG works on the bottom
part of the problem space.

W.r.t. IP header compression.  We deliberately opted to use LLC/SNAP
encapsulation as the default for our IP over ATM work.  That means we
terminate IP above the LLC entity and not in the service specific
convergence (SSCS) layer  of AAL5. It would probably be best to handle
IP header compression as a separate LLC/SNAP codepoint and/or use some
form of IP signaling than to try to munge the layers more than we already
have.  Also a side issue, correct me if I am wrong, but seem to remember
from our FR-SSCS discussion awhile ago with the signalling draft that the
SSCS is non-negotiable in the ATM UNI 3.1 call setup process and if so,
we probably don't want add more complication to what we are doing already
in RFC1755.

Mark

At 1:13 10/21/95, Tim Dwight wrote:
>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