In article , Howard C. Berkowitz
writes
>>Dear Guru's,
>>Have seen that in the frame format of ISDN, Frame Relay and HDLC, there are
>>two bits of Extended Address field. I would like to know why two fields
when
>>one can suffice?
>>With my limited knowledge, I can understand that may be when (in case of
FR)
>>the DLCI bits increase beyond 10 bits, then might require another frame to
>>take along the extra bits. This is purely my understanding, nothing to do
>>with any whitepaper or site. Have I hit the taget?
>>Moreover I was thinking why do we need more than 10 bits of DLCI? When will
>>we need it?
>>Do throw some light here, please.
>>Amit
>
>You ask a question here that digs deeply into why protocols are
>designed the way they are. First, it's worth remembering that
>protocol standards developed by ISO, ITU and CCITT usually are
>developed on paper long before there are any prototypes or products.
>In contrast, IETF standards require at least two running
>implementations before you can move to the second of three levels of
>standardization.
>
>So, without real-world modifiers about how the technology will be
>used, ISO/ITU standards (including ISDN, Frame, and HDLC), are rather
>consciously designed so there can be extensions later. You have
>correctly interpreted why the EA bit is there -- it's for extending
>the field length.
>
HDLC is a standard (the real HDLC not Cisco's version) and is the basis
of most layer 2 protocols, X.25 LAPB, Q.922 Frame Relay, ISDN Q.921
LAPD, V42bis (LAPM), PPP and various vendor specific flavours of HDLC.
Perhaps a brief look into HDLC may help.
HDLC frame layout
-----------------
flag ... flag | HDLC hdr | payload | FCS | flag ...
The flags separate the HDLC frames and identify the end of a frame.
They are hex 7E, ie 6 consecutive '1's. This pattern is illegal in a
frame and the transmitting chip set will break a pattern of 5
consecutive '1's by inserting an additional '0' bit (zero bit stuffing).
The receiving chip set will delete the '0' following 5 consecutive '1's,
so it is transparent to any higher layers.
The flags force clock transitions and hence help to maintain bit clock
synchronisation between frames. There must be at least 1 flag between
frames and there may be any number. When flags are nolonger sent it is
assumed that a new frame is beginning.
FCS (Frame Check Sequence) is some type of polynomial to enable the
detection of faulty frames. (Most modern L2 protocols only detect faulty
frames and then discard them, some of the legacy protocols X.25 LAPB,
perform error recovery at L2.)
The payload is what you wish to carry eg IP, IPX etc and normally has
some form of wrapper round it.
Now to the main part the HDLC header field. This is normally split into
2 sub parts, the address field and the control field.
By default an HDLC header address field is a single octet. As Howard
says standards bodies like protocols to be extendable. The HDLC address
field is extendable to as many octets as you like! The protocol says
that if the ea bit (least significant bit) is a '0' then the address
field extends into at least another octet. So if you want a 4 octet
address field the ea bit in the first 3 octets is a '0' ("more to
follow") and in the final, 4th octet, the ea bit is a '1'. ("END OF THE
LINE") In other words you just daisy chain the extensions to the address
field to as many octets as you need.
So for ISDN Q.921 and normal Q.922 Frame Relay it may seem as a waste to
have 2 ea bits just to say that we have a 2 octet address field. But at
least it is extendable. I have heard rumours of early IP developers
saying 'you must be nuts 32 bit IP addresses, we only ever need a
handful of networks with a couple of dozen hosts'...
So HDLC has and ea bit in every address octet!
Frame Relay supports 2, 3 & 4 octet header fields, controlled by the ea
bits in each octet. Yes in the Cisco world you are most unlikely to
come across Frame Relay frames with anything other than 2 octet address
fields.
In CPE land 1023 dlci per port may seem excessive but just think of the
poor old Frame Relay switches in the Frame cloud.
Let us suppose that a Frame Relay edge switch has say 500 customers
hanging off it, each with moderately large networks say needing 64 dlci
per customer and the Telco wants to switch these onto a single common
trunk. 64 x 500 dlci on the trunk! Oops! You can't do that!
Remember a dlci only has to be unique on a particular port, but when all
those dlcis are switched onto a single trunk, they must still be unique.
Hence the need for 3 and 4 octet frame header fields. You may come
across them on the NNI (Network - Network Interface) between switches,
within the Frame Relay cloud. However, in reality most Telco Frame
Relay networks run Frame Relay out to the customers and then use some
proprietary protocol in the core between the edge switches. So the most
likely place to find 3 and 4 octet Frame Relay headers would be on the
Inter Carrier Interface between 2 different Frame Relay networks.
This is really core Telco land and not Cisco CPE land.
The control sub field is not used for Frame Relay. Frame Relay has a
very simplistic approach to frame handling. All frames are un-numbered
information frames. Frame Relay has no need of a control field!
If you look a little closer at Frame Relay encapsulations to carry L3
you will see that they all start with the magic 03 as the first octet of
what should be the payload. This makes them compatible with the rest of
the HDLC based protocols. The HDLC header contains 2 sub fields the
Address (this is used by Frame Relay for the frame header, containing
dlci, DE bit, FECN bit, BECN bit, and a C/R bit) and the Control. An
HDLC header Control field of 03 is an un-numbered information frame.
I hope that this helps
Peter
>And you are also quite correct that no one has found a real reason to
>use more than 10 bits. But the capability is there if it's needed.
>We have a long history of running out of space in protocol fields --
>witness IPv4 addressess.
>
>Another good comparison is the difference in detailed protocol
>message design in OSPF and ISIS. OSPF is designed for processing
>efficiency. You will find that most important fields are aligned on
>32-bit boundaries. There's a lot of bit-flag level encoding.
>
>ISIS, however, was designed for extensibility. Its optional fields
>are in variable-length Type-Length-Value constructs, so it's much
>easier to add features than it is to OSPF.
>
>Again, rememeber when these protocol were designed, conditions
>weren't the same as they are today. Processors were much slower.
>html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
--
Peter Whittle
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=11619&t=11035
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
