DOCSLIB.ORG

Chapter 2. Network Interfaces

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Chapter 2. Network Interfaces Chapter 2. Network interfaces This chapter provides an overview of the protocols and interfaces that allow TCP/IP traffic to flow over various kinds of physical networks. TCP/IP, as an internetwork protocol suite, can operate over a vast number of physical networks. The most common and widely used of these protocols is, of course, Ethernet. The number of network protocols that have provisions for natively supporting IP is clearly beyond the scope of this redbook. However, we provide a summary of some of the different networks most commonly used with TCP/IP. 2.1 Ethernet and IEEE 802.x Local Area Networks (LANs) Two frame formats can be used on the Ethernet coaxial cable: 1. The standard issued in 1978 by Xerox Corporation, Intel Corporation and Digital Equipment Corporation, usually called Ethernet (or DIX Ethernet). 2. The international IEEE 802.3 standard, a more recently defined standard. See Figure 6 for more details. The difference between the two standards is in the use of one of the header fields, which contains a protocol-type number for Ethernet and the length of the data in the frame for IEEE 802.3. Dest Source Preamble Addr Addr Type Info FCS 8bytes 6bytes 6bytes 2bytes 46<=N<=1500 bytes 4 bytes Ethernet IEEE 802.2 header Dest Source Preamble SFD Addr Addr Length DSAP SSAP Ctrl Info FCS 7 bytes1byte 6 bytes 6 bytes 2 bytes 1byte 1byte 1byte variable 4bytes IEEE 802.3 3376\3376F2AE Figure 6. ARP - Frame formats for Ethernet and IEEE 802.3 • The type field in Ethernet is used to distinguish between different protocols running on the coaxial cable, and allows their coexistence on the same physical cable. © Copyright IBM Corp. 2001 29 • The maximum length of an Ethernet frame is 1526 bytes. This means a data field length of up to 1500 bytes. The length of the 802.3 data field is also limited to 1500 bytes for 10 Mbps networks, but is different for other transmission speeds. • In the 802.3 MAC frame, the length of the data field is indicated in the 802.3 header. The type of protocol it carries is then indicated in the 802.2 header (higher protocol level; see Figure 6). In practice, however, both frame formats can coexist on the same physical coax. This is done by using protocol type numbers (type field) greater than 1500 in the Ethernet frame. However, different device drivers are needed to handle each of these formats. Thus, for all practical purposes, the Ethernet physical layer and the IEEE 802.3 physical layer are compatible. However, the Ethernet data link layer and the IEEE 802.3/802.2 data link layer are incompatible. The 802.2 Logical Link Control (LLC) layer above IEEE 802.3 uses a concept known as link service access point (LSAP), which uses a 3-byte header, where DSAP and SSAP stand for destination and source service Access Point respectively. Numbers for these fields are assigned by an IEEE committee (see Figure 7). 1byte 1byte 1byte DSAP SSAP Ctrl Figure 7. ARP - IEEE 802.2 LSAP header Due to a growing number of applications using IEEE 802 as lower protocol layers, an extension was made to the IEEE 802.2 protocol in the form of the Sub-Network Access Protocol (SNAP) (see Figure 8). It is an extension to the LSAP header in Figure 7, and its use is indicated by the value 170 in both the SSAP and DSAP fields of the LSAP frame Figure 7. 3bytes 2bytes Prot.ID or org.code Ethertype Figure 8. ARP - IEEE 802.2 SNAP header In the evolution of TCP/IP, three standards were established that describe the encapsulation of IP and ARP frames on these networks: 30 TCP/IP Tutorial and Technical Overview 1. Introduced in 1984, RFC 894 – Standard for the Transmission of IP Datagrams over Ethernet Networks specifies only the use of Ethernet type of networks. The values assigned to the type field are: a. 2048 (hex 0800), for IP datagrams b. 2054 (hex 0806), for ARP datagrams 2. Introduced in 1985, RFC 948 – Two Methods for the Transmission of IP Datagrams over IEEE 802.3 Networks specifies two possibilities: a. The Ethernet compatible method: The frames are sent on a real IEEE 802.3 network in the same fashion as on an Ethernet network, that is, using the IEEE 802.3 data-length field as the Ethernet type field, thereby violating the IEEE 802.3 rules, but compatible with an Ethernet network. b. IEEE 802.2/802.3 LLC type 1 format: Using 802.2 LSAP header with IP using the value 6 for the SSAP and DSAP fields. The RFC indicates clearly that the IEEE 802.2/802.3 method is the preferred method, that is, that all future IP implementations on IEEE 802.3 networks are supposed to use the second method. 3. Introduced in 1987, RFC 1010 – Assigned Numbers (now obsoleted by RFC 1700, dated 1994) notes that as a result of IEEE 802.2 evolution and the need for more Internet protocol numbers, a new approach was developed based on practical experiences exchanged during the August 1986 TCP Vendors Workshop. It states, in an almost completely overlooked part of this RFC, that all IEEE 802.3, 802.4, and 802.5 implementations should use the Sub-Network Access Protocol (SNAP) form of the IEEE 802.2 LLC, with the DSAP and SSAP fields set to 170 (indicating the use of SNAP), with SNAP assigned as follows: a. 0 (zero) as organization code. b. EtherType field: 1. 2048 (hex 0800), for IP datagrams 2. 2054 (hex 0806), for ARP datagrams 3. 32821 (hex 8035), for RARP datagrams These are the same values used in the Ethernet type field. 4. In 1988, RFC 1042 – Standard for the Transmission of IP Datagrams over IEEE 802 Networks was introduced. As this new approach (very important for implementations) passed almost unnoticed in a little note of an unrelated RFC, it became quite confusing, and finally, in February 1988, it was repeated in an RFC on its own: RFC 1042, which obsoletes RFC 948. Chapter 2. Network interfaces 31 The relevant IBM TCP/IP products implement RFC 894 for DIX Ethernet and RFC 1700 for IEEE 802.3 networks. However, in practical situations, there are still TCP/IP implementations that use the older LSAP method (RFC 948 or 1042). Such implementations will not communicate with the more recent implementations (such as IBM's). Also note that the last method covers not only the IEEE 802.3 networks, but also the IEEE 802.4 and 802.5 networks, such as the IBM Token-Ring LAN. 2.2 Fiber Distributed Data Interface (FDDI) The FDDI specifications define a family of standards for 100 Mbps fiber optic LANs that provides the physical layer and media access control sublayer of the data link layer, as defined by the ISO/OSI Model. IP-FDDI is a draft-standard protocol. Its status is elective. It defines the encapsulating of IP datagrams and ARP requests and replies in FDDI frames. Figure 9 shows the related protocol layers. It is defined in RFC 1188 – A Proposed Standard for the Transmission of IP Datagrams over FDDI Networks for single MAC stations. Operation on dual MAC stations will be described in a forthcoming RFC. RFC 1188 states that all frames are transmitted in standard IEEE 802.2 LLC Type 1 Unnumbered Information format, with the DSAP and SSAP fields of the 802.2 header set to the assigned global SAP value for SNAP (decimal 170). The 24-bit Organization Code in the SNAP header is set to zero, and the remaining 16 bits are the EtherType from Assigned Numbers (see RFC 1700), that is: • 2048 for IP • 2054 for ARP The mapping of 32-bit Internet addresses to 48-bit FDDI addresses is done via the ARP dynamic discovery procedure. The broadcast Internet addresses (whose <host address> is set to all ones) are mapped to the broadcast FDDI address (all ones). IP datagrams are transmitted as series of 8-bit bytes using the usual TCP/IP transmission order called big-endian or network byte order. The FDDI MAC specification (ISO 9314-2 - ISO, Fiber Distributed Data Interface - Media Access Control) defines a maximum frame size of 4500 bytes for all frame fields. After taking the LLC/SNAP header into account, and 32 TCP/IP Tutorial and Technical Overview.
Load more

Recommended publications
  • Logical Link Control and Channel Scheduling for Multichannel Underwater Sensor Networks
    ICST Transactions on Mobile Communications and Applications Research Article Logical Link Control and Channel Scheduling for Multichannel Underwater Sensor Networks Jun Li ∗, Mylene` Toulgoat, Yifeng Zhou, and Louise Lamont Communications Research Centre Canada, 3701 Carling Avenue, Ottawa, ON. K2H 8S2 Canada Abstract With recent developments in terrestrial wireless networks and advances in acoustic communications, multichannel technologies have been proposed to be used in underwater networks to increase data transmission rate over bandwidth-limited underwater channels. Due to high bit error rates in underwater networks, an efficient error control technique is critical in the logical link control (LLC) sublayer to establish reliable data communications over intrinsically unreliable underwater channels. In this paper, we propose a novel protocol stack architecture featuring cross-layer design of LLC sublayer and more efficient packet- to-channel scheduling for multichannel underwater sensor networks. In the proposed stack architecture, a selective-repeat automatic repeat request (SR-ARQ) based error control protocol is combined with a dynamic channel scheduling policy at the LLC sublayer. The dynamic channel scheduling policy uses the channel state information provided via cross-layer design. It is demonstrated that the proposed protocol stack architecture leads to more efficient transmission of multiple packets over parallel channels. Simulation studies are conducted to evaluate the packet delay performance of the proposed cross-layer protocol stack architecture with two different scheduling policies: the proposed dynamic channel scheduling and a static channel scheduling. Simulation results show that the dynamic channel scheduling used in the cross-layer protocol stack outperforms the static channel scheduling. It is observed that, when the dynamic channel scheduling is used, the number of parallel channels has only an insignificant impact on the average packet delay.
    [Show full text]
  • Draft Stable Implementation Agreement for Open
    NBS PUBLICATIONS U.S. DEPARTMENT OF COMMERCE National Bureau of Standards Institute for Computer Sciences and Technology A 11 IDE 7 E T M NBSIR 87-3674 Draft Stable Implementation Agreements for Open Systems Interconnection Protocols NBS Workshop for Implementors of Open Systems Interconnection Version 1 Edition 0 October 1987 DRAFT STABLE IMPLEMENTATION AGREEMENTS Based on the Proceeding of the NBS/OSI Implementor’s Workshop Plenary Assembly Held October 9, 1987 National Bureau of Standards Gaithersburg, MD 20899 U.S. DEPARTMENT OF COMMERCE NATIONAL BUREAU OF STANDARDS — QC 100 - U 5 6 87-3674 1987 C • 2 U.S. DEPARTMENT OF COMMERCE National Bureau of Standards Institute for Computer Sciences and Technology Research Information Center NBSIR 87-3674 National r>ureau of Standards Gaithersburg, Maryland 20899 A) BSc DRAFT STABLE IMPLEMENTATION QCtoo AGREEMENTS FOR OPEN SYSTEMS < USy INTERCONNECTION PROTOCOLS m., 1921 c.> NBS Workshop for Implementors of Open Systems Interconnection Version 1 Edition 0 October 1987 DRAFT STABLE IMPLEMENTATION AGREEMENTS Based on the Proceeding of the NBS/OSI Implementor’s Workshop Plenary Assembly Held October 9, 1987 National Bureau of Standards Gaithersburg, MD 20899 U.S. DEPARTMENT OF COMMERCE, C. William Verity, Acting Secretary NATIONAL BUREAU OF STANDARDS, Ernest Ambler, Director 21 Table of Contents 1. GENERAL INFORMATION 1 1.1 PURPOSE OF THIS DOCUMENT * 1 1.2 PURPOSE OF THE WORKSHOP 1 1.3 WORKSHOP ORGANIZATION 1 2. SUB NETWORKS 1 2.1 LOCAL AREA NETWORKS 1 2.1.1 IEEE 802.2 LOGICAL LINK CONTROL 1 2.1.2 IEEE 802.3 CSMA/CD ACCESS METHOD 1 2.1.3 IEEE 802.4 TOKEN BUS ACCESS METHOD 1 2.1.4 IEEE 802.5 Token Ring Access Method 3 2.2 WIDE AREA NETWORKS 4 2.2.1 CCITT RECOMMENDATION X.25 4 2.3 PRIVATE SUBNETWORKS 4 2.3.1 PRIVATE SUBNETWORKS' 4 3.
    [Show full text]
  • QUESTION 20-1/2 Examination of Access Technologies for Broadband Communications
    International Telecommunication Union QUESTION 20-1/2 Examination of access technologies for broadband communications ITU-D STUDY GROUP 2 3rd STUDY PERIOD (2002-2006) Report on broadband access technologies eport on broadband access technologies QUESTION 20-1/2 R International Telecommunication Union ITU-D THE STUDY GROUPS OF ITU-D The ITU-D Study Groups were set up in accordance with Resolutions 2 of the World Tele- communication Development Conference (WTDC) held in Buenos Aires, Argentina, in 1994. For the period 2002-2006, Study Group 1 is entrusted with the study of seven Questions in the field of telecommunication development strategies and policies. Study Group 2 is entrusted with the study of eleven Questions in the field of development and management of telecommunication services and networks. For this period, in order to respond as quickly as possible to the concerns of developing countries, instead of being approved during the WTDC, the output of each Question is published as and when it is ready. For further information: Please contact Ms Alessandra PILERI Telecommunication Development Bureau (BDT) ITU Place des Nations CH-1211 GENEVA 20 Switzerland Telephone: +41 22 730 6698 Fax: +41 22 730 5484 E-mail: [email protected] Free download: www.itu.int/ITU-D/study_groups/index.html Electronic Bookshop of ITU: www.itu.int/publications © ITU 2006 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. International Telecommunication Union QUESTION 20-1/2 Examination of access technologies for broadband communications ITU-D STUDY GROUP 2 3rd STUDY PERIOD (2002-2006) Report on broadband access technologies DISCLAIMER This report has been prepared by many volunteers from different Administrations and companies.
    [Show full text]
  • Medium Access Control Layer
    Telematics Chapter 5: Medium Access Control Sublayer User Server watching with video Beispielbildvideo clip clips Application Layer Application Layer Presentation Layer Presentation Layer Session Layer Session Layer Transport Layer Transport Layer Network Layer Network Layer Network Layer Univ.-Prof. Dr.-Ing. Jochen H. Schiller Data Link Layer Data Link Layer Data Link Layer Computer Systems and Telematics (CST) Physical Layer Physical Layer Physical Layer Institute of Computer Science Freie Universität Berlin http://cst.mi.fu-berlin.de Contents ● Design Issues ● Metropolitan Area Networks ● Network Topologies (MAN) ● The Channel Allocation Problem ● Wide Area Networks (WAN) ● Multiple Access Protocols ● Frame Relay (historical) ● Ethernet ● ATM ● IEEE 802.2 – Logical Link Control ● SDH ● Token Bus (historical) ● Network Infrastructure ● Token Ring (historical) ● Virtual LANs ● Fiber Distributed Data Interface ● Structured Cabling Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 5: Medium Access Control Sublayer 5.2 Design Issues Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 5: Medium Access Control Sublayer 5.3 Design Issues ● Two kinds of connections in networks ● Point-to-point connections OSI Reference Model ● Broadcast (Multi-access channel, Application Layer Random access channel) Presentation Layer ● In a network with broadcast Session Layer connections ● Who gets the channel? Transport Layer Network Layer ● Protocols used to determine who gets next access to the channel Data Link Layer ● Medium Access Control (MAC) sublayer Physical Layer Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 5: Medium Access Control Sublayer 5.4 Network Types for the Local Range ● LLC layer: uniform interface and same frame format to upper layers ● MAC layer: defines medium access ..
    [Show full text]
  • GS970M Datasheet
    Switches | Product Information CentreCOM® GS970M Series Managed Gigabit Ethernet Switches The Allied Telesis CentreCOM GS970M Series of Layer 3 Gigabit switches offer an impressive set of features in a compact design, making them ideal for applications at the network edge. STP root guard ۼۼ Overview Management (UniDirectional Link Detection (UDLD ۼۼ Allied Telesis Autonomous Management ۼۼ Allied Telesis CentreCOM GS970M Series switches provide an excellent Framework™ (AMF) enables powerful centralized management and zerotouch device installation and Security Features access solution for today’s networks, recovery Access Control Lists (ACLs) based on Layer 2, 3 ۼۼ supporting Gigabit to the desktop for Console management port on the front panel for and 4 headers ۼۼ maximum performance. The Power ease of access Configurable auth-fail and guest VLANs ۼۼ Eco-friendly mode allows ports and LEDs to be ۼۼ over Ethernet Plus (PoE+) models Authentication, Authorization, and Accounting ۼۼ provide an ideal solution for connecting disabled to save power (AAA) Industry-standard CLI with context-sensitive help ۼ and remotely powering wireless access ۼ ۼ Bootloader can be password protected for device ۼ ,points, IP video surveillance cameras Powerful CLI scripting engine security ۼۼ ۼ and IP phones. The GS970M models BPDU protection ۼۼ -Comprehensive SNMP MIB support for standards ۼ feature 8, 16 or 24 Gigabit ports, based device management ۼ DHCP snooping, IP source guard and Dynamic ARP ۼ and 2 or 4 SFP uplinks, for secure (Built-in text editor Inspection
    [Show full text]
  • Communications Programming Concepts
    AIX Version 7.1 Communications Programming Concepts IBM Note Before using this information and the product it supports, read the information in “Notices” on page 323 . This edition applies to AIX Version 7.1 and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright International Business Machines Corporation 2010, 2014. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents About this document............................................................................................vii How to use this document..........................................................................................................................vii Highlighting.................................................................................................................................................vii Case-sensitivity in AIX................................................................................................................................vii ISO 9000.....................................................................................................................................................vii Communication Programming Concepts................................................................. 1 Data Link Control..........................................................................................................................................1 Generic Data Link Control Environment Overview...............................................................................
    [Show full text]
  • Tutorial on Network Communications and Security
    Lecture Notes Introduction to Digital Networks and Security Raj Bridgelall, PhD © Raj Bridgelall, PhD (North Dakota State University, College of Business) Page 1/23 Table of Contents PART I – NETWORKING CONCEPTS.....................................................................................4 1 INTRODUCTION..................................................................................................................4 2 DATA COMMUNICATIONS ..............................................................................................4 2.1 THE OSI MODEL ...............................................................................................................4 2.2 NETWORKING DEVICES .....................................................................................................5 2.3 TCP/IP ..............................................................................................................................6 3 MOBILE IP ............................................................................................................................7 3.1 FIREWALLS........................................................................................................................9 3.2 DHCP AND DNS ..............................................................................................................9 3.3 IPV6 ................................................................................................................................10 PART II – CRYPTOGRAPHY AND NETWORK SECURITY .............................................12
    [Show full text]
  • 1.2. OSI Model
    1.2. OSI Model The OSI model classifies and organizes the tasks that hosts perform to prepare data for transport across the network. You should be familiar with the OSI model because it is the most widely used method for understanding and talking about network communications. However, remember that it is only a theoretical model that defines standards for programmers and network administrators, not a model of actual physical layers. Using the OSI model to discuss networking concepts has the following advantages: Provides a common language or reference point between network professionals Divides networking tasks into logical layers for easier comprehension Allows specialization of features at different levels Aids in troubleshooting Promotes standards interoperability between networks and devices Provides modularity in networking features (developers can change features without changing the entire approach) However, you must remember the following limitations of the OSI model: OSI layers are theoretical and do not actually perform real functions. Industry implementations rarely have a layer‐to‐layer correspondence with the OSI layers. Different protocols within the stack perform different functions that help send or receive the overall message. A particular protocol implementation may not represent every OSI layer (or may spread across multiple layers). To help remember the layer names of the OSI model, try the following mnemonic devices: Mnemonic Mnemonic Layer Name (Bottom to top) (Top to bottom) Layer 7 Application Away All Layer 6 Presentation Pizza People Layer 5 Session Sausage Seem Layer 4 Transport Throw To Layer 3 Network Not Need Layer 2 Data Link Do Data Layer 1 Physical Please Processing Have some fun and come up with your own mnemonic for the OSI model, but stick to just one so you don't get confused.
    [Show full text]
  • High-Level Data Link Control
    ELEC3030 (EL336) Computer Networks S Chen High-Level Data Link Control • This class of data link layer protocols includes High-level Data Link Control (HDLC), Link Access Procedure Balanced (LAPB) for X.25, Link Access Procedure for D-channel (LAPD) for ISDN, and Logic Link Control (LLC) for FDDI • The frame format is: Flag Address Control Data FCS Flag Note that address and control bits 8 8 8 variable 16 8 can be extended to 16 bits, so bit position 12 3 4 5 6 7 8 N(S)=send sequence number N(R)=receive sequence number that sequence number is 7-bit Information: 0 N(S) P/F N(R) S=supervisory function bits P/F • Frame flag: 01111110, so bit Supervisory: 1 0 S N(R) M=unumbered function bits stuffing is used Unumbered: 1 1 M P/F M P/F=poll/final bit • Address: For multipoint operation, it is used to identify the terminal that transmits or receives the frame and, in point-to-point link, it is used to distinguish Commands from Responses (2nd bit for C/R: 0/1). The address is now extended to 16 bits (1st bit indicates long/short 16/8 bits) • Checksum: FCS contains the remainder of a 16-bit CRC calculation of the frame. It may be extended to 32 bits, using a 32-bit CRC • Control: Three types of frames, I, S and U frames. The old protocol uses a sliding window with 3-bit sequence number and the maximum window size is N = 7. The control field is now extended to 16 bits with 7-bit sequence number 60 ELEC3030 (EL336) Computer Networks S Chen HDLC (continue) • I-frames: carry user data.
    [Show full text]
  • Etsi En 301 192 V1.7.1 (2021-08)
    ETSI EN 301 192 V1.7.1 (2021-08) EUROPEAN STANDARD Digital Video Broadcasting (DVB); DVB specification for data broadcasting 2 ETSI EN 301 192 V1.7.1 (2021-08) Reference REN/JTC-DVB-367 Keywords broadcasting, data, digital, DVB, MPEG, video ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - APE 7112B Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° w061004871 Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI deliverable is the one made publicly available in PDF format at www.etsi.org/deliver. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Notice of disclaimer & limitation of liability The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of experience to understand and interpret its content in accordance with generally accepted engineering or other professional standard and applicable regulations.
    [Show full text]
  • Chapter 3: Datalink Layer
    Chapter 3: Data Link Layer Raj Jain Professor of CIS The Ohio State University Columbus, OH 43210 [email protected] http://www.cis.ohio-state.edu/~jain/ The Ohio State University Raj Jain 1 Overview ❑ Datalink layer design issues ❑ Error detection and correction ❑ Simple datalink protocols ❑ Sliding window protocols ❑ Example datalink protocols The Ohio State University Raj Jain 2 1 Data Link Layer Design Issues ❑ Services provided to the Network Layer ❑ Framing ❑ Error Control ❑ Flow Control The Ohio State University Raj Jain 3 Datalink Layer Services ❑ Unacknowledged connectionless service ❑ No acks, no connection ❑ Error recovery up to higher layers ❑ For low error-rate links or voice traffic ❑ Acknowledged connectionless service ❑ Acks improve reliability ❑ For unreliable channels. E.g.: Wireless Systems The Ohio State University Raj Jain 4 2 Datalink Services (Cont) ❑ Acknowledged connection-oriented service ❑ Equivalent of reliable bit-stream ❑ Connection establishment ❑ Packets Delivered In-Order ❑ Connection Release ❑ Inter-Router Traffic The Ohio State University Raj Jain 5 Framing ❑ Framing = How to break a bit-stream into frames ❑ Need for framing: Error Detection/Control work on chunks and not on bit streams of data ❑ Framing methods: ❑ Timing : risky. No network guarantees. ❑ Character count: may be garbled by errors ❑ Character stuffing: Delimit frame with special characters ❑ Bit stuffing: delimit frame with bit pattern ❑ Physical layer coding violations The Ohio State University Raj Jain 6 3 Character Stuffing ❑
    [Show full text]
  • Chapter 6: Medium Access Control Layer
    Chapter 6: Medium Access Control Layer Chapter 6: Roadmap " Overview! " Wireless MAC protocols! " Carrier Sense Multiple Access! " Multiple Access with Collision Avoidance (MACA) and MACAW! " MACA By Invitation! " IEEE 802.11! " IEEE 802.15.4 and ZigBee! " Characteristics of MAC Protocols in Sensor Networks! " Energy Efficiency! " Scalability! " Adaptability! " Low Latency and Predictability! " Reliability! " Contention-Free MAC Protocols! " Contention-Based MAC Protocols! " Hybrid MAC Protocols! Fundamentals of Wireless Sensor Networks: Theory and Practice Waltenegus Dargie and Christian Poellabauer © 2010 John Wiley & Sons Ltd. 2! Medium Access Control " In most networks, multiple nodes share a communication medium for transmitting their data packets! " The medium access control (MAC) protocol is primarily responsible for regulating access to the shared medium! " The choice of MAC protocol has a direct bearing on the reliability and efficiency of network transmissions! " due to errors and interferences in wireless communications and to other challenges! " Energy efficiency also affects the design of the MAC protocol! " trade energy efficiency for increased latency or a reduction in throughput or fairness! Fundamentals of Wireless Sensor Networks: Theory and Practice Waltenegus Dargie and Christian Poellabauer © 2010 John Wiley & Sons Ltd. 3! 1! Overview " Responsibilities of MAC layer include:! " decide when a node accesses a shared medium! " resolve any potential conflicts between competing nodes! " correct communication errors occurring at the physical layer! " perform other activities such as framing, addressing, and flow control! " Second layer of the OSI reference model (data link layer) or the IEEE 802 reference model (which divides data link layer into logical link control and medium access control layer)! Fundamentals of Wireless Sensor Networks: Theory and Practice Waltenegus Dargie and Christian Poellabauer © 2010 John Wiley & Sons Ltd.
    [Show full text]