Re: RFC 1381 anomolies?

[PHILIPPE ROGER <[e-mail]>]

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:     [e-mail])