Re: RFC 1381 anomolies?
PHILIPPE ROGER <email@example.com> Wed, 08 September 1993 00:09 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16919;
7 Sep 93 20:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16915; 7 Sep 93 20:09 EDT
Received: from dg-rtp.rtp.dg.com by CNRI.Reston.VA.US id aa23687; 7 Sep 93 20:09 EDT
Received: from relay2.UU.NET by dg-rtp.dg.com (5.4.1/dg-rtp-proto) id AA02509; Tue, 7 Sep 1993 19:49:09 -0400
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05499; Tue, 7 Sep 93 19:49:06 -0400
Received: from flowpnt.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 194713.9279; Tue, 7 Sep 1993 19:47:13 EDT
Received: by flowpnt (4.1/SMI-4.1) id AA01538; Tue, 7 Sep 93 16:43:08 PDT
Date: Tue, 7 Sep 93 16:43:08 PDT
From: PHILIPPE ROGER <firstname.lastname@example.org>
Subject: Re: RFC 1381 anomolies?
Sidnie, Let me try to clarify a few of these issues: > First of all, I have the definitive 1984 CCITT X.25 Recommendation, > as well as 1992 Recommendations expanding on the original. It is > my impression that vendors have built to CCITT (now ITU-TSS) > specifications, NOT ISO specs. I have vendor manuals that agree with > the CCITT specs, and contradict RFC 1381. > > I do not have the ISO 8885 document, and do not know whether it > indeed varies as much from the CCITT originals as the RFC would > imply. First of all, I would say that we, as an X.25 portable software vendor, support both the CCITT and ISO specs although most LAPB uses are to connect to public data networks (which follow the CCITT spec with some degree of interpretation). The actual ISO document that specifies LAPB is ISO 7776. It is complemented by the Data Link Service definition (ISO 8886) and HDLC classes of procedures (ISO 7809, which mentions the use for XID for negotiation purposes). ISO 8885 defines what protocol elements can be carried within XID frames (for negotiation purposes, and is referenced from ISO 7809, Addendum 2: description of OPTIONAL options. Also, the ISO 7776 spec defines the DTE behavior while the CCITT spec defines the DTE/DCE interface behavior. As such it also supports DTE to DTE communication (i.e. negotiated role). The ISO spec is ONLY defined for synchronous duplex links. Yet there might be other uses for LAPB than just provide the Data Link layer for X.25 or ISO 8208 on the synchronous duplex link. Take the example of half-duplex (CCITT T.71) switched lines (X.32). My feeling is: as we are at defining a spec for managing "LAPB", we might as well allow any legitimate use of LAPB (not strictly CCITT X.25 or ISO) to also be managed with this spec. Granted, they are lots of cases where all that stuff is not needed and wether it should be made optional in the LAPB MIB implementation (or left out) is another debate. > 1. lapbAdmnTransmitKWindowSize and lapbAdmnReceiveKWindow size. > (Similarly for Oper). CCITT states that these must be the same, and > MUST be preset by mutual agreement. > > The window sizes at the PACKET layer can differ, and can be negotiated > with the service provider through facilities negotiation, if the > service provider supports this. > > Also, the first of these definitions refers to "this DTE". > The interface can play the role of DTE or DCE. You are right saying that the window size must be mutually agreed upon (at the frame level, i.e. LAPB) and that usually they are the same for both ways of transmission. However this implies a leased line type of access between a DTE and a public network acting as a DCE. Please note, that the CCITT spec addresses ONLY the DTE/DCE interface in a public network. In the more general case, the type of link may also be a switched line and the DCE may not be provided by a public packet switched network. In such case, where it is not known in advance which device is acting as a DTE and which is acting as a DCE a role negotiation phase takes place (dxe) and the operationnal parameters are determined, with XID exchanges. > 2. lapbAdmnReceiveFrameSize. The default value is set to 4500 > octets. According to RFC1356, this is an illegal size. 1600 octets > is the maximum, and anything bigger will automatically be decreased. I think that 4500 is probably not a good value, neither is 1600. RFC1356 mentions 1600 as being the "frame" size ABOVE the X.25 packet layer (which may concatenate several lower layer frames into an IP datagram). Also RFC1356 implies the use of the X.25 packet layer, which again might not be the only use for LAPB (consider using LAPB instead of transparent HDLC for satellite links for instance). The reason why I think 4500 is not good value either is: 4500 not enough to account for a 4096 Packet Layer Data packet, 3 or 4 bytes of PLP header, 2 or 3 bytes of LAPB header and 2 bytes of CRC. The sum I just described is the definition for N1. The only sure thing is that N1 must not be smaller than 1080 bits (i.e. 2 + 3 + 128 + 2 = 135 bytes). For the rest, N1 is open and must be either a predetermined value agreed upon between a DTE and a DCE, or must be negotiated (in the case of switched lines, where the DTE/DCE role is unknown upon establishment of the physical layer). > 3. lapbAdmnT4IdleTimer. This does not appear in any of my standards > documents. I assume that this is a locally configured timer that I > use to say "Hmmm, nothing going on for this link, let's close it and > save our resources." If this is what it is, it should be explained, > and an official sounding protocol timer name like T4 should not be > assigned. Something like minIdleTime would match what vendors call > this. There is an actual reference to T4 in ISO 7776. It is defined as "a system parameter which represents the maximum time a DTE will allow without frames being exchanged on the data link". Which means, when that timer expires, the link is considered broken, which clears ALL the packet layer virtual circuits. The link may or may not be restarted (at the DTE convenience) by issuing a SABM frame. This is different from the idling timer you are refering to, which is the time after which an idle packet layer virtual circuit may be closed, as explained in RFC1536. The T4 timer is not described in the CCITT spec, nor is the checkpoint procedure (which consists in regularly sending RR commands with the P bit set, expecting RR responses with the F bit set). The T4 timer together with the checkpoint procedure is the only means by which a failure of the remote equipment (while no traffic is pending acknowledgement) is detected, without the assistance of the physical layer. It is self contained the data link layer. On the other hand CCITT, relies on hardware control signals like CTS or CD to report the failure of an interface. LAPB being more general than what the CCITT spec says, there might be cases where the failure of the remote equipment cannot be detected by the physical layer... > 4. I don't have an XID in ANY of my standards documents, nor is it > configured in my vendor manuals. Since it looks like IP addresses > and port numbers are involved, it should be in some RFC. Can > you tell me where this comes from? Do any vendors support this? > > You also state that "dxe" can be used when the station type has not > yet been negotiated using XID. But the lapbXidTable contains no > parameter that would define this role. How is the role defined > during XID? Again, who supports this in a product? XID exchange is described generally in ISO 8885. XID's use for identification purposes (and the corresponding billing!) is described in X.32. The DTE to DTE connection (also known as DXE), where the final DTE/DCE role is negotiated depends on which sides actually activates the physical layer. This is defined in CCITT T.70 and mentionned in X.32 For example, when a DTE dials out, the receiving end gets a RING indicator signal, which initiates the physical layer at the remote. This is reported to the remote data link layer with a PH_ACTIVATE primitive and it becomes a DCE. More on that in CCITT X.211 (Physical Service Definition of Open Systems Interconnection For CCITT Application) and CCITT X.212 (Data Link Service Definition for Open Systems Interconnection For CCITT Applications), specially Appendix III. In all the above I am refering to the set of CCITT blue books (1988). In conclusion, I would say that it is true that all this stuff is quite messy and most of the time useless. Is it enough to bar people from implementing it (that is, if they REALLY want) ? I think not. Being responsible for setting open standards, the CCITT, ISO and IETF should all take into account those weird cases. I am not saying that everybody should actually implement it: if your LAPB implementation does not support XID or the DXE mode, that's fine. Then, simply ignore this part of the MIB and don't let a management entity change the role to 'dxe'. I hope that I gave my ten cents worth. Philippe Roger (FlowPoint Corp: roger@flowpnt.UUNET.UU.NET)