Re: AppleTalk over X.25

[[e-mail]]

Chris,

Have you seen draft-ietf-iplpdn-x25_isdn-01.txt?  It just came out a week ago.

/bob

---------------------- Replied Message Body ----------------------
Date: 2-21-92  04:54pm 
From: {[e-mail]}:ugate:3Com
  To: Robert Jeckell:hq:3Com
Subj: Re: AppleTalk over X.25
Return-Path: {[e-mail]}:ugate:3Com
-----------------------
Original header follows:
Received: from gatekeeper.3Com.COM by gw.3Com.COM with SMTP id AA29680
  (5.65c/IDA-1.4.4 for <[e-mail]>); Fri, 21 Feb 1992 
16:54:28 -0800
Return-Path: <[e-mail]>
Received: from apple.com by gatekeeper.3Com.COM with SMTP id AA06069
  (5.65c/IDA-1.4.4-910725 for <[e-mail]>); Fri, 21 Feb 
1992 16:53:39 -0800
Received: by apple.com (5.61/10-Dec-1991-eef)
    id AA05618; Fri, 21 Feb 92 13:01:00 -0800
    for 
Received: from novell.com by apple.com with SMTP (5.61/10-Dec-1991-eef)
    id AA05596; Fri, 21 Feb 92 13:00:48 -0800
    for /usr/lib/sendmail -odq -oi -oQ/usr/spool/mqueue/lists 
[e-mail] apple-ip-list
Received: from na.novell.com by newsun.novell.com (4.1/smi4.1.1.v91190)
    id AA12500; Fri, 21 Feb 92 12:50:28 PST
Received: by na.novell.com (4.1/SMI-4.1)
    id AA15101; Fri, 21 Feb 92 13:01:03 PST
Date: Fri, 21 Feb 92 13:01:03 PST
From: [e-mail] (Christopher Ranch)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: AppleTalk over X.25
Cc: [e-mail], [e-mail]
-----------------------------------------------------------------
Hi Philip,

Thanks for replying.

>    I do not fully understand the problem that you are having with X.25
>protocol ID's. Bits 8 and 7 of the first octet determine who has allocated the
>protocol id.  See recommendation x.29 Page 286 Red Book.
> 
> 
>    There are four possibilites:
> 
>    bit 8 / 7
>        0   0   reserved to CCITT
>        0   1   reserved for national use
>        1   0   reserved for international user bodies (ISO ?)
>        1   1   DTE to DTE
> 
> 
>    Since only CCITT is defined as the group that allocates bits the range 
when
>bit 8 and 7 are zero, it is the only safe range to use.  

    This I do not understand.  Do you mean if I or someone (Apple) went to
    CCITT and asked for a number(s), it would be safe?  Or do you mean it's
    safe to aribtrarily pick one and go with it?

>Perhaps if an
>allocation was given for bits 1/0 and ISO was defined as the ONLY body that
>could use that range you could ask them for a protocol id.  

    Well, this leads back into my thinking.  ISO Tech Report 9577 Annex D
    calls out that 80 in the first byte descriminates SNAP.  Furthermore,
    Annex C specifies 0xCC is used to descriminate IP.  I imagine we could
    ask for an explicit descriminator, and we may get one (with glacial
    speed).

>Bits 0/1 are not
>good since the router could route across national boundries and hence the bits
>have different meanings in different countries.  

    Agreed.  BTW, my notes indicate this is reserved for CCG(DATAPAC).

>alas.... that means that YOU
>need to define a setting for bits 8/7 and the octets following.

    And that's what I'm trying to do, CORRECTLY.  I'm not sure what the
    answer is.  The method I have received the most favorable response
    has been 0x80 08 00 07 80 9B (SNAP discriminator + AppleTalk SNAP
    header).  Runner up is 0x80 9B.  The former may still run into the
    user bytes getting hammered for internal PDN use.  (More on this later)
    
>    Now the problem comes on how to tell some one what you have chosen so that
>they can receive your incoming call.  Since X.25 links are point to point just
>publish your value, and ask people who route to you what their value is.  You
>have 4 octets in a regular call packet to make a unique Protocol ID, and if 
you
>add in the 12 additional bytes of data that follow, 16 octets in all, to form 
a
>unique ID.  

    Right.  I could, but Apple may be the more appropriate party.  I could
    write yet another rfc like 877, but AppleTalk per se is not under
    IAB control (yet).  I'd love it if Apple would publish something
    much like what they did for FDDITalk.

>I am not aware of ANY PTT that drops the data portion of a call packet.  

    I have been told that some Canadian PTT's do it.  I'm still trying
    to nail this one down.
    
>I would suggest the following ID
> 
>    fefe fdfd dfdf efef (in hex) followed by in US Ascii the following 12
>characters. "Apple Router"

    Holy cow!  I can see that you picked this out of your hat, hoping
    that the chances of someone else picking the same one is about nil.
    I'll add it to my list.  Comments anyone?

>regards,
> 
>Philip

    Thanks again for responding,

    Chris