DOCSLIB.ORG

Hop by Hop Multicast Routing Protocol ∗

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Hop by Hop Multicast Routing Protocol ∗ Hop By Hop Multicast Routing Protocol ∗ Lu´ıs Henrique M. K. Costa1,2, Serge Fdida1, and Otto Carlos M. B. Duarte2 [email protected], [email protected], [email protected] 1 Laboratoire d’Informatique de Paris 6 2 Grupo de Teleinformatica´ e Automac¸ao˜ Université Pierre et Marie Curie Universidade Federal do Rio de Janeiro 4, place Jussieu - 75252 P.O. Box 68504 - 21945-970 Paris Cedex 05 - France Rio de Janeiro - RJ - Brasil ABSTRACT The IP Multicast architecture is completed by group ad- IP Multicast is facing a slow take-off although it is a hotly dressing and routing protocols. A multicast group is iden- debated topic since more than a decade. Many reasons are tified by a class-D IP address which is not related to any responsible for this status. Hence, the Internet is likely to topological information, as opposed to the hierarchical uni- be organized with both unicast and multicast enabled net- cast addressing model. Therefore, multicast address alloca- works. Thus, it is of utmost importance to design protocols tion is complicated and multicast forwarding state is diffi- that allow the progressive deployment of the multicast ser- cult to aggregate. Currently, there is no scalable solution vice by supporting unicast clouds. This paper proposes HBH to inter-domain multicast routing. The approach used is to (Hop-By-Hop multicast routing protocol). HBH adopts the connect different domains through MBGP (Multiprotocol source-specific channel abstraction to simplify address allo- Extensions to BGP)[2] and MSDP (Multicast Source Dis- cation and implements data distribution using recursive uni- covery Protocol)[18]. MBGP is used to announce differ- cast trees, which allow the transparent support of unicast- ent unicast and multicast-capable routes whereas MSDP is only routers. Additionally, HBH is original because its tree able to exchange active source information among the differ- construction algorithm takes into account the unicast rout- ent domains. The configuration complexity of this solution ing asymmetries. As most multicast routing protocols rely works against multicast deployment. On the other hand, on the unicast infrastructure, these asymmetries impact the backbone operators are currently overprovisioning their net- structure of the multicast trees. We show through simula- works so they have little interest in using multicast. tion that HBH outperforms other multicast routing proto- Nevertheless, ISPs (Internet Service Providers) could be cols in terms of the delay experienced by the receivers and interested in multicast to face the increasing demand for the bandwidth consumption of the multicast trees. network resources and content distribution. As a conse- quence, the Internet is likely to be organized with both uni- cast and multicast enabled networks. Therefore, it is of 1. INTRODUCTION utmost importance to design protocols that allow the pro- IP Multicast is facing a slow take-off although it is a hotly gressive deployment of the multicast service by supporting debated topic since more than a decade. Many reasons are unicast clouds. responsible for this status. The IP Multicast architecture Different solutions that simplify the multicast service by is composed of a service model that defines a group as an reducing the distribution model were proposed [8]. EX- open conversation from M sources to N receivers, an ad- PRESS [16] restricts the multicast conversation to 1toN dressing scheme based on IP class-D addresses, and routing (the channel abstraction), simplifying address allocation and protocols. In IP Multicast any host can send to a multicast data distribution, and still covering most of the current mul- group and any host can join it and receive data [5]. The IP ticast applications. The source-specific multicast service, Unicast service model is also completely open, but the po- currently being standardized at the IETF (Internet Engi- tential burden caused by unauthorized senders is amplified neering Task Force), can be implemented by Version 3 of by the group size in multicast. IGMP (Internet Group Management Protocol)[4] and by a modified version of PIM-SM (Protocol Independent Multi- ∗ This work was sponsored by FUJB, CNPq, CAPES, cast - Sparse Mode)[11], named PIM-SSM [3]. Neverthe- COFECUB, and IST Project GCAP N0 1999-10504. less, source-specific multicast does not allow the progressive deployment of the multicast service. Currently, the only alternative is to use tunnels to go through unicast-only net- works. There is some work in progress specific to multi- Permission to make digital or hard copies of all or part of this work for cast tunnelling. One such mechanism is the UDP Multi- personal or classroom use is granted without fee provided that copies are cast Tunneling Protocol (UMTP)[13]. UMTP encapsulates not made or distributed for pro£t or commercial advantage and that copies UDP multicast datagrams inside UDP unicast datagrams, bear this notice and the full citation on the £rst page. To copy otherwise, to so it can be implemented as a user-level process at end- republish, to post on servers or to redistribute to lists, requires prior speci£c hosts. The work in [14, 17] propose different mechanisms permission and/or a fee. SIGCOMM’01, August 27-31, 2001, San Diego, California, USA.. to automate the generation of UMTP tunnels. Automatic Copyright 2001 ACM 1-58113-411-8/01/0008 ...$5.00. 249 Multicast Tunnelling (AMT)[22] is an alternative scheme multicast trees, the majority of routers simply forward pack- that does not rely on UDP, it provides tunneling capabil- ets from one incoming interface to one outgoing interface, in ity through pseudo network interfaces that serve as default other words, the minority of routers are branching nodes. routes to multicast traffic. We do not propose a new au- Nevertheless, all multicast protocols keep per group infor- tomatic tunnelling scheme to connect the multicast-enabled mation in all routers of the multicast tree. Therefore the parts of the Internet, but instead proposes a new multicast idea is to separate multicast routing information in two ta- routing protocol that inherently supports unicast routers. bles: a Multicast Control Table (MCT) that is stored in Additionally, the protocol design takes into account the uni- the control plane and a Multicast Forwarding Table (MFT) cast routing asymmetries that may affect the structure of the installed in the data plane. Non-branching routers simply multicast distribution tree, especially if unicast-only routers keep group information in their MCT, as branching nodes are present. keep MFT entries which are used to recursively create packet The ability to transparently support unicast routers is the copies as to reach all group members. main motivation of the Hop-By-Hop multicast routing pro- REUNITE identifies a conversation by a <S,P > tuple, tocol (HBH) we propose in this paper. HBH implements where S is the unicast address of the source and P is a port multicast distribution through recursive unicast trees, ap- number allocated by the source. Class-D IP addresses are proach originally proposed in REUNITE [21]. REUNITE not used. As receivers join the group REUNITE populates does not use class-D IP addresses for group identification, its tables to construct the distribution tree. REUNITE uses completely abandoning the IP Multicast addressing model. two message types: join and tree. Join messages travel up- HBH uses the unicast infrastructure to do packet forward- stream from the receivers to the source, as tree messages are ing with smaller routing tables, just as REUNITE does, but periodically multicast by the source to refresh soft-state of uses EXPRESS’ channel abstraction to identify a group. the tree. Only the branching nodes for the group <S1,P1> Thus HBH preserves compatibility with IP Multicast as it keep <S1,P1 > entries in their MFT. The control table, uses class-D IP addresses in group identification. HBH con- MCT, is not used for packet forwarding. Non-branching structs Shortest-Path Trees (SPT) instead of Reverse SPTs routers in the <S1,P1> tree have MCT entries for <S1,P1> as most routing protocols do [6, 7, 9, 23]. Consequently, but no MFT entry. HBH potentially provides best routes in asymmetric net- works and is suitable for an eventual implementation of 2.2 Multicast distribution through recursive Quality of Service (QoS) based routing. Additionally, HBH unicast has a tree management algorithm that provides enhanced The basic idea of the recursive unicast approach is that tree stability in the presence of group dynamics and poten- packets have unicast destination addresses. The routers that tially reduces tree bandwidth consumption in asymmetric act as branching nodes for a specific multicast group are re- networks. sponsible of creating packet copies with modified destination This paper is organized as follows: Section 2 presents the address in such a way that all group members receive the related work, motivations and basic ideas of HBH, Section information. 3 describes the HBH protocol and Section 4 presents a per- Figure 1(a) shows how the recursive unicast data distri- formance comparison of HBH and other multicast protocols bution works for HBH. S sends data addressed to H1. H1 through simulation. Section 5 concludes the paper. creates two packet copies and sends them to H4 and H5 (the next branching nodes). H3 simply forwards the packets in 2. THE BASIC PRINCIPLES OF HOP-BY- unicast. H5 receives the data and sends a modified packet H r H HOP MULTICAST copy to 7 and 8. Finally, 7 creates one packet copy to r4, r5,andr6. Data distribution is symmetric on the other This section presents previous work related to this pa- side of the tree. per, namely the EXPRESS and REUNITE protocols, and Figure 1(b) gives an example of the recursive unicast data then introduce the basic principles of HBH and the prob- distribution in REUNITE.
Load more

