Conference ozrock::x25_osf

Actually, it's quite logical.

sap-0 receives every packet (that passes the address filter) that has
sap 7e as its destination sap.  It is up to sap-0 to demultiplex these
packets to the appropriate links (using the remote sap and remote
mac address).  (remember, to the datalink, sap-0 is just another user).

Each 802 packet has:

dst-mac-addr src-mac-addr dst-sap src-sap
^^^^^^^^^^^^                                   handled by address filter
             ^^^^^^^^^^^^                      remote mac address
                          ^^^^^^^              local lsap address
                                  ^^^^^^^      remote lsap address

Matt said it, but to extend Matt's reply and give a bit more detail:

> Exactly what is the syntax for creating another llc2 sap link using
> another LSAP. 

create llc2 sap sap-n
set llc2 sap sap-n station csma-cd station csmacd-1 local lsap address 7x

where x is even, e.g. C, A, 8, 6, 4, 2, 0 (or 6E, 6C etc)
(odd LSAP values are 'multicast' if I remember correctly).

will create more SAPs (demultiplexing points for incoming packets)
and

> create llc2 sap sap-0 link link-0
> set llc2 sap sap-0 link link-0 remote mac address aa-00-04-00-22-f8, -
>    remote lsap address xx
	will create more links.

A sap can have multiple links. If it helps you might care to think of a SAP
being like a sync card and a link being an individual port on its parent SAP
(sync card).

In the LAB we commonly use SAPs with local LSAP address of 7e, 7C, 7A etc to
create multiple X.25 point-to-point DTEs between two systems on the same LAN.
This is useful for testing. (I'm not sure its particularly useful in general.)

The wan configurator should create all the NCL for you. Why not use it -
the configurator was created to help avoid the requirement for learning NCL.

    Thanks for the replies. I had in fact managed to get hold of a decnis
    and a VMS system and managed to get it working ok in the office.
    I have successfully set up three LLC2 links between the same two
    machines.
    
    Whilst I am here I will elloborate on why this is required. Maybe there
    is a better way to do this.
    
    	
    The ALPHA unix system is meant to replace an Ultrix system. The Ultrix
    system supports GAP to the decnis. 
    The configuration they have is
    
    ULTRIX------DECNIS 	______switch 1
    (DUNIX)		------switch 2
    		  	------switch 3
    		   w618	------switch 4
    			------switch 5 
                        ------switch 6
    			------switch 7
    			------switch 8
    		
    
    Each port of the DECNIS 618 has a specific DTE class. X25 calls are
    made into the switch (Mobile telephone switches)such that address 1004
    is used for x29 , 1009 is used for FTAM and another address (dont know
    what)is used for x25 programme to programme comms.	
    
	They address each port by using the dte class which ifs fine using
    GAP on Ultrix but as GAP is not supported under DUNIX its a bit more
    problematical. The only way around it is to set up multiple LLC2 links
    to get the specific DTE class which is what I am doing now. 
    However if you can think of a more elegant way to imnplement this I
    would be grateful. 
    I dont have a full understanding of how the switches work which may
    help to give a better solution but typical of most companies this was
    set up a few years ago and all personell have since left.
    
    
    	John Davies

>    Each port of the DECNIS 618 has a specific DTE class. X25 calls are
>    made into the switch (Mobile telephone switches)such that address 1004
>    is used for x29 , 1009 is used for FTAM and another address (dont know
>    what)is used for x25 programme to programme comms.	
>    
>	They address each port by using the dte class which ifs fine using
>    GAP on Ultrix but as GAP is not supported under DUNIX its a bit more
>    problematical. The only way around it is to set up multiple LLC2 links
>    to get the specific DTE class which is what I am doing now. 
>    However if you can think of a more elegant way to imnplement this I
>    would be grateful. 
    	There is often a more elegant way to do this sort of thing that
    have multiple LLC2 links, but other constraints (especially lack of
    knowledge of how all the components work) may make it difficult to
    implement a more elegant solution.
    
    	If I was implementing this and had a free hand and could configure
    the switches appropriately, I would NOT use addresses to distinguish
    switch application classes. I would use the more convential method
    of the protocol id (first 4 bytes of call user data), X.29 has protocol
    id of 01xxxxxx etc. I would configure the DECnis to use the first few
    digits of the destination address to determine which port to send the
    call out; e.g. a destination address of 04xxxx sends the call out over 
    port 4 on w618 #0.
    
    	Maybe the switch uses only certain digits of the destination
    address for application selection. If so, you could add appropriate
    "routing" digits to the addresses.
    
    	Maybe the switch uses protocol id for application selection
    and the 4 digit addresses are for some other convenience which is no
    longer required.
    
    	If the switch MUST see 4 digit addresses for application selection
    then you could use some other call attribute (e.g. local sub address)
    for call switching. (The X25 relay filters would specify a calling
    address. However the form of the calling address, whether or not it
    includes the local dte address is dependent upon x25 protocol dte 
    profile at the call site.) This is a bit less intuitive that using
    destination addresses for call switching, but just as effective.
    
    	Arthur

    Many thanks for that input. I agree with your points but untill I know
    more about the way the switch works its difficult to do much else.
    
    I did consider the subaddress aproach but not sure how the relay client
    would pass the destination dte address on. If there was a mechanism of
    "set host/x25 1004(01) to address port 01 on the decnis  etc but only pass
    on destination dte address 1004 to the switch that would work ok.
    However I am not in a position to try this out - would you believe I
    work in an office with NO alpha technology of any sort available!!!
    The profile between the DECNIS and the switch is ISO8208.
    
    I am due to go to site tomorrow and hopefully the customer will have a
    test switch available. The customer is very nervous about changing
    things on his live network - understandibly!!
    
    	Many thanks for your input..
    
    	John Davies
    

>    I did consider the subaddress aproach but not sure how the relay client
>    would pass the destination dte address on.	
	The relay client should pass on the destination address untouched.

    Many thanks again for your input. It looks as if I need to stick to
    multiple LLC2 links though hopefully we'll be in a position to
    experiment a liitle.
    
    	Thanks
    
    	John Davies