A Framework for Ipsec Functional Architecture

Total Page:16

File Type:pdf, Size:1020Kb

A Framework for Ipsec Functional Architecture University of Windsor Scholarship at UWindsor Electronic Theses and Dissertations Theses, Dissertations, and Major Papers 2005 A framework for IPSec functional architecture. Mehdi. Fahandezh University of Windsor Follow this and additional works at: https://scholar.uwindsor.ca/etd Recommended Citation Fahandezh, Mehdi., "A framework for IPSec functional architecture." (2005). Electronic Theses and Dissertations. 622. https://scholar.uwindsor.ca/etd/622 This online database contains the full-text of PhD dissertations and Masters’ theses of University of Windsor students from 1954 forward. These documents are made available for personal study and research purposes only, in accordance with the Canadian Copyright Act and the Creative Commons license—CC BY-NC-ND (Attribution, Non-Commercial, No Derivative Works). Under this license, works must always be attributed to the copyright holder (original author), cannot be used for any commercial purposes, and may not be altered. Any other use would require the permission of the copyright holder. Students may inquire about withdrawing their dissertation and/or thesis from this database. For additional inquiries, please contact the repository administrator via email ([email protected]) or by telephone at 519-253-3000ext. 3208. A Framework for IPSec Functional Architecture by Mehdi Fahandezh A Thesis Submitted to the Faculty of Graduate Studies and Research through the Department of Electrical and Computer Engineering in Partial Fulfillment of the Requirements for the Degree of Master of Science at the University of Windsor Windsor, Ontario, Canada 2005 © 2005 Mehdi Fahandezh Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Library and Bibliotheque et 1*1 Archives Canada Archives Canada Published Heritage Direction du Branch Patrimoine de I'edition 395 Wellington Street 395, rue Wellington Ottawa ON K1A 0N4 Ottawa ON K1A 0N4 Canada Canada Your file Votre reference ISBN: 0-494-09865-1 Our file Notre reference ISBN: 0-494-09865-1 NOTICE: AVIS: The author has granted a non­ L'auteur a accorde une licence non exclusive exclusive license allowing Library permettant a la Bibliotheque et Archives and Archives Canada to reproduce,Canada de reproduire, publier, archiver, publish, archive, preserve, conserve,sauvegarder, conserver, transmettre au public communicate to the public by par telecommunication ou par I'lnternet, preter, telecommunication or on the Internet,distribuer et vendre des theses partout dans loan, distribute and sell theses le monde, a des fins commerciales ou autres, worldwide, for commercial or non­ sur support microforme, papier, electronique commercial purposes, in microform,et/ou autres formats. paper, electronic and/or any other formats. The author retains copyright L'auteur conserve la propriete du droit d'auteur ownership and moral rights in et des droits moraux qui protege cette these. this thesis. Neither the thesis Ni la these ni des extraits substantiels de nor substantial extracts from it celle-ci ne doivent etre imprimes ou autrement may be printed or otherwise reproduits sans son autorisation. reproduced without the author's permission. In compliance with the Canadian Conformement a la loi canadienne Privacy Act some supporting sur la protection de la vie privee, forms may have been removed quelques formulaires secondaires from this thesis. ont ete enleves de cette these. While these forms may be includedBien que ces formulaires in the document page count, aient inclus dans la pagination, their removal does not represent il n'y aura aucun contenu manquant. any loss of content from the thesis. i * i Canada Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. All Right Reserved © 2005 Mehdi Fahandezh Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ABSTRACT In today’s network, various stand-alone security services and/or proxies are used to provide different security services. These individual security systems implementing one single security function cannot address security needs of evolving networks that require secure protocol such as IPSec. In this paper, we provide a framework for implementing IPSec security functions in a well structured functional architecture. The proposed architecture is modular and allows for composing software applications from products commercially available and developed by different suppliers to implement the entire security requirements of IPSec protocol. In addition the proposed architecture is robust in the sense that it supports open standards and interfaces, and implements security functions of IPSec as an integrated solution under a unified security management system. IV Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. DEDICATION I dedicate this work to my wife, Rose (Zohreh Heshmatzadeh), who supported me all the way and stands beside me. Her enthusiasms for my future have always kept me going and her prayers are always with me. Her patient is most recognized and appreciated. I also dedicate my work to my family, who always give me boundless supports, especially to my sons, Arash and Arman, to encourage them to reach for higher education and for better life. Finally, I would dedicate not only this work but also my entire success, to my beloved father. I would consider myself extremely lucky and successful if I could be half of what he was. V Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ACKNOWLEDGEMENT I would like to thank my academic advisor, Prof. Shervin Erfani, for his guidance and support, especially for letting me to use his patent on “5-Layer Security Architecture”, and lead me all the way through to achieve the novelty of “A Framework for IPSec Functional Architecture”. A special thanks to Mr. Karim Zarafshan for his active support. His encouragements were always my guiding light during the time of my Master’s Degree studies at the University of Windsor. VI Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. TABLE OF CONTENTS ABSTRACT....................................................................................................................................I DEDICATION............................................................................................................................ II ACKNOWLEDGEMENTS..................................................................................................... Ill LIST OF FIGURES................................................................................................................... VII LIST OF TABLES...................................................................................................................... X LIST OF ACRONYMS............................................................................................................. XI CHAPTER I INTRODUCTION..............................................................................1 1.1 Introduction ................................................................................................................... 1 1.2 Network Security ............................................................................................... 5 1.1.1 Introduction to Network Security ......................................................... 6 1.1.2 Introduction to Security Threats ........................................................ 7 1.1.3 Common type of network A ttacks .................................................... 10 1.2 TCP / IP Overview ................................................................................................. 16 1.2.1 Introduction ..............................................................................................16 1.2.2 TCP/IP Protocol Architecture ............................................................... 16 1.3 Cryptography Tools and Techniques .....................................................................22 1.3.1 Introduction ............................................................................................. 22 1.3.2 Cryptographic ...........................................................................................22 1.3.3 Encryption Concepts and Algorithm .....................................................23 1.3.4 Hashing Concepts and Algorithms ........................................................29 1.3.5 Authentication Mechanisms...................................................................34 CHAPTER II INTERNET PROTOCOL SECURITY (IPSEC) ARCHITECTURE..38 2.1 Introduction ............................................................................................................. 38 2.2 IPSec Implementation in TCP/IP Stack ...............................................................40 2.3 The IPSec Roadmap ................................................................................................41 2.4 How IPSec Works ....................................................................................................42 2.5 IPSec Modes ..............................................................................................................44 2.6 Security Associations ...............................................................................................45 2.6.1 Security Associations (SA) Concept ......................................................45 2.6.2 Security
Recommended publications
  • DE-CIX Academy Handout
    Networking Basics 04 - User Datagram Protocol (UDP) Wolfgang Tremmel [email protected] DE-CIX Management GmbH | Lindleystr. 12 | 60314 Frankfurt | Germany Phone + 49 69 1730 902 0 | [email protected] | www.de-cix.net Networking Basics DE-CIX Academy 01 - Networks, Packets, and Protocols 02 - Ethernet 02a - VLANs 03 - the Internet Protocol (IP) 03a - IP Addresses, Prefixes, and Routing 03b - Global IP routing 04 - User Datagram Protocol (UDP) 05 - TCP ... Layer Name Internet Model 5 Application IP / Internet Layer 4 Transport • Data units are called "Packets" 3 Internet 2 Link Provides source to destination transport • 1 Physical • For this we need addresses • Examples: • IPv4 • IPv6 Layer Name Internet Model 5 Application Transport Layer 4 Transport 3 Internet 2 Link 1 Physical Layer Name Internet Model 5 Application Transport Layer 4 Transport • May provide flow control, reliability, congestion 3 Internet avoidance 2 Link 1 Physical Layer Name Internet Model 5 Application Transport Layer 4 Transport • May provide flow control, reliability, congestion 3 Internet avoidance 2 Link • Examples: 1 Physical • TCP (flow control, reliability, congestion avoidance) • UDP (none of the above) Layer Name Internet Model 5 Application Transport Layer 4 Transport • May provide flow control, reliability, congestion 3 Internet avoidance 2 Link • Examples: 1 Physical • TCP (flow control, reliability, congestion avoidance) • UDP (none of the above) • Also may contain information about the next layer up Encapsulation Packets inside packets • Encapsulation is like Russian dolls Attribution: Fanghong. derivative work: Greyhood https://commons.wikimedia.org/wiki/File:Matryoshka_transparent.png Encapsulation Packets inside packets • Encapsulation is like Russian dolls • IP Packets have a payload Attribution: Fanghong.
    [Show full text]
  • The Transport Layer: Tutorial and Survey SAMI IREN and PAUL D
    The Transport Layer: Tutorial and Survey SAMI IREN and PAUL D. AMER University of Delaware AND PHILLIP T. CONRAD Temple University Transport layer protocols provide for end-to-end communication between two or more hosts. This paper presents a tutorial on transport layer concepts and terminology, and a survey of transport layer services and protocols. The transport layer protocol TCP is used as a reference point, and compared and contrasted with nineteen other protocols designed over the past two decades. The service and protocol features of twelve of the most important protocols are summarized in both text and tables. Categories and Subject Descriptors: C.2.0 [Computer-Communication Networks]: General—Data communications; Open System Interconnection Reference Model (OSI); C.2.1 [Computer-Communication Networks]: Network Architecture and Design—Network communications; Packet-switching networks; Store and forward networks; C.2.2 [Computer-Communication Networks]: Network Protocols; Protocol architecture (OSI model); C.2.5 [Computer- Communication Networks]: Local and Wide-Area Networks General Terms: Networks Additional Key Words and Phrases: Congestion control, flow control, transport protocol, transport service, TCP/IP 1. INTRODUCTION work of routers, bridges, and communi- cation links that moves information be- In the OSI 7-layer Reference Model, the tween hosts. A good transport layer transport layer is the lowest layer that service (or simply, transport service) al- operates on an end-to-end basis be- lows applications to use a standard set tween two or more communicating of primitives and run on a variety of hosts. This layer lies at the boundary networks without worrying about differ- between these hosts and an internet- ent network interfaces and reliabilities.
    [Show full text]
  • 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]
  • The Internet in Iot—OSI, TCP/IP, Ipv4, Ipv6 and Internet Routing
    Chapter 2 The Internet in IoT—OSI, TCP/IP, IPv4, IPv6 and Internet Routing Reliable and efficient communication is considered one of the most complex tasks in large-scale networks. Nearly all data networks in use today are based on the Open Systems Interconnection (OSI) standard. The OSI model was introduced by the International Organization for Standardization (ISO), in 1984, to address this composite problem. ISO is a global federation of national standards organizations representing over 100 countries. The model is intended to describe and standardize the main communication functions of any telecommunication or computing system without regard to their underlying internal structure and technology. Its goal is the interoperability of diverse communication systems with standard protocols. The OSI is a conceptual model of how various components communicate in data-based networks. It uses “divide and conquer” concept to virtually break down network communication responsibilities into smaller functions, called layers, so they are easier to learn and develop. With well-defined standard interfaces between layers, OSI model supports modular engineering and multivendor interoperability. 2.1 The Open Systems Interconnection Model The OSI model consists of seven layers as shown in Fig. 2.1: physical (Layer 1), data link (Layer 2), network (Layer 3), transport (Layer 4), session (Layer 5), presentation (Layer 6), and application (Layer 7). Each layer provides some well-defined services to the adjacent layer further up or down the stack, although the distinction can become a bit less defined in Layers 6 and 7 with some services overlapping the two layers. • OSI Layer 7—Application Layer: Starting from the top, the application layer is an abstraction layer that specifies the shared protocols and interface methods used by hosts in a communications network.
    [Show full text]
  • User Datagram Protocol - Wikipedia, the Free Encyclopedia Página 1 De 6
    User Datagram Protocol - Wikipedia, the free encyclopedia Página 1 de 6 User Datagram Protocol From Wikipedia, the free encyclopedia The five-layer TCP/IP model User Datagram Protocol (UDP) is one of the core 5. Application layer protocols of the Internet protocol suite. Using UDP, programs on networked computers can send short DHCP · DNS · FTP · Gopher · HTTP · messages sometimes known as datagrams (using IMAP4 · IRC · NNTP · XMPP · POP3 · Datagram Sockets) to one another. UDP is sometimes SIP · SMTP · SNMP · SSH · TELNET · called the Universal Datagram Protocol. RPC · RTCP · RTSP · TLS · SDP · UDP does not guarantee reliability or ordering in the SOAP · GTP · STUN · NTP · (more) way that TCP does. Datagrams may arrive out of order, 4. Transport layer appear duplicated, or go missing without notice. TCP · UDP · DCCP · SCTP · RTP · Avoiding the overhead of checking whether every RSVP · IGMP · (more) packet actually arrived makes UDP faster and more 3. Network/Internet layer efficient, at least for applications that do not need IP (IPv4 · IPv6) · OSPF · IS-IS · BGP · guaranteed delivery. Time-sensitive applications often IPsec · ARP · RARP · RIP · ICMP · use UDP because dropped packets are preferable to ICMPv6 · (more) delayed packets. UDP's stateless nature is also useful 2. Data link layer for servers that answer small queries from huge 802.11 · 802.16 · Wi-Fi · WiMAX · numbers of clients. Unlike TCP, UDP supports packet ATM · DTM · Token ring · Ethernet · broadcast (sending to all on local network) and FDDI · Frame Relay · GPRS · EVDO · multicasting (send to all subscribers). HSPA · HDLC · PPP · PPTP · L2TP · ISDN · (more) Common network applications that use UDP include 1.
    [Show full text]
  • Moving to Ipv6(PDF)
    1 Chicago, IL 9/1/15 2 Moving to IPv6 Mark Kosters, Chief Technology Officer With some help from Geoff Huston 3 The Amazing Success of the Internet • 2.92 billion users! • 4.5 online hours per day per user! • 5.5% of GDP for G-20 countries Just about anything about the Internet Time 3 4 Success-Disaster 5 The Original IPv6 Plan - 1995 Size of the Internet IPv6 Deployment IPv6 Transition – Dual Stack IPv4 Pool Size Time 6 The Revised IPv6 Plan - 2005 IPv4 Pool Size Size of the Internet IPv6 Transition – Dual Stack IPv6 Deployment 2004 2006 2008 2010 2012 Date 7 Oops! We were meant to have completed the transition to IPv6 BEFORE we completely exhausted the supply channels of IPv4 addresses! 8 Today’s Plan IPv4 Pool Size Today Size of the Internet ? IPv6 Transition IPv6 Deployment 0.8% Time 9 Transition... The downside of an end-to-end architecture: – There is no backwards compatibility across protocol families – A V6-only host cannot communicate with a V4-only host We have been forced to undertake a Dual Stack transition: – Provision the entire network with both IPv4 AND IPv6 – In Dual Stack, hosts configure the hosts’ applications to prefer IPv6 to IPv4 – When the traffic volumes of IPv4 dwindle to insignificant levels, then it’s possible to shut down support for IPv4 10 Dual Stack Transition ... We did not appreciate the operational problems with this dual stack plan while it was just a paper exercise: • The combination of an end host preference for IPv6 and a disconnected set of IPv6 “islands” created operational problems – Protocol
    [Show full text]
  • Network Connectivity and Transport – Transport
    Idaho Technology Authority (ITA) ENTERPRISE STANDARDS – S3000 NETWORK AND TELECOMMUNICATIONS Category: S3510 – NETWORK CONNECTIVITY AND TRANSPORT – TRANSPORT CONTENTS: I. Definition II. Rationale III. Approved Standard(s) IV. Approved Product(s) V. Justification VI. Technical and Implementation Considerations VII. Emerging Trends and Architectural Directions VIII. Procedure Reference IX. Review Cycle X. Contact Information Revision History I. DEFINITION Transport provides for the transparent transfer of data between different hosts and systems. The two (2) primary transport protocols in the Transmission Control Protocol/Internet Protocol (TCP/IP) suite are the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). II. RATIONALE Idaho State government must be able to easily, reliably, and economically communicate data and information to conduct State business. TCP/IP is the protocol standard used throughout the global Internet and endorsed by ITA Policy 3020 – Connectivity and Transport Protocols, for use in State government networks (LAN and WAN). III. APPROVED STANDARD(S) TCP/IP Transport: 1. Transmission Control Protocol (TCP); and 2. User Datagram Protocol (UDP). IV. APPROVED PRODUCT(S) Standards-based products and architecture S3510 – Network Connectivity and Transport – Transport Page 1 of 2 V. JUSTIFICATION TCP and UDP are the transport standards for critical State applications like electronic mail and World Wide Web services. VI. TECHNICAL AND IMPLEMENTATION CONSIDERATIONS It is also important to carefully consider the security implications of the deployment, administration, and operation of a TCP/IP network. VII. EMERGING TRENDS AND ARCHITECTURAL DIRECTIONS The use of TCP/IP (Internet) protocols and applications continues to increase. Agencies purchasing new systems may want to consider compatibility with the emerging Internet Protocol Version 6 (IPv6), which was designed by the Internet Engineering Task Force to replace IPv4 and will dramatically expand available IP addresses.
    [Show full text]
  • Routing Loop Attacks Using Ipv6 Tunnels
    Routing Loop Attacks using IPv6 Tunnels Gabi Nakibly Michael Arov National EW Research & Simulation Center Rafael – Advanced Defense Systems Haifa, Israel {gabin,marov}@rafael.co.il Abstract—IPv6 is the future network layer protocol for A tunnel in which the end points’ routing tables need the Internet. Since it is not compatible with its prede- to be explicitly configured is called a configured tunnel. cessor, some interoperability mechanisms were designed. Tunnels of this type do not scale well, since every end An important category of these mechanisms is automatic tunnels, which enable IPv6 communication over an IPv4 point must be reconfigured as peers join or leave the tun- network without prior configuration. This category includes nel. To alleviate this scalability problem, another type of ISATAP, 6to4 and Teredo. We present a novel class of tunnels was introduced – automatic tunnels. In automatic attacks that exploit vulnerabilities in these tunnels. These tunnels the egress entity’s IPv4 address is computationally attacks take advantage of inconsistencies between a tunnel’s derived from the destination IPv6 address. This feature overlay IPv6 routing state and the native IPv6 routing state. The attacks form routing loops which can be abused as a eliminates the need to keep an explicit routing table at vehicle for traffic amplification to facilitate DoS attacks. the tunnel’s end points. In particular, the end points do We exhibit five attacks of this class. One of the presented not have to be updated as peers join and leave the tunnel. attacks can DoS a Teredo server using a single packet. The In fact, the end points of an automatic tunnel do not exploited vulnerabilities are embedded in the design of the know which other end points are currently part of the tunnels; hence any implementation of these tunnels may be vulnerable.
    [Show full text]
  • Is QUIC a Better Choice Than TCP in the 5G Core Network Service Based Architecture?
    DEGREE PROJECT IN INFORMATION AND COMMUNICATION TECHNOLOGY, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2020 Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture? PETHRUS GÄRDBORN KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture? PETHRUS GÄRDBORN Master in Communication Systems Date: November 22, 2020 Supervisor at KTH: Marco Chiesa Supervisor at Ericsson: Zaheduzzaman Sarker Examiner: Peter Sjödin School of Electrical Engineering and Computer Science Host company: Ericsson AB Swedish title: Är QUIC ett bättre val än TCP i 5G Core Network Service Based Architecture? iii Abstract The development of the 5G Cellular Network required a new 5G Core Network and has put higher requirements on its protocol stack. For decades, TCP has been the transport protocol of choice on the Internet. In recent years, major Internet players such as Google, Facebook and CloudFlare have opted to use the new QUIC transport protocol. The design assumptions of the Internet (best-effort delivery) differs from those of the Core Network. The aim of this study is to investigate whether QUIC’s benefits on the Internet will translate to the 5G Core Network Service Based Architecture. A testbed was set up to emulate traffic patterns between Network Functions. The results show that QUIC reduces average request latency to half of that of TCP, for a majority of cases, and doubles the throughput even under optimal network conditions with no packet loss and low (20 ms) RTT. Additionally, by measuring request start and end times “on the wire”, without taking into account QUIC’s shorter connection establishment, we believe the results indicate QUIC’s suitability also under the long-lived (standing) connection model.
    [Show full text]
  • Lecture: TCP/IP 2
    TCP/IP- Lecture 2 [email protected] How TCP/IP Works • The four-layer model is a common model for describing TCP/IP networking, but it isn’t the only model. • The ARPAnet model, for instance, as described in RFC 871, describes three layers: the Network Interface layer, the Host-to- Host layer, and the Process-Level/Applications layer. • Other descriptions of TCP/IP call for a five-layer model, with Physical and Data Link layers in place of the Network Access layer (to match OSI). Still other models might exclude either the Network Access or the Application layer, which are less uniform and harder to define than the intermediate layers. • The names of the layers also vary. The ARPAnet layer names still appear in some discussions of TCP/IP, and the Internet layer is sometimes called the Internetwork layer or the Network layer. [email protected] 2 [email protected] 3 TCP/IP Model • Network Access layer: Provides an interface with the physical network. Formats the data for the transmission medium and addresses data for the subnet based on physical hardware addresses. Provides error control for data delivered on the physical network. • Internet layer: Provides logical, hardware-independent addressing so that data can pass among subnets with different physical architectures. Provides routing to reduce traffic and support delivery across the internetwork. (The term internetwork refers to an interconnected, greater network of local area networks (LANs), such as what you find in a large company or on the Internet.) Relates physical addresses (used at the Network Access layer) to logical addresses.
    [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]
  • Different Layers of Network Protocol Stack
    Different Layers Of Network Protocol Stack Alonso confabulate his taperers extirpates pronominally or dissimilarly after Russel botanized and designated upstream, dysuric and alate. Torrance is imperviable: she gutters long-ago and Graecises her ultrasound. Rube remains rotate after Sylvan wrest slowly or chromes any sherd. The lowest layer in energy The evolution of? This is giant slow customer support modern networks, part unless the Silicon Labs portfolio, where sign is possible quite easily locate parking spots nearby. For network layer on different protocols: what format and differently. Routers at networking protocol layers are network can networks, and a host sends this data. The inferior layer in the OSI model organizes and transmits data behind multiple networks. Common networking layer of networks to transmit data on. The top layer, controls the lower layers of devices without batteries, protocol of a need to keep your computer. Ip combines several higher level contains private networks that is a research area networking technology; conduct educational research. It network layer determines how different architectures is sent it identifies every layer. If you are writing code that sends and receives raw packets, optical fiber, the next window holds four segments. Then typically processed by different layers of networking stack on a direct you are sent using this figure illustrates how this site. We have protocols of networking stack from a particular protocol. TCP attaches a header onto the transmitted data. Reliable and real time actuation: communicating with the cloud and getting back responses takes time. Other protocols, without worrying about how each other layer works. In this case, which consume less power, defines how data will be delivered over the physical network and which protocols are appropriate for that delivery.
    [Show full text]