I was wrong.

I looked it up last night and there is a seq. number in the control field of
LAPB, HDLC, and LABD.  Both, the sending and receiving stations must keep
the same seq. numbers when transmitting, but I cannot find anything on
retransmission at that layer.  But I asked an old IBM guy I used to work
with and he said that SDLC and all the related layer two protocols do
require retrans when bad packets are found or missing.  So I would assume
that LAPD layer two is reliable.  And as everyone else said, the SS7
signalling (Q.931) is just control and status messages over D channel.

And B channel is a different retrans technique, based upon the higher layer
protocols it carries.  If an ISDN frame gets corrupt, both channels will be
retransmitted, but by differnt methods.  So ISDN D channel is inherently
reliable at layer two and B channel is reliable only if that higher layer
protocol is.


""Peter Whittle""  wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I sent this to Priscilla on the topic and she suggested that the group
> might benefit from my response, so here it is.
>
> Priscilla,
>
> I think that you may find it helpful to separate end - to - end data
> transfer from signalling.
>
> Very few L2 protocols offer error correction. The modern approach is to
> require the L1 transmission to provide intrinsically reliable
> communication and hence it is a waste of bandwidth to implement error
> correction both on hop by hop and end to end basis as per X.25.
> Modern WAN digital transmission systems are designed to offer
> transmission error rates of fewer than 1 bit error in 10^9 bits.
>
> On Telco Wan links it is common on this side of the pond to require
> transmission media to offer error rates better than 1 in 10^9 and often
> 1 in 10^11. Indeed the commissioning tests call for fewer than 1 error
> in a 20 minute period on a basic E3 (34 Mb) link and fewer than 1 error
> in 24 hours on International links prior to acceptance from Transmission
> into Networks for operational trunks. That is not to say that links may
> not degrade but if the error rates became worse than 1 in 10^9 it would
> be time for Network operations to call 'holes & poles' (Transmission) to
> fix it.
>
> The fundamental assumptions in both Frame Relay and ATM is that they are
> running over intrinsically reliable transmission media. The low error
> rates being achieved either by correctly engineered transmission paths
> or by the use of significant forward error correction built in to the
> transmission equipment.
>
> ATM, and Frame Relay, implement error correction, or more precisely re-
> transmission in the interface to the signalling protocols. ISDN relies
> on the hop by hop error correction offered by LAPD.  However, they tend
> to leave the issue of payload error correction to any high level end-to-
> end protocols being run on top of these L2 Datalinks.
>
> ATM offers no direct protection of payload content, the HEC only
> protects the ATM header. However, some AALs do offer protection if not
> correction of the payload. Even AAL5 - most common for IP has a check
> polynomial (CRC32) to protect the CS PDU. It performs error detection
> but not correction. In the case of Q.2931, SAAL (version of AAL5 to
> carry signalling) will detect faulty PDUs.  If you want to look at ATM
> signalling take a look at Q.2931 essentially an enhanced and extended
> version of narrow band ISDN Q.931 signalling.  Take a look at the ATM
> forum website. www.atmforum.org
>
>
> Frame Relay has Frame Check Sequence that again will detect faulty
> frames. (Incidentally Carrier Switches tend to drop frames with a faulty
> FCS). Incidentally Frame Relay is sometimes known as LAPF. Take a look
> at the frame relay forum web site. www.frforum.org there are some good
> white papers and the frf's recommendations that you can download.
>
>
> ISDN B channel - is a 64 Kbit clear channel and the network makes no
> assumptions about the contents. It could be any number of data formats
> or indeed it could be 64 K G.711 PCM voice. The most ubiquitous use of
> data over ISDN is to encapsulate it in PPP which is intrinsically multi-
> protocol. However, it is also possible to use HDLC, X.25, Frame Relay,
> or any number of specialist protocols. D channel usage is somewhat
> different. L2 on D channel is Q.921 (as you say also known as LAPD). It
> is perhaps worth pointing out the ISDN signalling is NOT an end to end
> protocol! ISDN signalling only traverses the single hop to the
> signalling processor on the nearest switch.  This signalling processor
> then signals to the signalling processor of the next switch and finally
> the signalling processor on the last switch communicates with the far
> end CPE. In Public Carrier Networks the signalling between switches is
> normally SS7 or C7 as it is sometimes known.  The D channel is normally
> used for signalling but in the case of Basic Rate may also be used for
> permanently on low speed data services such as X.31 (9k6 X.25 in D
> channel, which uses LAPD for L2 and normal X.25 L3)
>
> Q.931 is used on public networks to communicate with the Carrier's CO
> switch and is fairly primitive in its feature set. QSIG is essentially a
> superset of Q.931 used on private telephony networks to signal between
> PABXs and offers an enhanced set of features such as 'camp on
> extension', 'ring back when free', redirect calls etc.
>
>
> X.25 has hop by hop error detection and correction in L2 - LAPB and also
> end to end in the L3. Sometimes known as 'belt and braces' or 'The Pony
> Express' of data communications. 'We get the data through, eventually,
> no matter how crummy the analogue link is!'
>
> Not being of IBM extraction I am not in a position to comment on SDLC or
> Bisync.
>
> I hope that this helps
>
> Peter
>
> --
> Peter Whittle




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=27694&t=27568
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to