Which Of The Following Ospf Packets Is Used By Routers To Announce New Information
Walter Goralski, in The Illustrated Network (Second Edition), IGPs
Walter Goralski, in The Illustrated Network (Second Edition), OSPF Designated Router and Backup Designated Router
An OSPF router can also be a Designated Router (DR) and Backup Designated Router (BDR). These have nothing to do with ABRs and ASBRs, and concern only the relationship between OSPF routers on links that deliver packets to more than one destination at the same time (mainly LANs).
There are two major problems with LANs and public data networks like ATM and frame relay (called non-broadcast multiple-access, or NBMA, networks). First is the fact that the link-state database represents links and routers as a directed graph. A simple LAN with five OSPF routers would need N (N − 1)/2, or 5(4)/2=20 link-state advertisements just to represent the links between the routers, even though all five routers are mutually adjacent on the LAN and any frame sent by one is received by the other four. Second, and just as bad, is the need for flooding. Flooding over a LAN with many OSPF routers is chaotic, as link-state advertisements are flooded and “reflooded” on the LAN.
Which of the following ospf packets is used by routers to announce new information? To address these issues, multiaccess networks such as LANs always elect a designated router for OSPF. The DR solves the two problems by representing the multiaccess network as a single “virtual router” or “pseudo-node” to the rest of the network and managing the process of flooding link-state advertisements on the multiaccess network. So each router on a LAN forms an OSPF adjacency only with the DR (and also the Backup DR [BDR] as mentioned later). All link-state advertisements go only to the DR (and BDR), and the DR forwards them on to the rest of the network and internetwork routers.
Each network that elects a DR also elects a BDR that will take over the functions of the DR if and when the DR fails. The DR and BDR form OSPF adjacencies with all of the other routers on the multiaccess network and the DR and BDR also form an adjacency with each other.
Read full chapter
Which of the following ospf packets is used by routers to announce new information? URL: /science/article/pii/B MPLS-Based Virtual Private Networks
Walter Goralski, in The Illustrated Network (Second Edition), Customer Edge
Each site has a customer-edge (CE) router, designated CE1, CE2, … CEn as needed. These routers are owned and operated by the customer and are at the “edge” of the VPN. At least one link runs to the ISP and carries customer data to and from the ISP’s network. The data on the link can be in plain text (the link is generally short, point to point, and not considered a high security risk) or encrypted with IPSec, SSL, or some other VPN protocol. The CEs still run a routing protocol, but only to gather information about other CE routers belonging to their own L3VPN.
Which of the following ospf packets is used by routers to announce new information? Read full chapter
URL: /science/article/pii/B Routing
Brad Woodberg, … Ralph Bonnell, in Configuring Juniper Networks NetScreen & SSG Firewalls, Link State Advertisements
Link State Advertisements (LSAs) are messages communicated via multicast to other routers in the OSPF domain. They are sent from internal routers to the DR/BDR routers to announce changes. This communication occurs on multicast address 224.0.0.6. The DR will announce changes to the other routers via multicast address 224.0.0.5. Several different types of LSAs exist in OSPF. We will focus on 1 thru 5 and 7, which are the ones you have to be concerned with for the functionality of OSPF on the firewall.
▪ Router LSA (1) This LSA is sent from an internal router to the DR/BDR routers to announce a change in the network. Specifically, they define the state of their interfaces, as well as associated costs.
▪ Network LSA (2) The DR will send this LSA out to the other routers in its area to announce the topology information based upon what it has gathered from other LSA types.
▪ Summary LSA (3) This LSA is sent between areas to announce routes from one area to another. By summarizing your network, you take advantage of using this LSA, since you reduce the number of routes you have to announce. These are sent by the ABR.
▪ ASBR Summary LSA (4) This is essentially a re-advertised version of the LSA 5 packet. Originally, the ASBR advertises the type 5 packet, but because some of the next hop information may not be known by remote networks, this packet is translated by the ABR to type 4, which is then passed on to other areas.
▪ External LSA (5) These are sent from the ASBR and are often the result of some sort of routing redistribution process from one routing protocol to another. They are sent to all areas, but may be filtered on areas such as stub and totally stubby areas.
▪ NSSA LSA (7) These are sent from routers in an NSSA to ABRs to redistribute into the OSPF area. The ABR will translate these into type-5 OSPF packets.
Read full chapter
URL: /science/article/pii/B Implementing the OSPF Protocol
Dale Liu, … Luigi DiGrande, in Cisco CCNA/CCENT Exam , , Preparation Kit, Reviewing the show ip ospf database Command
There are times when you might need to display the OSPF database for a particular area to ensure the proper configuration. Utilize the show ip ospf database command to display either the full OSPF database or a summary of it.
■
Link ID
■ for router links, this is set to the router’s OSPF RID
■ for network links, this is set to the IP interface address of the network’s DR
■ for type 3 summary LSAs, this is set to an IP network number
■ for type 4 summary LSAs, this is set to an ASBR’s RID
■ for type 5 externals, this is set to an IP network number
■ Adv Router—advertising router’s ID
■ Age—link-state age
■ Seq#—link-state sequence number (detects old or duplicate LSAs)
■ Checksum—Fletcher checksum of the complete contents of the LSA
Figure 7.13 depicts sample output from the show ip ospf database command with imbedded commentary.
FIGURE 7.13. Sample Output from the show ip ospf database Command
Read full chapter
URL: /science/article/pii/B OSPF and Integrated IS–IS
Deep Medhi, Karthik Ramasamy, in Network Routing (Second Edition), Hello Packet
The primary purpose of the hello packet (Figure 6.6) is to establish and maintain adjacencies. This means that it maintains a link with a neighbor that is operational. The hello packet is also used in the election process of the Designated Router and Backup Designated Router in broadcast networks. The hello packet is also used for negotiating optional capabilities.
Figure 6.6. OSPF hello packet (OSPF packet type=1).
• Network Mask: This is the address mask of the router interface from which this packet is sent.
• Hello Interval: This field designates the time difference in seconds between any two hello packets. The sending and the receiving routers are required to maintain the same value; otherwise, a neighbor relationship between these two routers is not established. For point-to-point and broadcast networks, the default value is 10 sec, while for non-broadcast networks the default value used is 30 sec.
• Options: Options fields allow compatibility with a neighboring router to be checked.
• Priority: This field is used when electing the designated router and the backup designated router.
• Router Dead Interval: This is the length of time in which a router will declare a neighbor to be dead if it does not receive a hello packet. This interval needs to be larger than the hello interval. Also note that the neighbors need to agree on the value of this parameter. This way, a routing packet, that is received and does not match this field on a receiving router’s interface folder, is dropped. The default value is typically four times the default value for the hello interval; thus, in point-to-point networks and broadcast networks, the default value used is 40 sec while in non-broadcast networks, the default value used is 120 sec.
• Designated Router (DR) (Backup Designated Router (BDR)): DR (BDR) field lists the IP address of the interface of the DR (BDR) on the network, but not its router ID. If the DR (BDR) field is 0.0.0.0, then this means there is no DR (BDR).
• Neighbor: This field is repeated for each router from which the originating router has received a valid Hello recently, meaning in the past RouterDeadInterval.
Read full chapter
URL: /science/article/pii/B Application
Vinod Joseph, Srinivas Mulugu, in Deploying Next Generation Multicast-enabled Applications, .5.4 SSM and IGMPv3: Initial Join in IPTV Network
The sequence of events that triggers the initial join of an STB into an IPTV network is shown in Figure 6.8. When the IPTV switches on, the STB detects the channel request and sends an IGMP Host Report. This is forwarded up to the DR. This router detects the neighbor to which it should forward the reverse path traffic and sends the JOIN (S, G) message upstream. The IP WAN/MAN network forwards the JOIN (S, G) messages until they reach the router to which the source is connected. As the JOIN (S, G) message flows through the routing domain, the shortest path tree (SPT) is constructed across the network to the router connecting to the content source.
Figure 6.8.
The traffic flow then begins through the network from the source, along the SPT to the DSLAM, and finally to the STB and the IPTV.
Read full chapter
URL: /science/article/pii/B Newly Developed Telecommunication Services
Nobuyoshi Terashima, in Intelligent Communication Systems, .6.9 Layered Structure of a Local Area Network
A local area network protocol has a layered structure and corresponds to the OSI reference model. The correspondence between the OSI reference model and an LAN protocol is shown in Figure 2.4. The data link layer protocol corresponds to the Logical Link Control (LLC) and Multiaccess Control (MAC) protocols. The physical layer protocol of the OSI reference model corresponds to the physical layer protocol of the LAN. The LLC protocol provides a common data transmission function to the upper layer of the LLC. The LLC frame consists of a data service access point (DSAP), a sender service access point (SSAP), control information, and data. LLC has been standardized as IEEE 802.2 LLC. In MAC, there are CSMA/CD, token-bus, token-ring, and FDDI MAC protocols. CSMA/CD, token-bus, token-ring, and FDDI MAC protocols have been standardized as IEEE 802.3, IEEE 802.4, IEEE 802.5, and FDDI (ANSI) protocol, respectively. In CSMA/CD, there are 10 BASE 5, 10 BASE 2, 10 BASE T, and 10 BROAD 36 protocols. FDDI has been standardized by the American National Standards Institute (ANSI) and is used mainly for a high-speed LAN. The coverage of the network based on FDDI is about 40–50 km.
How does a local area network work? An example involving the Internet is shown in Figure 7.9. In this network, LANs are interconnected by routers and gateways (GW).
FIGURE 7.9. Internet topology.
(1) Function of the router: The router sends a message to the router designated by the routing table. It does not perform protocol conversion.
(2) Functions of a GW: In addition to routing, a GW performs protocol conversion.
(3) Example of routing: An example of routing is shown in Figure 7.10, in which the designation IP address is 192.1.10.0 and the corresponding router address 192.1.1.2 is chosen. According to the information, router 3 is selected and the message is sent to router 3.
FIGURE 7.10. Routing.
(4) TCP/IP protocol example: A TCP/IP protocol example and a message form are shown in Figure 7.11. The destination IP address is 1.11.3, which identifies the destination node to which the message is sent. The destination port number is 2001, which identifies the destination process to which the message is sent.
FIGURE 7.11. TCP/IP protocol example.
Read full chapter
URL: /science/article/pii/B Multicast Routing
Deep Medhi, Karthik Ramasamy, in Network Routing (Second Edition), .1 Multicast IP Addressing
Multicast IP addresses are assigned from the same address space as for unicast IP addresses. Let us start with IPv4 first. On the surface, a multicast address looks the same as any 32-bit unicast IP address except for the leading bits. For the 32-bit address space in IPv4, the leading four bits for a multicast address are 1110, which means that the leading byte is in the range to . When we convert to decimal values, they become 224 and 239, respectively, resulting in the multicast address range 224.0.0.0–239.255.255.255.
In a way, it is insightful to allocate an IP multicast address from the 32-bit address space, instead of using some other address space. Why so? If you look at the IP header format, it allows the destination address field to be 32 bits. Therefore, there is no need to change the IP header format for multicasting packets. That is, a 32-bit multicast address can also be used for the destination address in an IP packet header. In other words, there is no need to change the IP header format.
While the IP packet format does not change, this does not mean that the destination address in the IP packet is to be interpreted the same way for both unicast and multicast addresses. In the case of a unicast address, we know that the destination address is for a specific host. On the other hand, the destination address field in an IP packet occupied by a multicast address is more like a channel, similar to a radio station transmitting on a particular frequency. With radio, when you want to listen to a particular station, you need to tune your radio dial to the appropriate frequency. Similarly, with IP multicasting, if a user wants to “hear” what is being transmitted on a particular multicast address, she/he is required to “listen” to it using a protocol, known as the Internet Group Management Protocol (IGMP) for IPv4 or the Multicast Listener Discovery (MLD) protocol for IPv6; we will discuss how they work in Section 8.2 and Section 8.3, respectively.
What does a multicast router then do when it receives an IP packet in which the destination address is set to a multicast address? On receiving such a packet, a multicast router forwards the packet on all its outgoing interfaces to its adjacent multicast routers so that this multicast address is percolated through the rest of the network to the end hosts who wish to listen to it via IGMP or MLD from their attached multicast routers. That is, the multicast routing protocol is in operation among the multicast routers, while IGMP/MLD operates between hosts and their home routers; this separation is depicted in Figure 8.2. It should be noted that for practical reasons, a multicast router may not always forward a received packet from its upstream multicast router on all its outgoing interfaces. As we go through the rest of this chapter, you will see where and why a multicast router may not always forward a packet.
Figure 8.2. Multicast service in operation: separation between the operating regions of the multicast protocol and IGMP/MLD.
The IPv4 multicast address space is divided into a number of different purposes, such as:
• The range 224.0.0.0–224.0.0.255 (224.0.0.0/24) is specifically allocated for use by routing protocols and by topology discovery and maintenance protocols; this block is referred to as the Local Network Control Block. For example, three multicast addresses are reserved for the OSPF protocol; 224.0.0.5 for flooding of link state updates (except for designated routers), 224.0.0.6 is for flooding within a subnet with a designated router, and 224.0.0.24 is for OSPF-TE.
• The range 224.0.1.0–224.0.1.255 (224.0.1.0/24) is used for the Internetwork Control Block. For example, 22.4.0.1.1 is used for the network time protocol (NTP).
• The range 224.0.2.0–224.0.255.255 is designated as the ad hoc address block. This block falls neither in Local Network Control Block, nor in Internetwork Control Block. Addresses in this block were assigned before clear guidelines were developed and allocated by IANA.
• The range 224.1.0.0–238.255.255.255 is known as globally scoped addresses. Within this range, the sub-ranges are allocated as follows:
∘ The sub-range 224.1.0.0–224.1.255.255 is unassigned.
∘ The sub-range 224.2.0.0–224.2.255.255 (224.2.0.0/16) is known as the SDP/SAP Block. This block is used by applications related to the Session Announcement Protocol (SAP) and the Session Description Protocol (SDP); see RFC 2974 [344].
∘ The sub-range 224.3.0.0–231.255.255.255 is unassigned.
∘ The sub-range 232.0.0.0–232.255.255.255 (232.0.0.0/8) is reserved for source specific multicast (SSM) (see Section 8.8.4).
∘ The sub-range 233.0.0.0–233.255.255.255 (233.0.0.0/8) is designated as the GLOP Block. Addresses in this block are statically assigned primarily for use by Internet service providers (ISPs), or content providers for content sourcing globally.
∘ The sub-range 234.0.0.0–238.255.255.255 is unassigned.
• The range 239.0.0.0–239.255.255.255 (239.0.0.0/8) is designated as a private address block for multicasting. For example, an institution or an organization may use this address space within its organization for multicast services.
In Table 8.1, a representative list of well-known multicast addresses is shown. As you can see, the multicast addresses are used in a number of different ways. For example, OSPF protocol uses it for flooding. Network time protocol uses a multicast address. IGMP, discussed in Section 8.2, is also assigned a multicast address.
Table 8.1. IPv4 pre-defined multicast addresses: a representative list (source: [393]).
IPv4 Address Description 224.0.0.1 All Systems on this Subnet 224.0.0.2 All Routers on this Subnet 224.0.0.4 All DVMRP Routers 224.0.0.5 OSPF Routers (except Designated Routers) 224.0.0.6 OSPF Designated Routers 224.0.0.9 RIP2 Routers 224.0.0.10 EIGRP Routers 224.0.0.11 Mobile-Agents 224.0.0.12 DHCP Server/Relay Agent 224.0.0.13 All PIM Routers 224.0.0.15 CBT routers 224.0.0.18 Virtual Router Redundancy Protocol (VRRP) 224.0.0.22 IGMP 224.0.0.24 OSPF-TE 224.0.0.252 Link-local Multicast Name Resolution 224.0.1.1 Network Time Protocol (NTP) Similar to IPv4, a part of IPv6 multicast address space is allocated for multicasting. It is separated into four parts (see Figure 8.3). The first byte in an IPv6 multicast address is set to . In IPv6 notation, the multicast address block is listed as: FF00::/8. After the first byte, the next four bits are used as Flag, known as 0RPT flag, followed by the next four bits that designate the scope of the address. In the Flag field, the first bit is reserved and is set to 0; the rest are shown in Table 8.2(a). There are also a number of scopes defined, as shown in Table 8.2(b). A list of well-known IPv6 multicast addresses is shown in Table 8.3.
Figure 8.3. IPv6 multicast address.
Table 8.2. IPv6 multicast addressing: (a) flags and (b) scope.
Flag Name R = 0 No embedded Rendezvous Point (RP) R = 1 Embedded Rendezvous Point (RP) P = 0 Not based on unicast P = 1 Based on unicast T = 0 Permanent address (IANA assigned) T = 1 Temporary address (local assigned) (a) Flags Scope Name 1 Interface-Local scope 2 Link-Local scope 3 Realm-Local scope 4 Admin-Local scope 5 Site-Local scope 8 Organization-Local scope E Global scope (b) Scope Table 8.3. IPv6 pre-defined multicast addresses: a representative list (source: [394]).
IPv6 Address Description FF02::1 All Systems on this Subnet FF02::2 All Routers on this Subnet FF02::4 All DVMRP Routers FF02::5 OSPF Routers (except Designated Routers) FF02::6 OSPF Designated Routers FF02::9 RIP Routers FF02::A EIGRP Routers FF02::B Mobile-Agents FF02::D All PIM Routers FF02::12 Virtual Router Redundancy Protocol (VRRP) FF02::16 All MLDv2-capable routers FF02::1:3 Link-local Multicast Name Resolution FF0X::101 Network Time Protocol (NTP) Now, what does a multicast group mean in terms of multicast IP addressing? In its simplest form, a multicast group needs a single multicast IP address to reach the receivers; for example, when a unidirectional multicast session originates from a source, just one multicast address suffices. However, when it is an application such as a multi-party conferencing application, an implementation may use multiple multicast IP addresses, one associated with each source in this conferencing application. Thus, when we consider the tuple 〈source, multicast group〉, it would typically mean that a source has an associated multicast IP address for the source to stream data to the receivers. In general, we refer to this tuple as 〈s,M〉 where s is the source and M is the multicast group. An advantage of a multicast group specified using a multicast IP address it that the receiving hosts need not be explicitly listed in the group, saving us from having a major headache.
Read full chapter
URL: /science/article/pii/B Routing Issues
In IP Addressing & Subnetting INC IPV6, Routing Update Impact
The RIP protocol is more suited to smaller networks because of the large amount of broadcasts used to update routers about paths to remote networks. The OSPF protocol is well-suited to larger, dynamic, more complicated networks. RIP updates occur every 30 seconds, whereas OSPF updates occur every 30 minutes. RIP routers send the entire routing table to neighboring routers, whereas OSPF sends very small update flies to routers whenever they detect a change in the network, such as a failed link or new link. When routers exchange information, it is called convergence, where the routers “converge” on the new representation of the network very quickly.
A network of OSPF and RIP routers can possibly coexist. OSPF is slowly replacing RIP as the interior gateway routing protocol of choice. These OSPF routers can simultaneously RIP for router-to-end station communications, and OSPF for router-to-router communications. For example, you can configure a Windows NT computer to participate as a RIP router in a RIP-routing environment, but you cannot configure this same Windows NT computer to participate as an OSPF router in an OSPF-routing environment. This coexistance between RIP and OSPF makes gradual migrations from RIP to OSPF feasible. In fact, RIP and OSPF routers cannot only coexist in the same network, they can actually share routing information. Figure 6.8 shows the enabling of RIP routing on Windows NT.
Figure 6.8. Configuring a Windows NT computer as a RIP router.
To configure your Windows NT computer to participate in sharing routing updates with other computers on the network, you need to enable IP forwarding. This is done in the Network applet of the Control Panel, by selecting the TCP/IP protocol and viewing the properties. The Routing tab is illustrated in Figure 6.8. You also need to enable RIP in the Services applet in the Control Panel.
In OSPF, a neighbor is another router running OSPF that has an interface on the same network. When discovering and configuring OSPF neighbors, the router will use the Hello protocol to discover their neighbors and maintain this relationship. On two of the types of OSPF networks, point-to-point and broadcast, the Hello protocol will dynamically discover the neighbors. On a nonbroadcast network, you will have to configure the neighbors manually, because OSPF will not have a means of contacting and establishing relationships with its neighbors.
This Hello protocol ensures that the relationships between the routers are bidirectional. This will guarantee that every OSPF router will send as well as receive updated route information to and from each of its neighbors. The communication is bidirectional when the router sees itself in the Hello packet from another router. Included in the Hello protocol packet is the following:
▪ The router’s priority
▪ The router’s Hello timer and Dead timer value
▪ A list of routers that has sent the router Hello packets on this interface
▪ This router’s choice of designated router and backup designated router.
However, this does not mean OSPF is a perfect routing protocol as far as routing updates are concerned. In really large network configurations, OSPF can produce a large number of router updates that flow between routers. If a network consists of hundreds of routers in a network topology that is designed to be fault tolerant, the number of link-state messages that traverse the network can be in the thousands. These thousands of link-state messages can be propagated from router to router across the network, consuming valuable bandwidth, especially on slower WAN links. The routers then have to recalculate their routing tables, which can consume valuable RAM and CPU cycles if these routing tables are a significant size. Fortunately for OSPF, no routing protocol available today is capable of minimizing routing updates in a very large network with many routers. OSPF is, however, much more capable than RIP at minimizing these bandwidth intensive routing updates. By the way, by “link-state” we mean the state, or condition of a link that is a description of the router’s relationship to its neighboring routers. We think of the link as being an interface on the router. An interface, for example, would be the IP address of the physical interface, the subnet mask, the type of network to which it is connected, or the routers connected to the network. The collection of all these link-states would comprise a link-state database.
The link-state algorithm states (in much more complex terms than described here) a few steps of building and calculating these paths:
▪ Upon initialization or upon a change in routing information, a router will generate a link-state advertisement that will represent the collection of all the link-states currently on the router.
▪ In an event called flooding, all routers will exchange this link-state information. This flood of routing information will be propagated to all routers in the area.
▪ After each router has finished compiling the link-state information, they will begin to calculate a Shortest Path Tree to all destinations. This is very CPU-intensive, as there can be hundreds of paths that need to be processed. These paths will include the associated cost and next hop information to reach those destinations.
▪ If there are no changes in the network topology, OSPF will not be very active. OSPF will not need to exchange link-state information, and the routers will therefore not need to calculate Shortest Path Trees, because they will already have the information processed.
There are also different types of link-state packets, as follows:
Router links. Describe the state and cost of the router’s links to the area. These router links are the indication of the interfaces on a router belonging to a certain area.
Network links. Describe all routers that are attached to a specific segment. These are generated by the Designated Router (DR).
Summary links. Describe networks in the autonomous system (AS), but outside of an area. These summary links also describe the location of the ABSR. They are also generated by the ABRs.
External links. Describe destinations that are external to the AS, or a default route from outside the AS. The ASBR is responsible for injecting the external link information into the autonomous system.
Another feature of OSPF is that routing updates are not passed across areas. Remember that areas are separated by the types of routers that we listed before, such as area border routers. If a network link were to fail, only the routers inside that area would exchange routing update information. Area border routers filter the routing updates from separate areas and the backbone. Area border routers can communicate with each other and exchange routing update information, but they use special link-state messages that are a brief summarization of the LAN or WAN topology for their areas.
Figure 6.9 illustrates the use of dividing areas that represent physical regions with area border routers attached to the backbone.
Figure 6.9. Dividing physical regions into areas separated by area border routers.
Each city does not want to receive the routing updates from the other cities; therefore, these areas are separated by area border routers, which can and do exchange information between each other, but in a smaller link-state update.
You can also fine-tune OSPF routers to minimize the amount of updates that are unleashed on the network, and therefore minimize the reduction in network bandwidth. You can also fine-tune the rate of convergence, which is the time between the routers receiving the new routing information and the time the network routers have made the necessary adjustments in their routing tables.
Table 6.4 illustrates an example of the OSPF database. This output is from the following command:
Table 6.4. The Complete OSPF Database Taken from an Area Border Router (ABR)
Router Link States (Area 1) Link ID ADV Router Link Count 211.231.15.67 211.231.15. .231.16. .231.16.130 2 Summary Net Link States (Area 1) Link ID ADV Router 211.231.13.41 211.231.15.67 211.231.15.64 211.231.15.67 211.231.15. .231.15.67 Router Link States (Area 0) Link ID ADV Router Link Count 211.231.13.41 211.231.13. .231.15.67 211.231.15.67 1 Net Link States (Area 0) Link ID ADV Router 211.231.15.68 211.231.13.41 Summary Net Link States (Area 0) Link ID ADV Router 211.231.15.0 211.231.15.67 Summary ASB Link States (Area 0) Link ID ADV Router 211.231.16. .231.15.67 AS External Link States Link ID ADV Router Tag 0.0.0.0 211.231.16. .231.16. .231.16. OSPF Router with ID (211.231.15.67) (Process ID 10)
We can begin analyzing the results, first starting with the Router Link States section of Area 1, shown in Table 6.5.
Table 6.5. The Router Link States Section of Area 1 in the OSPF Database
Link ID ADV Router Link Count 211.231.15.67 211.231.15. .231.16. .231.16. The two entries represent two routers in this area. Both routers have two links to Area 1, as represented by the Link Count column.
We continue, skipping past the Summary Net Link States section, and on to the next Router Link States section, which is for Area 0, shown in Table 6.6.
Table 6.6. he Router Link States Section of Area 0 in the OSPF Database
Link ID ADV Router Age Link Count 211.231.13.41 211.231.13. .231.15.67 211.231.15. Once again, there are two routers in this area. The first router has three links to Area 0, and the second router has one link to Area 0.
The Summary ASB Link States of Area 1 are listed in Table 6.7.
Table 6.7. The Summary ASB Link States of Area 1 in the OSPF Database
Link ID ADV Router Age 211.231.16. .231.15. This gives you an indication of who the ASBR for the area is. The ASBR is a router with the address of 211.231.16.130.
The AS External Link States information contains information about destinations outside of our area, shown in Table 6.8.
Table 6.8. The AS External Link States in the OSPF Database
Link ID ADV Router Age Tag 0.0.0.0 211.231.16. .231.16. .231.16. Both of the two external links that are listed have been injected into our area from the OSPF.
Read full chapter
URL: /science/article/pii/B Multicasting: Issues and Networking Support
UPKAR VARSHNEY, in Multimedia Communications, .3 MULTICASTING IN IP-BASED NETWORKS
The Internet Protocol (IP) is the network layer protocol used in the Internet or Transmission Control Protocol/Internet Protocol (TCP/IP)-based networks and it provides best effort and connectionless service. The reliability, if required, is provided by upper-layer protocols. Unlike unicasting addresses, a single address is used for the entire multicast group. This is done by using class D of IP addresses that range from 224.0.0.0 to 239.255.255.255. This type of address really represents a list of receivers and not the individual receivers. Some of these addresses are well-known multicast addresses and the rest are transient addresses. The well-known addresses are published over the Internet, while transient addresses are allocated only for the duration of a certain multicast session. Before starting a multicast session, a class-D address is chosen by the group initiator [Diot et al., 1997]. In IP multicasting, the members can be located anywhere on the network and the sender does not need to know about the other members. The sender does not have to be a member of the multicast group it is transmitting to. To join a multicast group, a host informs a local multicast router, which in turn contacts other multicast routers, and so on. After the local multicast router joins the multicast session, the router periodically checks if any of the hosts are still members of that multicast group. As long as at least one host on its network remains a member, the multicast router continues to be a part of that group. If it hears no responses, it assumes that no one is interested in the multicast group and it stops being part of that multicast group. The multicast router to host communication uses Internet Group Multicast Protocol (IGMP), which is also used for managing group memberships with other multicast routers [Deering, 1989]. The Internet multicast also makes use of time-to-live (TTL) field to limit how far (how many hops) a packet can traverse to a receiver [Diot et al., 1997]. The IGMPv2 adds a low-latency leave to IGMP to allow a more prompt pruning of a group after all members in the subnetwork leave.
IP multicasting in the Internet has been implemented using MBone, a virtual overlay network that has been operational since 1992 [Eriksson, 1994]. Since most IP routers currently do not support multicast routing, the forwarding of multicast datagrams between “islands” of multicast-capable subnetworks is handled by “multicast routers” through tunnels, as shown in Figure 16.3. The tunnels are implemented by encapsulating IP packets destined for a multicast address within an IP packet, with the unicast address of the next multicast-capable router along the path. IP multicasting does not use TCP, but uses User Datagram Protocol (UDP) to avoid the acknowledgment implosion problem caused by the increased number of acknowledgments from multiple receivers for every message. That is why IP multicasting is considered a best-effort service; however, upper-layer protocols (application or reliable transport protocols) can be employed to provide reliable multicasting service. The other interesting issue is how to deal with traffic congestion issues in IP multicast, as no TCP is being used. Therefore, applications should attempt to deal with congestion and the amount of multicast data that can be put over an IP-based network.
FIGURE 16.3. IP multicasting in Mbone.
16.3.1 Routing Protocols for IP Multicast
There are several routing protocols that can be used to support IP multicast, such as Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF), and Protocol Independent Multicast (PIM), as shown in Table 16.2.
Table 16.2. Routing Protocols for IP Multicasting
Routing Protocol Tree Type Information Collection Comment DVMRP Source-based Using exchange between routers Not scalable MOSPF Source-based Link state database Not scalable PIM RP-rooted/source-based From routing table Supports both sparse and dense mode Both the DVMRP and MOSPF build a source-based multicast tree, but the way they collect information is different. In DVMRP [Waitzman et al., 1998] multicast routers exchange information on reverse path distances, while MOSPF uses routing information from the link state database, allowing multicast routers to build efficient source-based tree without flooding as used in DVMRP. Therefore, MOSPF is more efficient than DVMRP, but more computation, although on demand, is required.
Both the DVMRP and MOSPF do not scale well, so another routing protocol has been proposed. It is termed Protocol Independent Multicast (PIM) and has two modes of operation, sparse and dense, based on how the multicast users are distributed. In sparse-mode PIM, some points on the network are designated as rendezvous points (RPs) and an RP-rooted tree is constructed as follows. The highest IP-addressed router is chosen as the designated router (DR) on a network. The receiver’s DR sends explicit join messages to the RP. The sender’s DR sends register messages to the RP, which sends a join to sources. The packets will follow the RP-rooted shared tree, but the receiver (or router) may switch to the source’s shortest path tree. The densemode PIM is essentially the same as DVMRP, except that unicast routers are imported from existing routing tables rather than incorporating a specific unicast routing algorithm. That is why it is termed Protocol Independent Multicasting. Many vendors are supporting multicast communications in their routers and other equipment, such as the support for DVMRP and MOSPF in Ascend’s IP navigator software and the support for PIM in Cisco 7507 routers as used in vBNS [Jamison et al., 1998].
MBone uses UDP for end-to-end transmission control, IGMP for group management, and DVMRP for multicast routing. Another example of IP multicasting implementation is vBNS that uses native IP multicasting without using any overlay networks [Jamison et al., 1998].
16.3.2 Multimedia Support and IP Multicasting
Multimedia applications may require low latency and a certain minimum amount of bandwidth. Supporting such QoS for unicast has been an interesting research problem for many years and a significant amount of work has been done to provide solutions for QoS problems. However, these solutions may not be applied to multicast communications, as different receivers may have different QoS requirements, capabilities, and constraints. Resource reservation is difficult to set up in a multipoint environment; however, a guarantee of minimum bandwidth on a multicast route is not a problem [Zhang et al., 1993]. The Resource Reservation Protocol (RSVP) can be applied for multicasting and is capable of supporting different QoS for different receivers. It defines three categories of services: guaranteed service (bounds on throughput and delay), controlled load service (by approximating the performance of an unloaded datagram network), and best-effort service. It maintains a soft state and sends periodic “refresh” messages to maintain the state along the reserved paths, allowing for dynamic adaptation to group membership and changing routes [Zhang et al., 1993].
16.3.3 Multimedia Multicasting Applications on The MBone
There are many multicasting applications that have been designed and are currently being used over the MBone, as shown in Table 16.3. Audio and video applications do not receive any reliability or transport layer ordering, and these applications implement an application-level congestion control scheme. Audio packets are reordered in application playout buffer.
Table 16.3. Some Multimedia Applications on Mbone
Application Purpose Comment vic Video conferencing Uses RTP version 2 vat Audio conferencing nv Video conferencing Allows slow frame rates ivs Audio/video Simple Freephone Audio conferencing Special coding wb Shared workspace sdr Advertisement and joining of multicast conferences on MBone Similar to popular application called sd Shared Workspace wb is the most well-known shared workspace application on the MBone. The communication system provides reliable but not ordered multicast. An application-level recovery is performed if an out-of-order packet is received. Session Directory (sd) is not a group application but provides the possibility to perform multicast address allocation (randomly chosen). The sd has been obsoleted by sdr, which is designed to allow the advertisement and joining of multicast conferences on the MBone. More information on MBone, the applications currently supported, and how to join a multicast session over the MBone can be found from the references provided in the “For Further Reading” section.
Read full chapter
URL: /science/article/pii/B Which type of OSPF packet is used by a router?
OSPF uses Database Descriptor (DBD) packets for this purpose. The DBD packets are OSPF packet Type 2. The OSPF router summarizes the local database and the DBD packets carry a set of LSAs belonging to the database.
What are three types of OSPF packets?
Packet types for OSPF.
Hello packet. This packet is sent by the OMPROUTED server to discover OSPF neighbor routers and to establish bidirectional communications with them. … .
Database description packet. … .
Link-state update packet. … .
Link-state request packet. … .
Link-state acknowledgment packet..
What is Hello packet in OSPF?
A HELLO packet is a special data packet (message) that is sent out periodically from a router to establish and confirm network adjacency relationships to other routers in the Open Shortest Path First (OSPF) communications protocol.
Which of the following does Hello packet use to uniquely identify the originating router?
Router ID – A 32-bit value expressed in dotted decimal notation (an IPv4 address) used to uniquely identifying the originating router.