1 / 35

Ethernet Lab

betty_james
Download Presentation

Ethernet Lab

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. 1 Ethernet Lab The goal is to complete a UML model that will simulate a local area network with 3 hosts connected to an Ethernet hub. The hub – which is provided – will rebroadcast any bit sent to it to all hosts, including the original sender. The hub is reliable: no bits will be lost, changed, or reordered. The hosts should use CSMA/CD – carrier sense multiple access with collision detection – to decide when to transmit. Task: complete the implementation of the Host class.

    2. 2 System architecture

    3. 3 Carrier Sense Multiple Access (CSMA) Each host should monitor the transmission medium (bits being received from the hub). If the medium is clear, the host can start sending immediately. If the medium is in use, the host must wait until the medium is clear.

    4. 4 Detecting a clear medium The transmission medium is deemed to be clear if there have been no bits received from the hub for a duration of 2.0 “time units.” [The time units represent milliseconds, but since the simulation is not in real time, the actual units are not relevant. However, the relative duration is important.] To detect a clear medium: Start a “frame gap” timer with duration 2.0. If the timer expires, the medium is clear. When a bit is received: Cancel the timer that is running (if there is one). Start a new timer.

    5. 5 Collision Detection (CD) When a host is sending bits, it must monitor the transmission medium. Bits that are being sent should be compared with the bits arriving from the hub. If each bit received matches the most recently sent bit, the transmission is proceeding correctly. If there is a mismatch, then a collision is detected. When a collision is detected, the host should request that the hub send a jamming signal.

    6. 6 When a collision occurs... On receipt of a jamming signal, hosts should do the following: All hosts will discard the partial frame that has been received. Any host that was in the process of sending, or was waiting for the medium to clear before beginning transmission, should do the functions on the next slide. If collisions occur on two consecutive transmission attempts, the transmission should be aborted.

    7. 7 Collision backoff algorithm when sending Wait for 2.0 time units for the medium to clear. Choose a random duration between 0.0 and 16.0 time units. This will be an additional backoff time to wait beyond the initial 2.0 time units. If bits begin arriving before the backoff timer expires, then another host has begun sending a frame and the host will have to wait for the medium to clear before sending bits. The host is not in the situation of sending the same frame twice consecutively, and a collision on the next attempt can be retried. If the backoff timer expires before any bits arrive from the hub, then the host can begin to resend the frame from the beginning. If a collision occurs on this specific attempt to send the frame, the send should be aborted.

    8. 8 Host Addresses Each host must send an address request message to the hub as it starts up. The hub will assign a 2-bit address to the host: one of 00, 01, or 10. An address indication message will be the reply that contains the address. The address 11 will be used as a broadcast address: all hosts are expected to receive the frame (including the sender).

    9. 9 Frame format The frame format for the model is shown above. SFD (start frame delimiter): The bit string 10. Destination address: two bits. Source address: two bits. Frame length: three bits representing a binary number between 3 and 7 inclusive. (e.g. 101 means that that the user data is 5 bits in length. User data: three to seven bits. There will be no CRC field; the hub is assumed to be reliable.

    10. 10 Frame requests Message: FrameReq(BitString, BitString): Request that the host send data to the specified address. First parameter: the destination MAC address. This must be a bit string of length 2. If the string is 11, the frame is to be received by all hosts on the LAN. Second parameter: the data to be sent. This must be a bit string with length between 3 and 7 inclusive. Eventually, a “result indication” message (ResultInd) will be returned to the requestor. The message will contain a result code that indicates whether or not the frame transmission was successful.

    11. 11 Result Indications If the parameters to the frame request are BitStrings of incorrect length, an appropriate result code (see next slide) should be returned immediately Only one frame request can be accepted by a host at any time. If a second frame request is received before the first one has completed, a ResultInd message with the appropriate result code should be returned immediately. If the transmission has to be aborted due to multiple collisions, a ResultInd message with the appropriate result code should be returned when the abort occurs. If the transmission has to be aborted due to multiple collisions, a ResultInd message with the appropriate result code should be returned when the abort occurs. If the transmission is successful, a ResultInd message with the appropriate result code should be returned after the final bit is sent.

    12. 12 Result codes 000: Frame was sent successfully. 001: Address bit string is not of length 2. 010: Data bit string has invalid length (that is, less than 3 or greater than 7). 011: Both the address and data bit strings are invalid (i.e. both of the above two errors) 100: Frame sending was aborted from two consecutive collisions. 101: Attempt to send a second frame while frame sending is in progress (i.e. a frame is currently being sent, or awaiting a clear medium).

    13. 13 Frame indications Message: FrameInd(BitString, BitString): Delivery of data from the host to the upper layer. First parameter: the source address (i.e. the address of the host which sent the message). This will be a bit string of length 2. Second parameter: the data for the upper layer. This will be a bit string with length between 3 and 7 inclusive.

    14. 14 The Hub Bits sent to the hub will be rebroadcast reliably to all hosts, including the original sender. The hub is a shared resource, so there may be collisions where bits from multiple hosts may become mixed together. If a host detects a collision, it should send a jamming request to the hub. The hub will then broadcast a jamming indication to all hosts. After a collision, the hub will wait for 1.0 time units before resuming operation. Any incoming signals during the wait interval will be absorbed by the hub, allowing the medium to clear all outstanding messages.

    15. 15 The Hub interface BitReq(Bit): Request that the hub send a bit to all hosts. Parameter: the value of the bit (0 or 1) to be sent BitInd(Bit): Indication of incoming bit to a host. Parameter: the value of the bit (0 or 1) to be received JamReq: Tells the hub that a collision has been detected, and request that a jamming signal be sent to all hosts. If several JamReq signals are received within a 1.0 time unit interval, the hub will assume they are all for the same collision and rebroadcast only one copy of the signal. JamInd: Indication of a jamming signal to a host AddressReq: Request a MAC address from hub. This signal is to be sent once only by a host during initialization, to obtain the MAC address for a host. AddressInd(BitString): Reply to an AddressReq signal. The parameter will be a bit string with length 2 that is the MAC address assigned by the hub.

    16. 16 Host architecture The Host class will have instances of 3 classes contained within it: Sender: responsible for creating a frame, and sending it, one bit at a time. Receiver: responsible for assembling an incoming frame from bits received. CSMA: process to monitor the transmission medium and detect collisions. This class will direct the behaviour of both the sender and the receiver: it tells the sender when to start and stop transmitting, and passes incoming bits to the receiver.

    17. 17 Host architecture

    18. 18 Interface among host classes SendReq: request from the Sender instance to the CSMA instance for permission to send bits. Parameter: BitString: the frame to be sent. The CSMA instance will compare this bit string to bits collected from the medium during sending to detect collisions. Go: The CSMA instance tells the Sender instance that the medium is clear and that sending can begin. Backoff: The CSMA instance has detected a collision, and tells the Sender instance that it should immediately stop sending bits. The Sender instance should wait for a subsequent Go signal to restart transmission of the frame. No parameters Abort: The CSMA instance has detected a collision, and tells the Sender instance to immediately abort transmission of the frame. Discard: Notifies instance Receiver that instance CSMA has received a jamming signal and that the current partially received frame should be discarded.

    19. 19 The Sender class (1/5) An instance of the Sender class will accept one frame at a time from the upper layer. The FrameReq signal includes the MAC address of the recipient of the message, and the upper layer user data. When the upper layer sends a FrameReq signal and there are no messages currently being sent by this host, the following steps need to be performed: Check that the destination address has exactly 2 bits. Check that the data bit string has at least 3 and no more than 7 bits. At this point, if one of the above constraints is violated, a ResultInd signal with the appropriate result code should be returned to the upper layer. (more on next slide)

    20. 20 The Sender class (2/5) Construct a frame according to the format shown on slide 9. The length of the data bit string has to be converted to a binary bit string with length 3. A method IntToBitString is provided. This procedure will convert an integer to a bit string of a specified length. Send a SendReq signal to the CSMA instance, and wait for the reply. The CSMA instance will send back a Go signal when the transmission medium is clear. The SendReq signal includes a copy of the bit string representing the entire frame to be sent. Once the CSMA instance sends the Go signal, it will be checking the bits on the medium to ensure that what is being sent matches the frame’s bits.

    21. 21 The Sender class (3/5) The frame should be sent one bit at a time by sending BitReq signals to the Hub. It is only allowed to send one bit per UML transition. Your implementation must enter and leave a state between each bit (Lab 1 does this), and it is specifically prohibited to create a loop within a single transition that sends the entire frame. This requirement is due to the semantics of the Telelogic Tau run-time system for scheduling process execution, which state than a single UML transition is guaranteed to run to completion (i.e. from a state to a state) before another process can be activated. In other words, there would be no possibility of a collision if all bits were sent on one transition – and this is not realistic.

    22. 22 The Sender class (4/5) If all bits are sent without receiving either a Backoff or Abort signal from the CSMA instance, then instance Sender sends a ResultInd signal to the upper layer, with result code 000, to indicate successful transmission and that it is ready to accept another frame.

    23. 23 The Sender class (5/5) If the CSMA instance detects a collision while bits are being sent, it will send a Backoff or Abort signal to the Sender instance depending on the result of the collision algorithm used within the CSMA class. The Sender instance should react as follows: If a Backoff signal arrives, the Sender instance should stop sending bits immediately and await a subsequent Go signal from the CSMA instance. The CSMA instance will send the Go signal when it determines that the medium is clear. The frame should be resent from the beginning. No additional SendReq signal is needed. If an Abort signal arrives, the Sender instance should stop sending bits immediately. The attempt to send the frame is abandoned, and a ResultInd signal with result code 100 must be returned to the upper layer.

    24. 24 The receiver class The purpose of this class is to collect incoming bits from the transmission medium into a frame, and to decide whether or not to accept the resulting frame.  If the incoming frame that contains a destination address that matches the local host, or the destination address is the broadcast address 11, the frame is to be passed to the upper layer.  Otherwise, the frame is discarded after it is received. Bits will be passed to this class from the CSMA instance.  Bits will be forwarded at all times, even when this host is sending a frame.  This permits the capability of receiving broadcast frames from this host, or frames sent to oneself.

    25. 25 Receiver class behaviour (1/3) Start with a 2-bit string 00, and left-shift bits into this string as they arrive.  When the string matches 10, assume that a start frame delimiter has been received, and proceed to the next step. Accept two bits as the destination address.  At this point, the determination can be made whether or not the frame will eventually be passed to the upper layer.

    26. 26 The receiver class If the destination address matches the host address, or the destination address is the broadcast address 11, the frame should be eventually passed to the upper layer. Accept two bits as the source address.  If the frame is to be passed to the upper layer, this will be one of the parameters in the FrameInd signal. Accept three bits as the length of data.  These three bits represent a binary number that is the number of data bits to follow.  This number will need to be converted to an integer to count bits, and the method BitStringToInt is provided for this purpose.

    27. 27 The receiver class Accept the specified number of data bits. Once the correct number of data bits have been received, send a FrameInd signal to the upper layer, containing the source address of the frame and the upper layer data. At any time while bits are being received, a Discard signal may arrive from the CSMA instance.  This indicates that a collision has been detected and the bits received so far should be discarded.  This results in returning to step 1 of this description.

    28. 28 The CSMA Class

    29. 29 States for the CSMA class

    30. 30 Description of CSMA behaviour The state machine should keep a Boolean flag wantSend that is true if a request from the Sender instance is pending, and a Boolean flag retry that indicates whether a transmission can be retried if there is a collision.  Other variables can be stored as needed. In the Clear state, a gap of at least 2.0 time units has occurred since the last incoming bit.  Neither sending nor receiving is active.  If a SendReq signal arrives in this state, the Go signal is sent to the Sender instance immediately to indicate that transmission may begin and the CSMA instance moves to the Sending state; the flags WantSend and retry are set to true during the transition.  If bits begin arriving, the CSMA instance moves to the Receiving state.

    31. 31 Description of CSMA behaviour A SendReq signal contains one parameter which is the bit string representing the frame to be sent.  The CSMA instance will need to match these bits as they are sent, and the bit string is kept until the transmission is successful or is aborted. In the Receiving state, bits are currently incoming from the transmission medium, and are being passed to the Receive instance.  On entry to this state, the gap timer is started, and if the timer expires, the CSMA instance moves to the Clear state or the Sending state, depending on the current value of the wantSend flag; if wantSend is true, a Go signal is sent as the instance moves to the sending state.  If a jamming signal arrives, a Discard signal will be sent to the Receive instance so that the partial frame is trashed, and the instance moves to the Collision state.  A send is not permitted in the Receiving state, but if a send request arrives, the CSMA instance sets the wantSend variable to true.

    32. 32 Description of CSMA behaviour In the Sending state, bits are being transmitted by the Sender instance.  The CSMA instance monitors the incoming bits to ensure that they match the frame being sent.  Incoming bits are still forwarded to instance Receiver even while sending.  If there is a mismatch between an incoming bit and the expected next bit, then a collision has occurred.  A JamReq signal is sent to the hub to request the broadcast of a jamming signal.  Collisions may be detected elsewhere as well, so it is when a JamInd signal arrives from the hub that action is taken.  On receipt of a JamInd signal, the CSMA instance will first send a Discard signal to instance Receiver informing it that a collision has been detected and that the partial frame received to this point should be trashed. The CSMA instance will decide whether or not a retry is permitted based on the value of the retry flag.  If a retry is permitted, a Backoff signal will be sent to instance Sender to temporarily halt the sending of bits; if a retry is not permitted, an Abort signal is send to instance Sender telling it to abandon the transmission, and the value of wantSend is set to false.  The CSMA instance then moves into the Collision state.

    33. 33 Description of CSMA behaviour Retries are permitted except in the case where after a collision and backoff, the host draws the lowest backoff duration and restarts sending without having to wait for another frame.  A collision on such an attempt, which is a second consecutive attempt to send the frame, will result in an abort.  However, if after a collision and backoff, another host began sending a frame, a collision on a subsequent transmission attempt will permit a retry.

    34. 34 Description of CSMA behaviour In the Collision state, the host is waiting for the transmission medium to clear after a collision.  A fixed wait of 3.0 time units is allowed for the medium to clear.  At this point, if the wantSend flag is false (i.e. the host was not sending, or the transmission is to be aborted), then the instance moves to the Clear state.  However, if the wantSend flag is true, then the host will participate in the collision backoff.  A random duration is drawn between 0.0 and 16.0 time units, and a backoff timer is started.  The host then moves into the Backoff state.

    35. 35 Description of CSMA behaviour In the Backoff state, the backoff timer is running.  If bits start arriving before the backoff timer expires, then it is assumed that another host won the backoff race and the local host is now receiving a frame.  The backoff timer is cancelled, and the CSMA instance moves to the Receiving state, with the wantSend flag remaining at true to indicate that our host would like to claim the medium when the current frame is finished.  However, if the backoff timer expires, then it is assumed that the local host has won the backoff race; a Go signal is sent to the Sender instance immediately so that it can start transmitting bits.  The CSMA instance then moves into the Sending state. At any point, if a BitInd signal arrives from the transmission medium, it is to be forwarded to the Receiver instance.

    36. 36 Design of the CSMA class

More Related