The IP over ATM Mailing List Archive by date

[Andrew Smith <asmith@Baynetworks.COM>]

You could even put the "echo ID" into the AAL5 CPCS-SDU
in some of those unused bits near the end and you wouldn't
even have to change your hardware. 

There you have it: AAL5-1/2 :-)

Andrew


********************************************************************************
Andrew Smith					TEL:	+1 408 764 1574
Technology Synergy Unit				FAX:	+1 408 988 5525
Bay Networks, Inc.				E-m:	asmith@baynetworks.com
Santa Clara, CA
********************************************************************************



> From atmpost@matmos.hpl.hp.com Fri May  5 14:38:06 1995
> Date: Fri, 5 May 95 14:13:44 PDT
> From: bryang@eng.adaptec.com (Bryan Gleeson)
> To: ip-atm@matmos.hpl.hp.com
> Subject: Encapsulation - a different approach
> Content-Length: 2256
> 
> 
> One of the 'features' of using ATM and broadcast / multicast
> servers is the need for detecting your own transmissions and
> then discarding them, what I'll term echo cancelling. This
> is an ATM phenomenon and is independent of any particular 
> layer 2 or layer 3 protocols that may be running over it.
> As such I was thinking that it may be better handled by
> an ATM / AAL layer function than by disturbing existing
> layer 2/3 encapsulations.
> 
> 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.
> 
> On Transmit:
> AAL-SDUs are passed to the EC-SSCS. With IP/ATM these
> AAL-SDUs will be LLC SNAP encapsulated packets,
> or just IP or ARP packets if VC-MUXing was used.
> When a VC is established the EC-SSCS is passed,
> through some local mechanism, a number which
> is used for echo detection (e.g. a Cluster
> Member ID if a MARS is used). Let's call this the ECID, 
> and the AAL-SDU the ECPACKET. The EC-SSCS constructs an 
> EC-SSCS-PDU which is a concatenation of the ECID and the 
> ECPACKET. This is passed as a CPCS-SDU to the Common Part 
> layer. The UU byte is set to the length of the ECID.
> 
> On Receive:
> The CPCS layer gets an incoming CPCS-PDU and passes
> up a CPCS-SDU to its user, which for that VC will be
> the EC-SSCS. The EC-SSCS examines the UU byte to  
> determine the length and value of the ECID. It compares 
> this with its own ECID, and if there is a match it discards 
> the PDU. If not it passes up the ECPACKET as an AAL-SDU to 
> its user.
> 
> A new code point needs to be allocated to specify the
> use of the EC-SSCS in the AAL5 parameters IE, used
> in SETUP and CONNECT messages.
> 
> So in brief there is still an encapsulation, but it
> is at a logically different layer, and some parts could
> be implemented in hardware. It doesn't affect any existing
> encapsulations and doesn't need a new OUI or PID. Each
> layer 2 or layer 3 protocol would have its own semantics
> and scope for the ECID. For IPv4/ATM perhaps a 4 byte
> ECID could be used, set to the address of the IP interface.
> This could remove the need for the MARS to manage and
> distribute the Cluster Member Ids.
> 
> Comments ?
> 
> Bryan Gleeson,
> Adaptec.
> 
> (I'll be away for a week so I won't be responding to any
> replies till I get back)
>