Cell Relay Archive

[Pranab Chakraborty <sanu@rocketmail.com>]

Hi Greg,

> I would like an opinion on the correct
interpretation of the LANE 1.0
> standard with regard to how the LECS should respond
in the following
> circumstance.
> 
> A LEC with SOURCE-ATM-ADDRESS S and
SOURCE-LAN-DESTINATION MAC1 is already
> joined to ELAN E.
> 
> A configure request is then sent to the LECS with
SOURCE-ATM-ADDRESS S,
> SOURCE-LAN-DESTINATION MAC2 and ELAN-NAME E.  
> 
> From 5.4.2.6, I believe it would be illegal for the
> LES for ELAN E to
> accept a join request for a LEC with >
SOURCE-ATM-ADDRESS S and
> SOURCE-LAN-DESTINATION MAC2 at the same time it >
already has that
> SOURCE-ATM-ADDRESS already joined with a different
> SOURCE-LAN-DESTINATION
> (MAC1).  

Correct, LES MUST reject the join request of the
second LEC. In other words, the primary ATM address
of an LEC MUST be unique and that address "MUST be
used to establish the LE Client's Control Direct and
Multicast VCCs, and MUST be specified as the
SOURCE-ATM-ADDRESS in the client's LE_JOIN_REQUESTs"
(5.1.1)

> My assumption here is that different >
SOURCE-LAN-DESTINATIONs for
> the the same SOURCE-ATM-ADDRESS represent different 
> LEC instantiations with
> respect to a join request, and therefore these
cannot > be the subject of
> separate join requests to the same ELAN
concurrently > (note this is
> different to subsequently using the registration > 
> protocol to register
> multiple local or non-local MAC addresses against a 
> joined LEC).  

"LE Clients MUST NOT register non-local LAN
destinations (C27)." (6.1.1.2)

> However, my interpretation of the standard is that
> the LECS itself should
> *NOT* reject the *configure* request above, even if
a > subsequent join
> attempt using those parameters would fail. 
>

Yes, in LANE v1 there is no concept of communication
between LECS and LES. So, the LECS does not have any
hint about whether the subsequent join request would
succeed or not (it does not have any specified way of
getting the join or registration database).

> In 5.3.2 the standard says "The LE Configuration 
> Server uses the
> information provided in the LE_CONFIGURE_REQUEST to 
> generate an
> LE_CONFIGURE_RESPONSE.  This response may indicate 
> success or failure
> depending on whether the prospective LE Client is
to > be allowed to attempt
> to join an LE Server".  
> 
> To me, the key words are "allowed to attempt to 
> join", which is not the
> same as "allowed to join"!!  That is, as far as I
can > tell, the LECS should
> make its decisions totally based on its local 
> configuration database,
> independently of the current state of the LESs in
the > network.  So as long
> as the LECS configuration database otherwise
permits > a LEC with
> SOURCE-ATM-ADDRESS S and SOURCE-LAN-DESTINATION
MAC2 > to belong to ELAN E,
> my interpretation is that the LECS should respond 
> with success status and
> the LES address and other configuration parameters 
> for  ELAN E.  It would
> then be up to the LES to reject a subsequent join 
> request if it believed
> the requested parameters were in conflict with an 
> already-joined LEC.
> 

As far as I understand, the LECS (even if it
maintains a successfully configured LECs database)
should not reject any request with duplicate source
ATM address, since the previous join request might
not have been successful for some other reason (or
the first LEC might have decided to disconnect itself
from the present ELAN). So the present joining would
eventually succeed and denying this possiblity in the
configuration phase means unnecessary prohibition of
service.

Regds,
Pranab

(Pranab Chakraborty
 Dynamic Digital Technology, Calcutta
 email : pranab@dtix.com
         sanu@rocketmail.com)
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com