Recommended publications
  • TCP Over Wireless Multi-Hop Protocols: Simulation and Experiments
    TCP over Wireless Multi-hop Protocols: Simulation and Experiments Mario Gerla, Rajive Bagrodia, Lixia Zhang, Ken Tang, Lan Wang {gerla, rajive, lixia, ktang, lanw}@cs.ucla.edu Wireless Adaptive Mobility Laboratory Computer Science Department University of California, Los Angeles Los Angeles, CA 90095 http://www.cs.ucla.edu/NRL/wireless Abstract include mobility, unpredictable wireless channel such as fading, interference and obstacles, broadcast medium shared In this study we investigate the interaction between TCP and by multiple users and very large number of heterogeneous MAC layer in a wireless multi-hop network. This type of nodes (e.g., thousands of sensors). network has traditionally found applications in the military To these challenging physical characteristics of the ad-hoc (automated battlefield), law enforcement (search and rescue) network, we must add the extremely demanding requirements and disaster recovery (flood, earthquake), where there is no posed on the network by the typical applications. These fixed wired infrastructure. More recently, wireless "ad-hoc" include multimedia support, multicast and multi-hop multi-hop networks have been proposed for nomadic computing communications. Multimedia (voice, video and image) is a applications. Key requirements in all the above applications are reliable data transfer and congestion control, features that are must when several individuals are collaborating in critical generally supported by TCP. Unfortunately, TCP performs on applications with real time constraints. Multicasting is a wireless in a much less predictable way than on wired protocols. natural extension of the multimedia requirement. Multi- Using simulation, we provide new insight into two critical hopping is justified (among other things) by the limited problems of TCP over wireless multi-hop.
    [Show full text]
  • Configuring Ipv6 First Hop Security
    Configuring IPv6 First Hop Security This chapter describes how to configure First Hop Security (FHS) features on Cisco NX-OS devices. This chapter includes the following sections: • About First-Hop Security, on page 1 • About vPC First-Hop Security Configuration, on page 3 • RA Guard, on page 6 • DHCPv6 Guard, on page 7 • IPv6 Snooping, on page 8 • How to Configure IPv6 FHS, on page 9 • Configuration Examples, on page 17 • Additional References for IPv6 First-Hop Security, on page 18 About First-Hop Security The Layer 2 and Layer 3 switches operate in the Layer 2 domains with technologies such as server virtualization, Overlay Transport Virtualization (OTV), and Layer 2 mobility. These devices are sometimes referred to as "first hops", specifically when they are facing end nodes. The First-Hop Security feature provides end node protection and optimizes link operations on IPv6 or dual-stack networks. First-Hop Security (FHS) is a set of features to optimize IPv6 link operation, and help with scale in large L2 domains. These features provide protection from a wide host of rogue or mis-configured users. You can use extended FHS features for different deployment scenarios, or attack vectors. The following FHS features are supported: • IPv6 RA Guard • DHCPv6 Guard • IPv6 Snooping Note See Guidelines and Limitations of First-Hop Security, on page 2 for information about enabling this feature. Configuring IPv6 First Hop Security 1 Configuring IPv6 First Hop Security IPv6 Global Policies Note Use the feature dhcp command to enable the FHS features on a switch. IPv6 Global Policies IPv6 global policies provide storage and access policy database services.
    [Show full text]
  • Junos® OS Protocol-Independent Routing Properties User Guide Copyright © 2021 Juniper Networks, Inc
    Junos® OS Protocol-Independent Routing Properties User Guide Published 2021-09-22 ii Juniper Networks, Inc. 1133 Innovation Way Sunnyvale, California 94089 USA 408-745-2000 www.juniper.net Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Junos® OS Protocol-Independent Routing Properties User Guide Copyright © 2021 Juniper Networks, Inc. All rights reserved. The information in this document is current as of the date on the title page. YEAR 2000 NOTICE Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036. END USER LICENSE AGREEMENT The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License Agreement ("EULA") posted at https://support.juniper.net/support/eula/. By downloading, installing or using such software, you agree to the terms and conditions of that EULA. iii Table
    [Show full text]
  • Don't Trust Traceroute (Completely)
    Don’t Trust Traceroute (Completely) Pietro Marchetta, Valerio Persico, Ethan Katz-Bassett Antonio Pescapé University of Southern California, CA, USA University of Napoli Federico II, Italy [email protected] {pietro.marchetta,valerio.persico,pescape}@unina.it ABSTRACT In this work, we propose a methodology based on the alias resolu- tion process to demonstrate that the IP level view of the route pro- vided by traceroute may be a poor representation of the real router- level route followed by the traffic. More precisely, we show how the traceroute output can lead one to (i) inaccurately reconstruct the route by overestimating the load balancers along the paths toward the destination and (ii) erroneously infer routing changes. Categories and Subject Descriptors C.2.1 [Computer-communication networks]: Network Architec- ture and Design—Network topology (a) Traceroute reports two addresses at the 8-th hop. The common interpretation is that the 7-th hop is splitting the traffic along two Keywords different forwarding paths (case 1); another explanation is that the 8- th hop is an RFC compliant router using multiple interfaces to reply Internet topology; Traceroute; IP alias resolution; IP to Router to the source (case 2). mapping 1 1. INTRODUCTION 0.8 Operators and researchers rely on traceroute to measure routes and they assume that, if traceroute returns different IPs at a given 0.6 hop, it indicates different paths. However, this is not always the case. Although state-of-the-art implementations of traceroute al- 0.4 low to trace all the paths
    [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]
  • Rule-Based Forwarding (RBF): Improving the Internet's Flexibility
    Rule-based Forwarding (RBF): improving the Internet’s flexibility and security Lucian Popa∗ Ion Stoica∗ Sylvia Ratnasamy† 1Introduction 4. rules allow flexible forwarding: rules can select ar- From active networks [33] to the more recent efforts on bitrary forwarding paths and/or invoke functionality GENI [5], a long-held goal of Internet research has been made available by on-path routers; both path and to arrive at a network architecture that is flexible.Theal- function selection can be conditioned on (dynamic) lure of greater flexibility is that it would allow us to more network and packet state. easily incorporate new ideas into the Internet’s infras- The first two properties enable security by ensuring tructure, whether these ideas aim to improve the existing the network will not forward a packet unless it has network (e.g., improving performance [36, 23, 30], relia- been explicitly cleared by its recipients while the third bility [12, 13], security [38, 14, 25], manageability [11], property ensures that rules cannot be (mis)used to attack etc.) or to extend it with altogether new services and the network itself. As we shall show, our final property business models (e.g., multicast, differentiated services, enables flexibility by allowing a user to give the network IPv6, virtualized networks). fine-grained instructions on how to forward his packets. An unfortunate stumbling block in these efforts has In the remainder of this paper, we present RBF, a been that flexibility is fundamentally at odds with forwarding architecture that meets the above properties. another long-held goal: that of devising a secure network architecture.
    [Show full text]
  • Routing and Packet Forwarding
    Routing and Packet Forwarding Tina Schmidt September 2008 Contents 1 Introduction 1 1.1 The Different Layers of the Internet . .2 2 IPv4 3 3 Routing and Packet Forwarding 5 3.1 The Shortest Path Problem . .6 3.2 Dijkstras Algorithm . .7 3.3 Practical Realizations of Routing Algorithms . .8 4 Autonomous Systems 10 4.1 Intra-AS-Routing . 10 4.2 Inter-AS-Routing . 11 5 Other Services of IP 11 A Dijkstra's Algorithm 13 1 Introduction The history of the internet and Peer-to-Peer networks starts in the 60s with the ARPANET (Advanced Research Project Agency Network). Back then, when computers were expen- sive and linked to several terminals, the aim of ARPANET was to establish a continuous network inbetween mainframe computers in the U.S. Starting with only three computers in 1969, mainly universities were involved in establishing the ARPANET. The ARPANET became a network inbetween networks of mainframe computes and therefore was called inter-net. Today it became the internet which links millions of computers. For a long time nobody knew what use such a Wide Area Netwok (WAN) could have for the pop- ulation. The internet was used for e-mails, newsgroups, exchange of scientific data and some special software, all in all services that were barely known in public. The spread of 1 Application Layer Peer-to-Peer-networks, e.g. Telnet = Telecommunication Network FTP = File Transfer Protocol HTTP = Hypertext Transfer Protocol SMTP = Simple Mail Transfer Protocol Transport Layer TCP = Transmission Control Protocol UDP = User Datagram Protocol Internet Layer IP = Internet Protocol ICMP = Internet Control Message Protocol IGMP = Internet Group Management Protocol Host-to-Network Layer device drivers or Link Layer (e.g.
    [Show full text]
  • Are We One Hop Away from a Better Internet?
    Are We One Hop Away from a Better Internet? Yi-Ching Chiu,∗ Brandon Schlinker,∗ Abhishek Balaji Radhakrishnan, Ethan Katz-Bassett, Ramesh Govindan Department of Computer Science, University of Southern California ABSTRACT of networks. A second challenge is that the goal is often an approach The Internet suffers from well-known performance, reliability, and that works in the general case, applicable equally to any Internet security problems. However, proposed improvements have seen lit- path, and it may be difficult to design such general solutions. tle adoption due to the difficulties of Internet-wide deployment. We We argue that, instead of solving problems for arbitrary paths, we observe that, instead of trying to solve these problems in the general can think in terms of solving problems for an arbitrary byte, query, case, it may be possible to make substantial progress by focusing or dollar, thereby putting more focus on paths that carry a higher on solutions tailored to the paths between popular content providers volume of traffic. Most traffic concentrates along a small number and their clients, which carry a large share of Internet traffic. of routes due to a number of trends: the rise of Internet video In this paper, we identify one property of these paths that may had led to Netflix and YouTube alone accounting for nearly half provide a foothold for deployable solutions: they are often very short. of North American traffic [2], more services are moving to shared Our measurements show that Google connects directly to networks cloud infrastructure, and a small number of mobile and broadband hosting more than 60% of end-user prefixes, and that other large providers deliver Internet connectivity to end-users.
    [Show full text]
  • Reverse Traceroute
    Reverse Traceroute Ethan Katz-Bassett, Harsha V. Madhyastha, Vijay K. Adhikari, Colin Scott, Justine Sherry, Peter van Wesep, Arvind Krishnamurthy, Thomas Anderson NSDI, April 2010 This work partially supported by Cisco, Google, NSF Researchers Need Reverse Paths, Too The inability to measure reverse paths was the biggest limitation of my previous systems: ! Geolocation constraints too loose [IMC ‘06] ! Hubble can’t locate reverse path outages [NSDI ‘08] ! iPlane predictions inaccurate [NSDI ‘09] Other systems use sophisticated measurements but are forced to assume symmetric paths: ! Netdiff compares ISP performance [NSDI ‘08] ! iSpy detects prefix hijacking [SIGCOMM ‘08] ! Eriksson et al. infer topology [SIGCOMM ʻ08] Everyone Needs Reverse Paths “The number one go-to tool is traceroute. Asymmetric paths are the number one plague. The reverse path itself is completely invisible.” NANOG Network operators troubleshooting tutorial, 2009. Goal: Reverse traceroute, without control of destination and deployable today without new support ! Want path from D back to S, don’t control D ! Traceroute gives S to D, but likely asymmetric ! Can’t use traceroute’s TTL limiting on reverse path KEY IDEA ! Technique does not require control of destination ! Want path from D back to S, don’t control D ! Set of vantage points KEY IDEA ! Multiple VPs combine for view unattainable from any one ! Traceroute from all vantage points to S ! Gives atlas of paths to S; if we hit one, we know rest of path " Destination-based routing KEY IDEA ! Traceroute atlas gives
    [Show full text]
  • Improving the Reliability of Internet Paths with One-Hop Source Routing
    Improving the Reliability of Internet Paths with One-hop Source Routing Krishna P. Gummadi, Harsha V. Madhyastha, Steven D. Gribble, Henry M. Levy, and David Wetherall Department of Computer Science & Engineering University of Washington {gummadi, harsha, gribble, levy, djw}@cs.washington.edu Abstract 1 Introduction Internet reliability demands continue to escalate as the Recent work has focused on increasing availability Internet evolves to support applications such as banking in the face of Internet path failures. To date, pro- and telephony. Yet studies over the past decade have posed solutions have relied on complex routing and path- consistently shown that the reliability of Internet paths monitoring schemes, trading scalability for availability falls far short of the “five 9s” (99.999%) of availability among a relatively small set of hosts. expected in the public-switched telephone network [11]. This paper proposes a simple, scalable approach to re- Small-scale studies performed in 1994 and 2000 found cover from Internet path failures. Our contributions are the chance of encountering a major routing pathology threefold. First, we conduct a broad measurement study along a path to be 1.5% to 3.3% [17, 26]. of Internet path failures on a collection of 3,153 Internet Previous research has attempted to improve Internet destinations consisting of popular Web servers, broad- reliability by various means, including server replica- band hosts, and randomly selected nodes. We monitored tion, multi-homing, or overlay networks. While effec- these destinations from 67 PlanetLab vantage points over tive, each of these techniques has limitations. For ex- a period of seven days, and found availabilities ranging ample, replication through clustering or content-delivery from 99.6% for servers to 94.4% for broadband hosts.
    [Show full text]
  • Introduction to IP Multicast Routing
    Introduction to IP Multicast Routing by Chuck Semeria and Tom Maufer Abstract The first part of this paper describes the benefits of multicasting, the Multicast Backbone (MBONE), Class D addressing, and the operation of the Internet Group Management Protocol (IGMP). The second section explores a number of different algorithms that may potentially be employed by multicast routing protocols: - Flooding - Spanning Trees - Reverse Path Broadcasting (RPB) - Truncated Reverse Path Broadcasting (TRPB) - Reverse Path Multicasting (RPM) - Core-Based Trees The third part contains the main body of the paper. It describes how the previous algorithms are implemented in multicast routing protocols available today. - Distance Vector Multicast Routing Protocol (DVMRP) - Multicast OSPF (MOSPF) - Protocol-Independent Multicast (PIM) Introduction There are three fundamental types of IPv4 addresses: unicast, broadcast, and multicast. A unicast address is designed to transmit a packet to a single destination. A broadcast address is used to send a datagram to an entire subnetwork. A multicast address is designed to enable the delivery of datagrams to a set of hosts that have been configured as members of a multicast group in various scattered subnetworks. Multicasting is not connection oriented. A multicast datagram is delivered to destination group members with the same “best-effort” reliability as a standard unicast IP datagram. This means that a multicast datagram is not guaranteed to reach all members of the group, or arrive in the same order relative to the transmission of other packets. The only difference between a multicast IP packet and a unicast IP packet is the presence of a “group address” in the Destination Address field of the IP header.
    [Show full text]
  • Analysis and Improvement of Name-Based Packet Forwarding
    Analysis and Improvement of Name-based Packet Forwarding over Flat ID Network Architectures Antonio Rodrigues Peter Steenkiste Ana Aguiar [email protected] [email protected] [email protected] Carnegie Mellon University Carnegie Mellon University Faculty of Engineering, Univ. of Porto Pittsburgh, PA, USA Pittsburgh, PA, USA Instituto de Telecomunicações Faculty of Engineering, Univ. of Porto Porto, Portugal Instituto de Telecomunicações Porto, Portugal ABSTRACT URLs to identify web objects. Name-based Information Centric One of ICN’s main challenges is attaining forwarding table scala- Networks (ICNs) such as NDN [8] promise to be a good fit for such bility when confronted with a huge content space. This is specially applications, for two reasons: (1) no need for external name lookup true in flat ID architectures, which do not naturally support route (e.g., DNS or GNS [18]) by using name-based forwarding at the aggregation for hierarchical names. Previous work has proposed network layer; and (2) reduced forwarding table sizes as a result improving scalability by aggregating content names in a fixed-size of the aggregation enabled by the hierarchical structure of names. Bloom Filters (BF). However, the negative impact of false positive In contrast, ICNs based on flat IDs (defined as fixed-size bit strings (FPs) matches on forwarding correctness and performance has not in this paper), e.g., DONA [12], PURSUIT [6], do not natively have been studied thoroughly. In this paper, we study the end-to-end net- these benefits. work performance of BF-based forwarding. We devise an analytical Recently, a forwarding scheme based on Bloom Filters (BFs) [13, model that accurately models BF-based forwarding and the flow of 14] has been proposed to enable aggregation of content descriptors BF-based packets over inter-domain topologies.
    [Show full text]