Scribd Logo
Upload

Welcome to Scribd!

  • Chapter 13 MAN

    Uploaded by

    thundernhut
    67 views17 pages

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    67 views17 pages

    Chapter 13 MAN

    Uploaded by

    thundernhut

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    of 17
    HAPTER 13 Metropolitan Area Networks A metropolitan area network (MAN) is a network designed to extend over an entire city. When local area networks (LANs) in close proximity need to exchange data, they can be connected privately using cable and routers or gateways. When LAN of a single enterprise are distributed over a larger area (such as a city or large campus), however, privately owned connecting infrastructure is impractical. Most organizations find that even if they could get permits to lay cable on public land, a better alternative is to use the services of existing utilities, such as the telephone company. One of these services is switched multimegabit data services (SMDS), which nor- mally uses another protocol called distributed queue dual bus (DQDB). In this chapter, we first discuss DQDB and then concentrate on SMDS. 13.1 IEEE 802.6 (DQDB) In addition to the protocols discussed in Chapter 12, another protocol in the IEEE Project 802 (IEEE 802.6) is distributed queue dual bus (DQDB). Although DQDB resembles a LAN standard, it is designed to be used in MANs. Access Method: Dual Bus As its name implies, DQDB uses a dual bus configuration: Each device in the system connects to two backbone links. Access to these links is granted not by contention (as in 802.3) or token passing (as in 802.4 and 802.5) but by a mechanism called distrib- uted queues, Figure 13.1 shows 2 DQDB topology. In this illustration, the two unidirectional buses are labeled Bus A and Bus B. Five numbered stations connect to the buses as shown. Each bus connects to the stations directly through input and output ports; no drop lines are used, 414 CHAPTER 13 METROPOLITAN ARE: NETWORKS Figure 13.1 DQDB buses and nodes Directional Traffic “ Each bus supports traflic in only one direction, The direction of traffic on one bus is the Opposite of trafic on the other. In Figure 13.1, for example, where the beginning of each bus is represented by a square and the end by a triangle, Bus A traffic moves from right to left. The bus itself starts at station 1 and ends at station 5, Bus B traffic moves from left to right. The bus starts at station 5 and ends at station 1, Upstream and Downstream Stations The relationships of the stations on a DQDB network depend on the direction of traffic flow on’a’bus. As Bus A is configured, Stations I and 2 are considered to be upstream with respect to station 3, and stations 4 and 5 are considered to be downstream with respect to station 3. In the example in Figure 13.1, station 1 has no upstream stations but has four downstream stations. For this reason, station 1 is regarded as the head of Bus A. Station 5 has no downstream sta. tions but has four upstream stations; jt is regarded as the end of Bus A. As Bus B is configured, stations | and 2 are considered downstream with respect to Station 3, and stations 4 and 5 are considered upstream with respect to station 3. In this case, station 5 has no upstream stations but has four downstream stations. It is therefore the head of Bus B. Station I has no downstream stations but has four upstream stations: itis the end of Bus B. Transmission Slots Data travel on each bus as a steady stream of 53-byte slots, These slots are not packets; they are merely continuous streams of bits. The head of Bus A (station 1 in Figure 13.1) Benerates empty slots for use on Bus A. The head of Bus B (station 5) generates empty Slots for use on Bus B. The data rate is dependent on the number of slots generated per second. A number of different data rates are in use today. An empty slot travels down its bus until a transmitting station drops data into it and the intended destination station reads the data. But which bus will the source station choose to carry data to a given destination station? The source station must choose the bus for which the destination station is considered downstream, This rule is intuitive ‘The slots in each bus travel from their head station to their end station, Within each bus, the slots are moving toward the next downstream station. Ifa station wants to send data, it must choose the bus whose traffic flows toward its destination, SECTION 13.) IEEE 802.6(DQDB) 415 ‘The source station must choose the bus for which the destination station is considered downstream, Figure 13.2a shows station 2 sending data to station 4, Station 2 chooses a slot on Bus A because Bus A is flowing downstream from station 2 toward station 4. The trans- mission process is as follows: the head station in Bus A (station 1) creates an empty slot. Station 2 drops its data into the passing slot and addresses the slot to station 4, St tion 3 reads the address and passes the slot along unread. Station 4 recognizes address. It reads the data and changes the status of the slot to “read” before passing it along to station 5, where the slot is absorbed. Figure 13.2 Data transmission in DODB é i s ‘ 3 2 +25 | eee) ees | ie BusA a. Station 2 sends data to station 4 (ies 1 | mba t tot 1 ou | | Bus A », Station 3 sends data to station 1 In Figure 13.2d, station 3 needs to send data to station 1. Station 1 is downstream from station 3 on Bus B, so Bus B is chosen to carry the data. The head of the bus (in this case, station 5) creates an empty slot arid sends it down the bus. Station 4 ignores the slot (why it does so is discussed below) and passes it to station 3. Station 3 inserts its data into the slot and addresses the slot to station 1. Station 2 reads the address and relays the slot unread, Station 1 recognizes its address, reads the data, and discards the 416 CHAPTER 13 METROPOLITAN AREA NETWORKS used slot. Note that because station 1 is the end of the bus, it does not set the read field, but just discards the frame once it has read the data, Slot Reservation To send data downstream, a station must wait for the arrival of an unoccupied slot. But what is to stop an upstream station from monopolizing the bus and Cccupying all the slots? Should stations near the end of a bus suffer because the upstream stations have access to empty slots before they do? This imbalance can be more than an injustice; it ean degrade quality of service—particularly if the system car. ries time-sensitive information such as voice or video. The solution is to require stations to make reservations forthe slots they want, But if you will look at Figure 13.2 again, you will notice a problem, A station makes a res. ervation to keep upstream stations from using slots on the bus. But how can station 2 make @ reservation on Bus A? How can it communicate its reservation upstream to Station 1? The solution, of course, is for station-2.to make its reservation for Bus A on Bus B, which is carrying traffic in the other direction, Station 2 sets a reservation bit n 4 slot on Bus B to tell each station it passes that a station is reserving a slot on Bus A ‘The slot passes every station downstream from station 2 on Bus B—-the same stations that are upstream from it on Bus A. These stations must respect the reservation of a downstream station and leave slots free for the downstream station’s use. How this process works is described below. For how, just remember that to send data on one bus; a station must make a reservation on the other bus. Another important aspect of the reservation process is that no station may fend data without first making a reservation, even if it sees slot after slot pass by empty. Empty slots may be reserved by downstream stations. In fact, even a station that hg made a reservation cannot claim just any empty slot. It must wait for the arrival of the specific slot it reserved. To send data on one bus. a station must use the other bus fo make a reservation, Distributed Queues Making reservations and tracking the reservations of the other stations on a bus require that each station store two queues—one for each bus. Each station has one queue for Bus A, called queue A, and one queue for Bus B, called queue B. A queue is a storage mechanism with first-in, first-out (FIFO) functionality, It is Comparable to the waiting list at a restaurant. As patrons arrive, they sign the list. The first party on the list is seated first. Thus, a DQDB queue is essentially a waiting list for using empty slots. Figure 13.3 gives a conceptual view of a queue, Elements are inserted from the rear and removed from the front as the queue advances, Remember, each station keeps two queues, queue A and queue B. Figure 13:4 shows these two queues for one station, Using a Queue for Bus Access: For clarity, let's examine queue A by itself. Station X adds itself to queue A to reserve Space on Bus A. To do so, it needs to know how many of its downstream neighbors have made slot requests on Bus A already. To track these reservations, it uses virtual SECTION 13.1 IEEE 802.6(DQDB) 417 Figure 13.3 Quewes Front Rear Alfelic|/olfelle lia |falf x ]fa ]fx a. A queue with 11 elements, Front Rear BiycifTpo}le}fei/ affair |fs [x b. The queue after removing the first element from the front. Front Rear By} cif otfe|}e {alfa} a ffs lf « ]fe |i ©. The queue after inserting two elements at the rear Figure 13.4 Distributed queues in anode Queue A _ te FP Bus A tokens. It adds a token at the rear of the queue each time a slot passes on Bus B with a reservation bit set. When the station needs to make a reservation for itself, it sets one of the reservation bits in a slot passing on Bus B (the slot can be occupied or not, provided a request bit is available). The station then inserts its own token into its queue A. This token, however, is of a different type from the others to indicate that it is the station’s own reservation (see Figure 13.5). Each time the station reads its queue A, it can tell how many downstream reserva- tions have been made by counting how many tokens are in the queue. The station can also tell how many empty slots it must allow to pass before it can capture a slot for itself. The station watches the unoccupied slots passing in Bus A. For each empty slot that passes, it removes and discards one token from the front of the queue. When it sees an empty slot and finds its own token at the front of the queue, it discards the token but captures the empty slot and inserts its own data. The station knows it has satisfied the 418 CHAPTER 13 METROPOLITAN AREA NETWORKS Figure 13.5 Reservation token in a queue ‘These tokens are ahead of station X's token in the queue. So three reservations must be satisfied before station X can capture an empty slot ‘This isthe token inserted by station X, 2 BusA | Feservation requirements of the downstream stations by letting the same number of empty slots pass as there are tokens ahead of its own in its queue Now, referring back to Figure 13.2, let’s examine the behavior of each of our orig- inal five stations with respect to Bus A. Station 1 is responsible for slot creation. It creates empty slots continuously and releases them to Bus A. To use one of these slats to.send its own data, however, it must take its place in its queue A just like any other station; If there are tokens in front ofits dealt gation 1 releases empty slots for the downstream stations (stations 2, 3, 4, and 5) Unt its own token comes up. At that point, it inserts its own data into a slot and sete the slot’s busy bit (to 1 for “on”) before releasing the slot to the bus. ~ The behavior of stations 2, 3, and 4 is essentially the same as that of station 1 except that these stations do not create slots, Instead, they watch the empty slos as they pass, For each empty slot that passes; each station removes one token from its queue A until it removes its own token. At that point, it captures the next empty slot, loads data into it, sets the busy bit, and releases it back to the bus, Station 5, on the other hand, cannot send data by Bus A (there is no station downs Stream from station 5 on Bus A). In fact, it does not even need a queue A, although it may contain @ queue A for network compatibility in case a station is added downstream from it in the future. The preceding description also applies to Bus B, with the difference that in Bus B station 5 creates and releases the slots and station 1 does not need a queue B. Queue Structure The DQDB standard states explicitly how logical queues A and B ate to be used, How- ever, the design of each queue is left to the implementors. Networks and stations can be made to simulate the operations of the queues as long as those simulations follow the Stated rules, Ring Configuration DQDB can also be implemented as a ring. In this case, one station plays the roles of both header and end (see Figure 13.6). This topology has the advantage of being SECTION 13.1 ERE 802.6(DQDB) 419 reconfigurable whenever a link or a station fails. Figure 13.6 shows the original ring reconfigured after a link failure | Figure 13.6 DQDB rings Bu Bus A ios A Bus Te Tak Te | ing io a hing te jefines both the medium access control (MAC) sublayer and the physival layer for DQDB. The specifics of the MAC layer functions are complex and fall beyond the scope of this book. In general, however, the MAC layer splits the data stream com- ing from the upper layers into 48-byte segments and adds a S-byte header to each seg- ment to create slots of 53 bytes exch (see Figure 13.7). Having 53 bytes makes a DQDB slot compatible with the size ofa cell ia Asynchronous Transfer Mode (ATM): see Chapter 19. ‘The DQDB He: ‘The five bytes of the DDB he: address, type. priority, and CRC. ader are distributed among five major fields: access Aceess Field The DQDB access field is an vight-bit field that controls access to the bus. I is subdivided into five subfields Busy (B). The B bit indicates whether or not the slot is carrying data. Wh moans the slot is occupied Slot type (ST). The ST bit ean define «wo types of sloss. one for packet transinis: sions and the other for isochronous transmission Me Reserved (IR). The It bit is reserved for Future use. W Previous slot read (PSR). The wwo-bit PSR field is set to 0 by the addressed st tion once it hus read the contents of the slot. setit 420 CHAPTER 13 METROPOLITAN AREA NETWORK. Figure 13.7 D@DB layers Data from LLC or upper layers 48 bytes, B: Busy ST: Slot type R: Reserved PSR: Previous slot read. | RQ: Request Data link Request (RQ). The RQ field consists of three bits set by stations to make reserva- tions for slots. The three bits can represent eight levels of priority in networks with

    You might also like