The IP over ATM Mailing List Archive by date

[bryang@eng.adaptec.com (Bryan Gleeson)]

Grenville et al.

>>>As such I'd like to propose that we define a new SSCS 
>>>that can be used with AAL5 to provide echo cancelling,
>>>lets call it the EC-SSCS.
>
>My first response is that this is quite an elegant idea.
>Would you consider writing up a contribution to the Forum
>for this, or should the IETF simply describe its
>functionality, position in the data path, and call
>it a user supplied SSCS?
>

(better late than never ...)

Actually I think a modified version of the
proposal, which did not put the functionality in the
SSCS layer but instead defined a new mapping of
AAL5-user PDUs onto AAL5-UNITDATA primitives might
might be a quicker way forward. This is because
if it is an SSCS you need a codepoint to
signal it, and this cannot be assigned by the 
ATM Forum, instead it needs to be assigned by the
ITU. This would take too long, and would also be
a change, even if a small one, to pure UNI 3.x
signalling. Using a null SSCS, but defining the
use of the UU parameter of the AAL5-UNITDATA
primitive in the same manner as was previously
described for the CPCS-SDU gives you basically
the same thing (i.e. defines the length of an
echo-id prepended to the AAL5-user PDU), but without
the ability to explicitly signal its use in a SETUP.
Instead the rules of the AAL5-user protocol, in our
case IP/ATM, would determine the use or non-use on
any particular VCC. Anyway right now it is just one option 
among many and I think the best way to proceed is to 
reissue the I-D on the new encaps with this as an option, 
and get the WG, or at least that part of the WG that
sees merit in supporting the use of an MCS, to
pick one, so to that end I hope to issue an updated
version in a few days.

I think that just about every point that could be made
in this debate have been made lots of times. It is clear
that there is a demand for an approach which allows an
MCS to be used. It is also clear that nobody will ever be
forced to use one if they don't want to. If we mandate 
that every node must be able to support the existing
encaps only, as an option, then it will be quite possible
to build and deploy products that are totally unaware
of a new encaps and the concept of an MCS, if someone
so chooses. If anyone wishes to build products that
use an MCS and a new encaps that is their choice, but
it is not going to break anything. 

It is also important to remember that we are trying to 
specify a protocol here, not build a network. I believe 
that full-mesh and MCS are necessary building blocks and 
should be treated as such. The pros and cons of each should 
be described, but it is not the job of this WG to make value 
judgements on which one is "better" or "recommended". This 
decision can only be made in the context of specific information
on numbers and types of hosts and routers, and the types
of traffic patterns in use. As such I am totally against
separating out MCS from the main portion of the spec and
treating it as some form of special case. I believe it is
quite within the capabilities of this WG to write a spec
where the mesh and server approaches can live in
peaceful co-existence. In fact most of this is already
there in ipmc04 - all that remains is to pick an encapsulation
and define the rules as to when it is used. 

Bryan