Held Monday, April 3, 2000
Overview
Today we conclude our study of the data-link layer with
a consideration of one of the recent data-link protocols,
ATM.
Notes
- Expect assignment 6 on Wednesday.
- On Wednesday at noon, there's a brown bag film on The Origins
of ATM
- Read chapter 4 of Peterson and Davie for Wednesday.
Contents
Summary
- These notes will be fairly quick since you can learn more from
the video on Wednesday.
- One of the more recent (and decreasingly popular) networking
techniques is ATM.
- Unlike many of the protocols we've considered so far, ATM involves
fixed-length cells.
- These cells are sent over virtual circuits.
- Each ATM cell has 5 bytes of header and 48 bytes of data.
- Why 48 bytes of data? It's the average of 32 and 64 (really).
- Why 5 bytes of header? It seemed appropriate upon close analysis.
- What are the parts of the header?
- 4 bits of generic flow control. Typically unused.
- 24 bits of address information. Although addresses are shorter
for virtual circuits, we still need a lot of them.
- 3 bits for type. 1** is for management. 0** is for users.
The last bit is set to 1 at user level for ``end of frame''
in ATM adaption layer 5.
- 1 bit for ``it's okay to drop this cell''
- 8 bits for ecc
- How do we fit variable-length data into fixed-length cells? We
segment and reassemble the data.
- There are different policies for doing so.
- We'll just consider 1.
- First, we extend the original data with some extra stuff.
- some amount of padding so that we have the right number of bytes.
- 16 bits reserved; must by all 0.
- 16 bits give the length of the data.
- 32 bits give a CRC.
- Next, we divide the data up into 48 byte cells.
- We reassemble as we go.
- How do we know when we've hit the beginning
of a frame? When the previous cell was the end of a frame.
- How do we know when we've hit the end of a frame? When the third
type bit is 1.
- Note that this puts losses at the frame level, and not at the cell
level. You can decide for yourself whether or not this is an
appropriate strategy.
- As we saw just before break, there are a number of problems
with bridge-based networks. Most had to do with heterogeneity
and scalability.
- Hence, we add another layer to support these two issues.
- Routers are network devices that sit between two or more networks
(with potentially different architectures) and handle the
various issues we have to handle, including translating between
different data-link protocols.
- What are the primary issues we have to consider at this level?
- How to address data
- How to route data once we have an address
- What services we provide (other than routing)
- Different internetworking protocols provide different
features sets.
- The IP protocol (or is that redundant) is the most popular
protocol for doing large-scale networking across heterogeneous
networks.
- Once of the keys to IP was to provide as little as possible.
- Implementing many features, such as reliable delivery or
guaranteed bandwidth, is hard.
- Of course, it's no easier (and may even be harder) to implement
these features at a higher level.
- However, IP does provide segmentation and reassembly, so that
packets don't have architecture-based bounds.
- What does an IP packet look like?
- 4 bits for the version
- 4 bits for the length of the header (in 4-byte words). IP has some
optional stuff that can be in the header.
- 8 bits for the type of service (left until chapter 6)
- 16 bits for the length of the data (in bytes)
- 16 bits for an identifier (for fragmentation and reassembly)
- 3 bits for flags (M: more to come in fragmented packet)
- 13 bits for the offset of the fragment within the packet.
- 8 bits for the hop count
- 8 bits for the high-level protocol
- 16 bits for the protocol
- 32 bits for the source address
- 32 bits for the destination address
- Some multiple of 32 bits for options (with some padding at the end).
- We'll do a fragmentation example