art@ACC.ARPA.UUCP (02/11/87)
I'd like to solicit any input anyone might have... I'm going to be defining an X.25 service interface and am dealing with specifying binding information for incoming calls. Unfortunately X.25 does not have any clean, well defined mechanism for this. What I want is for a user to allocate a "Service Access Point" (SAP) and then specify information for a binding filter. When an incoming call matches the binding filter, an Indication of Incoming Call will be passed to the user for his acceptance or rejection. Issues: Protocol Identification - The first byte of call user data is typically used to identify a specific upper layer protocol. But call user data is optional and CCITT PAD protocols use a four byte protocol identifier and other protocols (such as DoD IP) use just one. What about information in the rest of the user data field? Destination Address - The format of the X.25 address which is received is essentially controlled by the network provider under X.121 guidelines. Some networks support "sub-address" bits which are not interpreted by the network, others do not. Some networks support more than one address format (typically for local vs internetwork calls). Source Address - Should the service interface filter on remote host identification? Facilities - Should the service interface be involved in which facilities are allowed? What about negotiated Facilities (such as packet size)? Anyone interested in this stuff??? Art Berggreen <Art@ACC.ARPA> ------
haas%utah-gr@UTAH-CS.ARPA.UUCP (02/11/87)
In article <8702110223.AA26394@ucbvax.Berkeley.EDU>, art@ACC.ARPA writes: > > I'm going to be defining an X.25 service interface and am dealing > with specifying binding information for incoming calls. Unfortunately > X.25 does not have any clean, well defined mechanism for this. > ... > Protocol Identification - The first byte of call user data is typically > used to identify a specific upper layer protocol. But call user > data is optional and CCITT PAD protocols use a four byte protocol > ... Actually the situation is manageable. My X.25 implementation for the DEC-20 (RIP) checked that the Call User Data field was present and started appropriately before accepting the call. This seems to be a reasonable general strategy. You won't find many PADs supporting X.29 that don't say so in their Call User Data field. > Destination Address - The format of the X.25 address which is received > is essentially controlled by the network provider under X.121 guidelines. > Some networks support "sub-address" bits which are not interpreted by > the network, others do not. Some networks support more than one address > format (typically for local vs internetwork calls). > Yup. Some networks let the caller set the sub-address bits, and some service organizations (like STN for example) select a service based on these bits. > > Source Address - Should the service interface filter on remote host > identification? > You WILL find PADs that don't provide a source address, and there is nothing in general to stop somebody from spoofing source address, unless you happen to be hooked to a particular network that verifies this field. In particular our local PDN, ComWest, uses Dynapac PADs that leave out source address. > > Facilities - Should the service interface be involved in which facilities > are allowed? What about negotiated Facilities (such as packet size)? > Well, at some level you need to negotiate facilities based on what service is requested. Larger window sizes have advantages for interactive use, and larger packet sizes have advantages for file transfer. Plus, your accountant probably has an interest in who pays for the call, which is a facility! > > Anyone interested in this stuff??? > > Art Berggreen > <Art@ACC.ARPA> Me for one! Walt Haas <haas@utah-cs.arpa> ...utah-cs!haas