Network Working Group. Category: Informational. Hitachi Data Systems L. Lavu Bay Networks G. Duan Oracle J. Ma NewBridge H. Nah

Size: px
Start display at page:

Download "Network Working Group. Category: Informational. Hitachi Data Systems L. Lavu Bay Networks G. Duan Oracle J. Ma NewBridge H. Nah"

Transcription

1 Network Working Group Request for Comments: 2490 Category: Informational M. Pullen George Mason University R. Malghan Hitachi Data Systems L. Lavu Bay Networks G. Duan Oracle J. Ma NewBridge H. Nah George Mason University January 1999 Status of this Memo A Simulation Model for IP Multicast with RSVP This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package [4], with protocol procedures defined in the C language. The model was developed to allow investigation of performance constraints on routing but should have wide applicability in the Internet multicast/resource reservation community. We are making this model publicly available with the intention that it can be used to provide expanded studies of resource-reserved multicasting. Table of Contents 1. Background 2 2. The OPNET Simulation Environment 3 3. IP Multicast Model Address Format Network Layer Node layer 5 4. RSVP Model RSVP Application 15 Pullen, et. al. Informational [Page 1]

2 4.2 RSVP on Routers RSVP on Hosts Multicast Routing Model Interface Creation of multicast routing processor node Interfacing processor nodes Interrupt Generation Modifications of modules in the process model OSPF and MOSPF Models Init Idle BCOspfLsa BCMospfLsa Arr Hello_pks Mospfspfcalc Ospfspfcalc UpstrNode DABRA DVMRP Model Init Idle Probe_Send State Report_Send Prune _Send Graft_send Arr_Pkt Route_Calc Timer Simulation performance Future Work Security Considerations References 33 Authors Addresses 34 Full Copyright Statement Background The successful deployment of IP multicasting [1] and its availability in the Mbone has led to continuing increase in real-time multimedia Internet applications. Because the Internet has traditionally supported only a best-effort quality of service, there is considerable interest to create mechanisms that will allow adequate resources to be reserved in networks using the Internet protocol suite, such that the quality of real-time traffic such as video, voice, and distributed simulation can be sustained at specified levels. The RSVP protocol [2] has been developed for this purpose and is the subject of ongoing implementation efforts. Although the developers of RSVP have used simulation in their design process, no Pullen, et. al. Informational [Page 2]

3 simulation of IPmc with RSVP has been generally available for analysis of the performance and prediction of the behavior of these protocols. The simulation model described here was developed to fill this gap, and is explicitly intended to be made available to the IETF community. 2. The OPNET Simulation Environment The Optimized Network Engineering Tools (OPNET) is a commercial simulation product of the MIL3 company of Arlington, VA. It employs a Discrete Event Simulation approach that allows large numbers of closely-spaced events in a sizable network to be represented accurately and efficiently. OPNET uses a modeling approach where networks are built of components interconnected by perfect links that can be degraded at will. Each component s behavior is modeled as a state-transition diagram. The process that takes place in each state is described by a program in the C language. We believe this makes the OPNET-based models relatively easy to port to other modeling environments. This family of models is compatible with OPNET 3.5. The following sections describe the state-transition models and process code for the IPmc and RSVP models we have created using OPNET. Please note that an OPNET layer is not necessarily equivalent to a layer in a network stack, but shares with a stack layer the property that it is a highly modular software element with well defined interfaces. 3. IP Multicast Model The following processing takes place in the indicated modules. Each subsection below describes in detail a layer in the host and the router that can be simulated with the help of the corresponding OPNET network layer or node layer or the process layer, starting from physical layer. 3.1 Address format The OPNET IP model has only one type of addressing denoted by "X.Y" where X is 24 bits long and Y is 8 bits long, corresponding to an IPv4 Class C network. The X indicates the destination or the source network number and Y indicates the destination or the source node number. In our model X = 500 is reserved for multicast traffic. For multicast traffic the value of Y indicates the group to which the packet belongs. Pullen, et. al. Informational [Page 3]

4 3.2 Network Layer Figure 1 describes an example network topology built using the OPNET network editor. This network consists of two backbone routers BBR1, BBR2, three area border routers ABR1, ABR2, ABR3 and six subnets F1, through F6. As OPNET has no full duplex link model, each connecting link is modeled as two simplex links enabling bidirectional traffic Attributes Figure 1: Network Layer of Debug Model The attributes of the elements of the network layer are: a. Area Border Routers and Backbone Routers 1. IP address of each active interface of each router (network_id.node_id) 2. Service rate of the IP layer (packets/sec) 3. Transmission speeds of each active interface (bits/sec) b. Subnets 1. IP address of each active interface of the router in the subnet 2. IP address of the hosts in each of the subnet. 3. Service rate of the IP layer in the subnet router and the hosts. Pullen, et. al. Informational [Page 4]

5 c. Simplex links 1. Propagation delay in the links 2. The process model to be used for simulating the simplex links (this means whether animation is included or not) LAN Subnets Figure 2 shows the FDDI ring as used in a subnet. The subnet will have one router and one or more hosts. The router in the subnet is included to route the traffic between the FDDI ring or Ethernet in the corresponding subnet and the external network. The subnet router is connected on one end to Ethernet or FDDI ring and normally also is connected to an area border router on another interface (the area border routers may be connected to more than one backbone router). In the Ethernet all the hosts are connected to the bus, while in FDDI the hosts are interconnected in a ring as illustrated in Figure 2. Figure 2: FDDI Ring Subnet Layer FDDI provides general purpose networking at 100 Mb/sec transmission rates for large numbers of communicating stations configured in a ring topology. Use of ring bandwidth is controlled through a timed token rotation protocol, wherein stations must receive a token and meet with a set of timing and priority criteria before transmitting frames. In order to accommodate network applications in which response times are critical, FDDI provides for deterministic availability of ring bandwidth by defining a synchronous transmission service. Asynchronous frame transmission requests dynamically share the remaining ring bandwidth. Ethernet is a bus-based local area network (LAN) technology. The operation of the LAN is managed by a media access protocol (MAC) following the IEEE standard, providing Carrier Sense Multiple Access with Collision Detection (CSMA/CD) for the LAN channel. 3.3 Node layer This section discusses the internal structure of hosts and routers with the help of node level illustrations built using the Node editor of OPNET. Pullen, et. al. Informational [Page 5]

6 3.3.1 Basic OPNET elements The basic elements of a node level illustration are a. Processor nodes: Processor nodes are used for processing incoming packets and generating packets with a specified packet format. b. Queue node: Queue nodes are a superset of processor nodes. In addition to the capabilities of processor nodes, queue nodes also have capability to store packets in one or more queues. c. Transmitter and Receiver nodes: Transmitters simulate the link behavior effect of packet transmission and Receivers simulate the receiving effects of packet reception. The transmission rate is an attribute of the transmitter and receiving rate is an attribute of the receiver. These values together decide the transmission delay of a packet. d. Packet streams: Packet streams are used to interconnect the above described nodes. e. Statistic streams: Statistic streams are used to convey information between the different nodes: Processor, Queue, Transmitters and Receivers nodes respectively Host description The host model built using OPNET has a layered structure. Different from the OPNET layers (Network, Node and Process layer) that describe the network at different levels, protocol stack elements are implemented at OPNET nodes. Figure 3 shows the node level structure of a FDDI host. a. MAC queue node: The MAC interfaces on one side to the physical layer through the transmitter (phy_tx) and receiver (phy_rx) and also provides services to the IP layer. Use of ring bandwidth is controlled through a timed token rotation protocol, wherein hosts must receive a token and meet with a set of timing and priority criteria before transmitting frames. When a frame arrives at the MAC node, the node performs one of the following actions: 1. If the owner of the frame is this MAC, the MAC layer destroys the frame since the frame has finished circulating through the FDDI ring. 2. if the frame is destined for this host, the MAC layer makes a copy of the frame, decapsulates the frame and sends the descapsulated frame (packet) to the IP layer. The original frame is transmitted to the next host in the FDDI ring. Pullen, et. al. Informational [Page 6]

7 3. if the owner of the frame is any other host and the frame is not destined for this host, the frame is forwarded to the adjacent host. Figure 3: Node Level of Host b. ADDR_TRANS processor node: The next layer above the MAC layer is the addr_trans processor node. This layer provides service to the IP layer by carrying out the function of translating the IP address to physical interface address. This layer accepts packets from the IP layer with the next node information, maps the next node information to a physical address and forwards the packet for transmission. This service is required only in one direction from the IP layer to the MAC layer. Since queuing is not done at this level, a processor node is used to accomplish the address translation function, from IP to MAC address (ARP). c. IP queue node: Network routing/forwarding in the hierarchy is implemented here. IP layer provides service for the layers above which are the different higher level protocols by utilizing the Pullen, et. al. Informational [Page 7]

8 services provided by the MAC layer. For packets arriving from the MAC layer, the IP layer decapsulates the packet and forwards the information to an upper layer protocol based upon the value of the protocol ID in the IP header. For packets arriving from upper layer protocols, the IP layer obtains the destination address, calculates the next node address from the routing table, encapsulates it with a IP header and forwards the packet to the addr_trans node with the next node information. The IP node is a queue node. It is in this layer that packets incur delay which simulates the processing capability of a host and queueing for use of the outgoing link. A packet arrival to the IP layer will be queued and experience delay when it finds another packet already being transmitted, plus possibly other packets queued for transmission. The packets arriving at the IP layer are queued and operate with a first-in first-out (FIFO) discipline. The queue size, service rate of the IP layer are both promoted attributes, specified at the simulation run level by the environment file. d. IGMP processor node: The models described above are standard components available in OPNET libraries. We have added to these the host multicast protocol model IGMP_host, the router multicast model IGMP_gwy, and the unicast best-effort protocol model UBE. The IGMP_host node (Figure 4) is a process node. Packets are not queued in this layer. IGMP_host provides unique group management services for the multicast applications utilizing the services Figure 4: IGMP process on hosts Pullen, et. al. Informational [Page 8]

9 provided by the IP layer. IGMP_host maintains a single table which consists of group membership information of the application above the IGMP layer. The function performed by the IGMP_host layer depends upon the type of the packet received and the source of the packet. The IGMP_host layer expects certain type of packets from the application layer and from the network: 1. Accept join group requests from the application layer (which can be one or more applications): IGMP_host maintains a table which consists of the membership information for each group. When a application sends a join request, it requests to join a specific group N. The membership information is updated. This new group membership information has to be conveyed to the nearest router and to the MAC layer. If the IGMP_host is already a member ofthis group (i.e. if another application above the IGMP_host is a member of the group N), the IGMP_host does not have to send a message to the router or indicate to the MAC layer. If the IGMP_host is not a member currently, the IGMP_host generates a join request for the group N (this is called a "response" in RFC 1112) and forwards it to the IP layer to be sent to the nearest router. In addition the IGMP_host also conveys this membership information to the MAC layer interfacing to the physical layer through the OPNET "statistic wire" connected from the IGMP_host to the MAC layer, so that the MAC layer knows the membership information immediately and begins to accept the frames destined for the group N. (An OPNET statistic wire is a virtual path to send information between OPNET models.) 2. Accept queries arriving from the nearest router and send responses based on the membership information in the multicast table at the IGMP_host layer: A query is a message from a router inquiring each host on the router s interface about group membership information. When the IGMP_host receives a query, it looks up the multicast group membership table, to determine if any of the host s applications are registered for any group. If any registration exists, the IGMP_host schedules an event to generate a response after a random amount of time corresponding to each active group. The Ethernet example in Figure 5 and the description in the following section describes the scenario. H1 H2 H3 R Figure 5: An Ethernet example of IGMP response schedule Pullen, et. al. Informational [Page 9]

10 The router R interfaces with the subnet on one interface I1 and to reach the hosts. To illustrate this let us assume that hosts H1 and H3 are members of group N1 and H2 is a member of group N2. When the router sends a query, all the hosts receive the query at the same time t0. IGMP_host in H1 schedules an event to generate a response at a randomly generated time t1 (t1 >= t0) which will indicate the host H1 is a member of group N1. Similarly H2 will schedule an event to generate a response at t2 (t2 >= t0)to indicate membership in group N2 and H3 at t3 (t3 >= t0) to indicate membership in group N3. When the responses are generated, the responses are sent with destination address set to the multicast group address. Thus all member hosts of a group will receive the responses sent by the other hosts in the subnet who are members of the same group. In the above example if t1 < t3, IGMP_host in H1 will generate a response to update the membership in group N1 before H3 does and H3 will also receive this response in addition to the router. When IGMP_host in H3 receives the response sent by H1, IGMP_host in H3 cancels the event scheduled at time t3, since a response for that group has been sent to the router. To make this work, the events to generate response to queries are scheduled randomly, and the interval for scheduling the above described event is forced to be less than the interval at which router sends the queries. 3. Accept responses sent by the other hosts in the subnet if any application layer is a member of the group to which the packet is destined. 4. Accept terminate group requests from the Application layer. These requests are generated by application layer when a application decides to leave a group. The IGMP_host updates the group information table and subsequently will not send any response corresponding to this group (unless another application is a member of this group). When a router does not receive any response for a group in certain amount of time on a specific interface, membership of that interface is canceled in that group. e. Unicast best-effort (UBE) processor node: This node is used to generate a best effort traffic in the Internet based on the User Datagram Protocol (UDP). The objective of this node is to model the background traffic in a network. This traffic does not use the services provided by RSVP. UBE node aims to create the behaviors observed in a network which has one type of application using the services provided by RSVP to achieve specific levels of QoS and the best effort traffic which uses the services provided by only the underlying IP. The UBE node generates traffic to a randomly generated IP address so as to model competing traffic in the network from applications such as FTP. The packets generated are sent to the IP layer which routes Pullen, et. al. Informational [Page 10]

11 the packet based upon the information in the routing table. The attributes of the UBE node are: 1. Session InterArrival Time (IAT): is the variable used to schedule an event to begin a session. The UBE node generates an exponentially distributed random variable with mean Session IAT and begins to generate data traffic at that time. 2. Data IAT: When the UBE generates data traffic, the interarrival times between data packets is Data IAT. A decrease in the value of Data IAT increases the severity of congestion in the network. 3. Session-min and Session-max: When the UBE node starts generating data traffic it remains in that session for a random period which is uniformly distributed between Session-min and Session-max. f. Multicast Application processor node: The application layer consists of one or more application nodes which are process nodes. These nodes use the services provided by lower layer protocols IGMP, RSVP and IP. The Application layer models the requests and traffic generated by Application layer programs. Attributes of the application layer are: 1. Session IAT: is the variable used to schedule an event to begin a session. The Application node generates an exponentially distributed random variable with mean Session IAT and begins to generate information for a specific group at that time and also accept packets belonging to that group. 2. Data IAT: When Application node generates data traffic, the inter arrival time between the packets uses Data IAT variable as the argument. The distribution can be any of the available distribution functions in OPNET. 3. Session-min and Session-max: When an application joins a session the duration for which the application stays in that session is bounded by Session-min and Session-max. A uniformly distributed random variable between Session-min and Session-max is generated for this purpose. At any given time each node will have zero or one flow(s) of data. 4. NGRPS: This variable is used by the application generating multicast traffic to bound the value of the group to which an application requests the IGMP to join. The group is selected at random from the range [0,NGRPS-1] Router description There are two types of routers in the model, a router serving a subnet and a backbone router. A subnet router has all the functions of a backbone router and in addition also has a interface to the underlying subnet which can be either a FDDI network or a Ethernet subnet. In the following section the subnet router will be discussed in detail. Pullen, et. al. Informational [Page 11]

12 Figure 6 shows the node level model of a subnet router. Figure 6: Node Level of Gateway a. The queueing technique implemented in the router is a combination of input and output queueing. The nodes rx1 to rx10 are the receivers connected to incoming links. The router in Figure 6 has a physical interface to the FDDI ring or Ethernet, which consists of the queue node MAC, transmitter phy_tx, and the receiver phy_rx. The backbone routers will not have a MAC layer. The services provided and the functions of the MAC layer are the same as the MAC layer in the host discussed above. There is one major difference between the MAC node in a subnet router and that in a host. The MAC node in a subnet router accepts all arriving multicast packets unlike the MAC in a host Pullen, et. al. Informational [Page 12]

13 which accepts only the multicast packets for groups of which the host is a member. For this reason the statistic wire from the IGMP to MAC layer does not exist in a router (also because a subnet router does not have an application layer). b. Addr_trans: The link layer in the router hierarchy is the addr_trans processor node which provides the service of translating the IP address to a physical address. The addr_trans node was described above under the host model. c. IP layer: The router IP layer which provides services to the upper layer transport protocols and also performs routing based upon the information in the routing table. The IP layer maintains two routing tables and one group membership table. The tables used by the router model are: 1. Unicast routing table: This table is an single array of one dimension, which is used to route packets generated by the UDP process node in the hosts. If no route is known to a particular IP address, the corresponding entry is set to a default route. 2. Multicast routing table: This table is a N by I array where N is the maximum number of multicast groups in the model and I is the number of interfaces in the router. This table is used to route multicast packets. The routing table in a router is set by an upper layer routing protocol (see section 4 below). When the IP layer receives a multicast packet with a session_id corresponding to a session which is utilizing the MOSFP, it looks up the multicast routing table to obtain the next hop. 3. Group membership table: This table is used to maintain group membership information of all the interfaces of the router. This table which is also an N by I array is set by the IGMP layer protocol. The routing protocols use this information in the group membership table to calculate and set the routes in the Multicast routing table. Sub-queues: The IP node has three subqueues, which implement queuing based upon the priority of arriving packets from the neighboring routers or the underlying subnet. The queue with index 0 has the highest priority. When a packet arrives at the IP node, the packets are inserted into the appropriate sub-queue based on the priority of their traffic category: control traffic, resource- reserved traffic, or best effort traffic. A non-preemptive priority is used in servicing the packets. After the servicing, packets are sent to the one of the output queues or the MAC. The packets progress through these queues until the transmitter becomes available. Pullen, et. al. Informational [Page 13]

14 Attributes of the IP node are: 1. Unique IP address for each interface (a set of transmitter and receiver constitute an interface). 2. Service rate: the rate with which packets are serviced at the router. 3. Queue size: size of each of the sub queues used to store incoming packets based on the priority can be specified individually d. Output queues: The output queues perform the function of queueing the packets received by the IP layer when the transmitter is busy. A significant amount of queuing takes place in the output queues only if the throughput of the IP node approaches the transmission capacity of the links. The only attribute of the queue node is: Queue size: size of the queue in each queue node. If the queue is full when a packet is received, that packet is dropped. e. IGMP Node: Also modeled in the router is the IGMP for implementing multicasting, the routing protocol, and RSVP for providing specific QoS setup. The IGMP node implements the IGMP protocol as defined in RFC The IGMP node at a router (Figure 7) is different from the one at a host. The functions of the IGMP node at a router are: 1. IGMP node at a router sends queries at regular intervals on all its interfaces. 2. When IGMP receives a response to the queries sent, IGMP updates the multicast Group membership table in the IP node and triggers on MOSPF LSA update. 3. Every time the IGMP sends a query, it also updates the multicast group membership table in the IP node if no response has been received on for the group on any interface, indicating that a interface is no longer a member of that group. This update is done only on entries which indicate an active membership for a group on a interface where the router has not received a response for the last query sent. 4. The routing protocol (see ection 4 below) uses the information in the group membership table to calculate the routes and update the multicast routing table. 5. When the IGMP receives a query (an IGMP at router can receive a query from a directly connected neighboring router), the IGMP node creates a response for each of the groups it is a member of on all the interfaces except the one through which the query was received. 6. The IGMP node on a backbone router is disabled, because IGMP is only used when a router has hosts on its subnet. Pullen, et. al. Informational [Page 14]

15 4. RSVP model Figure 7: IGMP process on routers The current version of the RSVP model supports only fixed-filter reservation style. The following processing takes place in the indicated modules. The model is current with [2]. 4.1 RSVP Application Init Initializes all variables and loads the distribution functions for Multicast Group IDs, Data, termination of the session. Transit to Idle state after completing all the initializations Idle This state has transitions to two states, Join and Data_Send. It transit to Join state at the time that the application is scheduled to join a session or terminate the current session, transit to Data_Send state when the application is going to send data. Pullen, et. al. Informational [Page 15]

16 4.1.3 Join The Application will send a session call to local RSVP daemon. In response it receives the session Id from the Local daemon. This makes a sender or receiver call. The multicast group id is selected randomly from a uniform distribution. While doing a sender call the application will write all its sender information in a global session directory. If the application is acting as a receiver it will check for the sender information in the session directory for the multicast group that it wants to join to and make a receive call to the local RSVP daemon. Along with the session and receive calls, it makes an IGMP join call. If the application chooses to terminate the session to which it was registered, it will send a release call to the local RSVP daemon and a terminate call to IGMP daemon. After completing these functions it will return to the idle state Data_Send Creates a data packet and sends it to a multicast destination that it selects. It update a counter to keep track of how many packets that it has sent. This state on default returns to Idle state. 4.2 RSVP on Routers Figure 8 shows the process model of RSVP on routers Init This state calls a function called RouterInitialize which will initialize all the router variables. This state will go to Idle state after completing these functions Idle Idle state transit to Arr state upon receiving a packet Arr This state checks for the type of the packet arrived and calls the appropriate function depending on the type of message received. a. PathMsgPro: This function was invoked by the Arr state when a path message is received. Before it was called, OSPF routing had been recomputed to get the latest routing table for forwarding the Path Message. Pullen, et. al. Informational [Page 16]

17 Figure 8: RSVP process on routers 1. It first checks for a Path state block which has a matching destination address and if the sender port or sender address or destination port does not match the values of the Session object of the Path state block, it sends an path error message and returns. (At present the application does not send any error messages, we print this error message on the console.) 2. If a PSB is found whose Session Object and Sender Template Object matches with that of the path message received, the current PSB becomes the forwarding PSB. 3. Search for the PSB whose session and sender template matches the corresponding objects in the path message and whose incoming interface matches the IncInterface. If such a PSB is found and the if the Previous Hop Address, Next Hop Address, and SenderTspec Object doesn t match that of path message then the values of path message is copied into the path state block and Path Refresh Needed flag is turned on. If the Previous Hop Address, Next Hop Address of PSB differs from the path message then the Resv Refresh Pullen, et. al. Informational [Page 17]

18 Needed flag is also turned on, and the Current PSB is made equal to this PSB. 4. If a matching PSB is not found then a new PSB is created and and Path Refresh Needed Flag is turned on, and the Current PSB is made equal to this PSB. 5. If Path Refresh Needed Flag is on, Current PSB is copied into forwarding PSB and Path Refresh Sequence is executed. To execute this function called PathRefresh is used. Path Refresh is sent to every interface that is in the outgoing interfaces list of forwarding path state block. 6. Search for a Reservation State Block whose filter spec object matches with the Sender Template Object of the forwarding PSB and whose Outgoing Interface matches one of the entry in the forwarding PSB s outgoing interface list. If found then a Resv Refresh message to the Previous Hop Address in the forwarding PSB and execute the Update Traffic Control sequence. b. PathRefresh: This function is called from PathMsgPro. It creates the Path message sends the message through the outgoing interface that is specified by the PathMsgPro. c. ResvMsgPro: This function was invoked by the Arr state when a Resv message is received. 1. Determine the outgoing interface and check for the PSB whose Source Address and Session Objects match the ones in the Resv message. 2. If such a PSB is not found then send a ResvErr message saying that No Path Information is available. (We have not implemented this message, we only print an error message on the console.) 3. Check for incompatible styles and process the flow descriptor list to make reservations, checking the PSB list for the sender information. If no sender information is available through the PSB list then send an Error message saying that No Sender information. For all the matching PSBs found, if the Refresh PHOP list doesn t have the Previous Hop Address of the PSB then add the Previous Hop Address to the Refresh PHOP list. 4. Check for matching Reservation State Block (RSB) whose Session and Filter Spec Object matches that of Resv message. If no such RSB is found then create a new RSB from the Resv Message and set the NeworMod flag On. Call this RSB as activersb. Turn on the Resv Refresh Needed Flag. 5. If a matching RSB is found, call this as activersb and if the FlowSpec and Scope objects of this RSB differ from that of Resv Message copy the Resv message Flowspec and Scope objects to the ActiveRSB and set the NeworMod flag On. 6. Call the Update Traffic Control Sequence. This is done by calling the function UpdateTrafficControl Pullen, et. al. Informational [Page 18]

19 7. If Resv Refresh Needed Flag is On then send a ResvRefresh message for each Previous Hop in the Refresh PHOP List. This is done by calling the ResvRefresh function for every Previous Hop in the Refresh PHOP List. d. ResvRefresh: this function is called by both PathMsgPro and ResvMsgPro with RSB and Previous Hop as input. The function constructs the Resv Message from the RSB and sends the message to the Previous Hop. e. PathTearPro: This function is invoked by the Arr state when a PathTear message is received. 1. Search for PSB whose Session Object and Sender Template Object matches that of the arrived PathTear message. 2. If such a PSB is not found do nothing and return. 3. If a matching PSB is found, a PathTear message is sent to all the outgoing interfaces that are listed in the Outgoing Interface list of the PSB. 4. Search for all the RSB whose Filter Spec Object matches the Sender Template Object of the PSB and if the Outgoing Interface of this RSB is listed in the PSB s Outgoing interface list delete the RSB. 5. Delete the PSB and return. f. ResvTearPro: This function is invoked by the Arr state when a ResvTear message is received. 1. Determine the Outgoing Interface. 2. Process the flow descriptor list of the arrived ResvTear message. 3. Check for the RSB whose Session Object, Filter Spec Object matches that of ResvTear message and if there is no such RSB return. 4. If such an RSB is found and Resv Refresh Needed Flag is on send ResvTear message to all the Previous Hops that are in Refresh PHOP List. 5. Finally delete the RSB. g. ResvConfPro: This function is invoked by the Arr state when a ResvConf message is received. The Resv Confirm is forwarded to the IP address that was in the Resv Confirm Object of the received ResvConf message. h. UpdateTrafficControl: This function is called by PathMsgPro and ResvMsgPro and input to this function is RSB. 1. The RSB list is searched for a matching RSB that matches the Session Object, and Filter Spec Object with the input RSB. 2. Effective Kernel TC_Flowspec are computed for all these RSB s. 3. If the Filter Spec Object of the RSB doesn t match the one of the Filter Spec Object in the TC Filter Spec List then add the Filter Spec Object to the TC Filter Spec List. Pullen, et. al. Informational [Page 19]

20 4. If the FlowSpec Object of the input RSB is greater than the TC_Flowspec then turn on the Is_Biggest flag. 5. Search for the matching Traffic Control State Block(TCSB) whose Session Object, Outgoing Interface, and Filter Spec Object matches with those of the Input RSB. 6. If such a TCSB is not found create a new TCSB. 7. If matching TCSB is found modify the reservations. 8. If Is_Biggest flag is on turn on the Resv Refresh Needed Flag flag, else send a ResvConf Message to the IP address in the ResvConfirm Object of the input RSB pathmsg: The functions to be done by this state are done through the function call PathMsgPro described above resvmsg: The functions that would be done by this state are done through the function call ResvMsgPro described above ptearmsg: The functions that would be done by this state are done through the function call PathTearPro described above rtearmsg: The functions that would be done by this state are done through the function call ResvTearPro described above rconfmsg: The functions that would be done by this state are done through the function call ResvConfPro described above. 4.3 RSVP on Hosts Figure 9 shows the process of RSVP on hosts Init Initializes all the variables. Default transition to idle state idle Figure 9: RSVP process on hosts This state transit to the Arr state on packet arrival. Pullen, et. al. Informational [Page 20]

21 4.3.3 Arr This state calls the appropriate functions depending on the type of message received. Default transition to idle state. a. MakeSessionCall: This function is called from the Arr state whenever a Session call is received from the local application. 1. Search for the Session Information. 2. If one is found return the corresponding Session Id. 3. If the session information is not found assign a new session Id to the session to the corresponding session. 4. Make an UpCall to the local application with this Session Id. b. MakeSenderCall: This function is called from the Arr state whenever a Sender call is received from the local application. 1. Get the information corresponding to the Session Id and create a Path message corresponding to this session. 2. A copy of the packet is buffered and used by the host to send the PATH message periodically. 3. This packet is sent to the IP layer. c. MakeReserveCall: This function is called from the Arr state whenever a Reserve call is received from the local application. This function will create and send a Resv message. Also, the packet is buffered for later use. d. MakeReleaseCall: This function is called from the Arr state whenever a Release call is received from the local application. This function will generate a PathTear message if the local application is sender or generates a ResvTear message if the local application is receiver Session This state s function is performed by the MakeSessionCall function Sender This state s function is han by the MakeSenderCall function Reserve This state s function is performed by the MakeReserveCall function Release This state s function is performed by the MakeReleaseCall function. Pullen, et. al. Informational [Page 21]

22 5. Multicast Routing Model Interface Because this set of models was intended particularly to enable evaluation by simulation of various multicast routing protocols, we give particular attention in this section to the steps necessary to interface a routing protocol model to the other models. We have available implementations of DVMRP and OSPF, which we will describe below. Instructions for invoking these models are contained in a separate User s Guide for the models. 5.1 Creation of multicast routing processor node Interfacing a multicast routing protocol using the OPNET Simulation package requires the creation of a new routing processor node in the node editor and linking it via packet streams. Packet streams are unidirectional links used to interconnect processor nodes, queue nodes, transmitters and receiver nodes. A duplex connection between two nodes is represented by using two unidirectional links to connect the two nodes to and from each other. A multicast routing processor node is created in the node editor and links are created to and from the processors(duplex connection) that interact with this module, the IGMP processor node and the IP processor node. Within the node editor, a new processor node can be created by selecting the button for processor creation (plain gray node on the node editor control panel) and by clicking on the desired location in the node editor to place the node. Upon creation of the processor node, the name of the processor can be specified by right clicking on the mouse button and entering the name value on the attribute box presented. Links to and from this node are generated by selecting the packet stream button (represented by two gray nodes connected with a solid green arrow on the node editor control panel), left clicking on the mouse button to specify the source of the link and right clicking on the mouse button to mark the destination of the link. 5.2 Interfacing processor nodes The multicast routing processor node is linked to the IP processor node and the IGMP processor node each with a duplex connection. A duplex connection between two nodes is represented by two unidirectional links interconnecting them providing a bidirectional flow of information or interrupts, as shown in Figure 6. The IP processor node (in the subnet router) interfaces with the multicast routing processor node, the unicast routing processor node, the Resource Reservation processor node(rsvp), the ARP processor node( only on subnet routers and hosts), the IGMP processor node, and finally the MAC processor node (only on subnet routers and hosts) each with a duplex connection with exceptions for ARP and MAC nodes. Pullen, et. al. Informational [Page 22]

23 5.2.1 Interfacing ARP and MAC processor nodes The service of the ARP node is required only in the direction from the IP layer to the MAC layer(requiring only a unidirectional link from IP processor node to ARP processor node). The MAC processor node on the subnet router receives multicast packets destined for all multicast groups in the subnet, in contrast to the MAC node on subnet hosts which only receives multicast packets destined specifically for its multicast group. The MAC node connects to the IP processor node with a single uni-directional link from it to the IP node Interfacing IGMP, IP, and multicast routing processor nodes The IGMP processor node interacts with the multicast routing processor node, unicast routing processor node, and the IP processor node. Because the IGMP node is linked to the IP node, it is thus able to update the group membership table(in this model, the group membership table is represented by the local interface(interface 0) of the multicast routing table data structure) within the IP node. This update triggers a signal to the multicast routing processor node from the IGMP node causing it to reassess the multicast routing table within the IP node. If the change in the group membership table warrants a modification of the multicast routing table, the multicast routing processor node interacts with the IP node to modify the current multicast routing table according to the new group membership information updated by IGMP Modification of group membership table The change in the group membership occurs with the decision at a host to leave or join a particular multicast group. The IGMP process on the gateway periodically sends out queries to the IGMP processes on hosts within the subnet in an attempt to determine which hosts currently are receiving packets from particular groups. Not receiving a response for a pending IGMP host query specific to a group indicates to the gateway IGMP that no host belonging to the particular group exists in the subnet. This occurs when the last remaining member of a multicast group in the subnet leaves. In this case the IGMP processor node updates the group membership able and triggers a modification of the multicast routing table by alerting the multicast routing processor node. A prune message specific to the group is initiated and propagated upward establishing a prune state for the interface leading to the present subnet, effectively removing this subnet from the group-specific multicast spanning tree and potentially leading to additional pruning of spanning tree edges as the prune message travels higher up the tree. Joining a multicast group is also managed by the IGMP process which updates the group membership table leading to a possible modification of the multicast routing table. Pullen, et. al. Informational [Page 23]

24 Dependency on unicast routing protocol The multicast routing protocol is dependent on a unicast routing protocol (RIP or OSPF) to handle multicast routing. The next hop interface to the source of the packet received, or the upstream interface, is determined using the unicast routing protocol to trace the reverse path back to the source of the packet. If the packet received arrived on this upstream interface, then the packet can be propagated downstream through its downstream interfaces (excluding the interface in which the packet was received). Otherwise, the packet is deemed to be a duplicate and dropped, halting the propagation of the packet downstream. This repeated reverse path checking and broadcasting eventually generates the spanning tree for multicast routing of packets. To determine the reverse path forward interface of a received multicast packet propagated up from the IP layer, the multicast routing processor node retrieves a copy of the unicast routing table from the IP processor node and uses it to recalculate the multicast routing table in the IP processor node. 5.3 Interrupt Generation Using the OPNET tools, interrupts to the multicast routing processor node are generated in several ways. One is the arrival of a multicast packet along a packet stream (at the multicast routing processor node) when the packet is received by the MAC node and propagated up the IP node where upon discarding the IP header determination is made as to which upper layer protocol to send the packet. A second type of interrupt generation occurs by remote interrupts from the IGMP process alerting the multicast routing process of an update in the group membership table. A third occurs when the specific source/group (S,G) entry for a multicast packet received at the IP node does not exist in the current multicast routing table and a new entry needs to be created. The IP node generates an interrupt to the multicast routing processor node informing it to create a new source/group entry on the multicast routing table Types of interrupts The process interrupts generated within the OPNET model can be handled by specifying the types of interrupts and the conditions for the interrupts using the interrupt code, integer number representing the condition for a specific interrupt. The conditions for interrupts are specified on the interrupt stream linking the interrupt generating state and the state resulting from the interrupt. For self-interrupts (interrupts occurring among states within the same process), interrupts of type OPC_INTRPT_SELF are used. For remote interrupts (interprocess interrupts), the conditions for specific interrupts are specified from the idle state Pullen, et. al. Informational [Page 24]

25 to the state resulting from the interrupt within the remote process. The remote interrupts are of type, OPC_INTRPT_REMOTE. A third type of interrupt is the OPC_INTRPT_STRM, which is triggered when packets arrive via a packet stream, indicating its arrival. The condition of this interrupt is also specified from the idle state to the resultant state by the interrupt condition stream defined by a unique interrupt code. For all of these interrupts, the interrupt code is provided within the header block (written in C language) of the interrupted process. When the condition for the interrupt becomes true, a transition is made to the resultant state specified by the interrupt stream Conditions for interrupts Several interrupt connections exist to interface the IGMP processor node, IP processor node, and the multicast routing processor node with each other in the present OPNET Simulation Model. Also, the IP processor node interfaces with the unicast routing protocol which interfaces with the IGMP processor node. An OPC_INTRPT_STRM interrupt is generated when a multicast packet arrives via a packet stream from the IP processor node to the multicast routing processor node. A remote interrupt of type, OPC_INTRPT_REMOTE, is generated from the IGMP process to the IP process when a member of a group relinquishes membership from a particular group or a new member is added to a group. This new membership is updated in the group membership table located in the IP node by the IGMP process which also generates a remote interrupt to the multicast routing protocol process, causing a recalculation of the multicast routing table in the IP module. 5.4 Modifications of modules in the process model Modifications of routing protocol modules (in fact all of the modules in the process model) are made transparently throughout the network using the OPNET Simulation tools. An addition or modification of a routing module in any subnet will reflect on all the subnets. 6. OSPF and MOSPF Models OSPF and MOSPF models [5] are implemented in the OSPF model containing fourteen states. They only exist on routers. Figure 10 shows the process model. The following processing takes place in the indicated modules. 6.1 init This state initializes all the router variables. Default transition to idle state. Pullen, et. al. Informational [Page 25]

26 6.2 idle This state has several transitions. If a packet arrives it transits to arr state. Depending on interrupts received it will transit to BCOspfLsa, BCMospfLsa, hello_pks state. In future versions, links coming up or down will also cause a transition. 6.3 BCOspfLsa Transition to this state from idle state is executed whenever the condition send_ospf_lsa is true, which happens when the network is being initialized, and when ospf_lsa_refresh_timout occurs. This state will create Router, Network, Summary Link State Advertisements and pack all of them into an Link State Update packet. The Link State Update Packet is sent to the IP layer with a destination address of AllSPFRouters. 6.4 BCMospfLsa Figure 10: OSPF and MOSPF process model on routers Transition to this state from idle state is executed whenever the condition send_mospf_lsa is true. This state will create Group Membership Link State Advertisement and pack them into Mospf Link Pullen, et. al. Informational [Page 26]

27 State Update Packet. This Mospf Link State Update Packet is sent to IP layer with a destination address of AllSPFRouters. 6.5 arr The arr state checks the type of packet that is received upon a packet arrival. It calls the following functions depending on the protocol Id of the packet received. a. OspfPkPro: Depending on the type of OSPF/MOSPF packet received the function calls the following functions. 1. HelloPk_pro: This function is called whenever a hello packet is received. This function updates the router s neighbor information, which is later used while sending the different LSAs. 2. OspfLsUpdatePk_pro: This function is called when an OSPF LSA update packet is received (router LSA, network LSA, or summary LSA). If the Router is an Area Border Router or if the LSA belongs to the Area whose Area Id is the Routers Area Id, then it is searched to determine whether this LSA already exists in the Link State database. If it exists and if the existing LSA s LS Sequence Number is less than the received LSA s LS Sequence Number the existing LSA was replaced with the received one. The function processes the Network LSA only if it is a designated router or Area Border Router. It processes the Summary LSA only if the router is a Area Border Router. The function also turns on the trigger ospfspfcalc which is the condition for the transition from arr state to ospfspfcalc. 3. MospfLsUpdatePk_pro: This function is called when a MOSPF LSA update packet is received. It updates the group membership link state database of the router. 6.6 hello_pks Hello packets are created and sent with destination address of AllSPFRouters. Default transition to idle state. 6.7 mospfspfcalc The following functions are used to calculate the shortest path tree and routing table. This state transit to upstr_node upon detupstrnode condition. a. CandListInit: Depending upon the SourceNet of the datagram, the candidate lists are initialized. b. MospfCandAddPro: The vertex link is examined and if the other end of the link is not a stub network and is not already in the candidate list it is added to the candidate list after calculating the cost to that vertex. If this other end of the link is already on the shortest Pullen, et. al. Informational [Page 27]

28 path tree and the calculated cost is less than the one that shows in the shortest path tree entry update the shortest path tree to show the calculated cost. c. MospfSPFTreeCalc: The vertex that is closest to the root that is in the candidate list is added to the shortest path tree and its link is considered for possible inclusions in the candidate list. d. MCRoutetableCalc: Multicast routing table is calculated using the information of the MOSPF shortest Path tree. 6.8 ospfspfcalc The following functions are used in this state to calculate the shortest path tree and using this information the routing table. Transition to ospfspfcalc state on ospfcalc condition. This is set to one after processing all functions in the state. a. OspfCandidateAddPro: This function initializes the candidate list by examining the link state advertisement of the Router. For each link in this advertisement, if the other end of the link is a router or transit network and if it is not already in the shortest-path tree then calculate the distance between these vertices. If the other end of this link is not already on the candidate list or if the distance calculated is less than the value that appears for this other end add the other end of the link to candidate list. b. OspfSPTreeBuild: This function pulls each vertex from the candidate list that is closest to the root and adds it to the shortest path tree. In doing so it deletes the vertex from the candidate list. This function continues to do this until the candidate list is empty. c. OspfStubLinkPro: In this procedure the stub networks are added to shortest path tree. d. OspfSummaryLinkPro: If the router is an Area Border Router the summary links that it has received is examined. The route to the Area border router advertising this summary LSA is examined in the routing table. If one is found a routing table update is done by adding the route to the network specified in the summary LSA and the cost to this route is sum of the cost to area border router advertising this and the cost to reach this network from that area border router. e. RoutingTableCalc: This function updates the routing table by examining the shortest path tree data structure. Pullen, et. al. Informational [Page 28]

29 6.9 upstr_node This state does not do anything in the present model. It transitions to DABRA state DABRA If the router is an Area Border Router and the area is the source area then a DABRA message is constructed and send to all the downstream areas. Default transition to idle state. 7. DVMRP Model The DVMRP model is implemented based on reference [6], DVMRP version 3. There are nine states. The DVMRP process only exists on Routers. Figure 11 shows the states of the DVMRP process. 7.1 Init Initialize all variables, routing table and forwarding table and load the simulation parameters. It will transit to the Idle state after completing all the initializations. 7.2 Idle The simulation waits for the next scheduled event or remotely invoked event in the Idle State and transit to the state accordingly. In the DVMRP model, Idle State has transitions to Probe_Send, Report_Send, Prune_Send, Graft_Send, Arr_Pkt, Route_Calc and Timer states. 7.3 Probe_Send State A DVMRP router sends Probe messages periodically to inform other DVMRP routers that it is operational. A DVMRP router lists all its known neighbors addresses in the Probe message and sends it to All- DVMRP-Routers address. The routers will not process any message that comes from an unknown neighbor. 7.4 Report_Send To avoid sending Report at the same time for all DVMRP routers, the interval between two Report messages is uniformly distributed with average 60 seconds. The router lists source router s address, upstream router s address and metric of all sources into the Report message and sends it to All-DVMRP-Routers address. Pullen, et. al. Informational [Page 29]

30 7.5 Prune_Send Figure 11. DVMRP process on routers The transition to this state is triggered by the local IGMP process. When a host on the subnetwork drops from a group, the IGMP process asks DVMRP to see if the branch should be pruned. The router obtains the group number from IGMP and checks the IP Multicast membership table to find out if there is any group member that is still in the group. If the router determines that the last host has resigned, it goes through the entire forwarding table to locate all sources for that group. The router sends Prune message, containing source address, group address and prune lifetime, separately for each (source, group) pair and records the row as pruned in the forwarding table. 7.6 Graft_Send The transition to this state is triggered by the local IGMP process. Once a multicast delivery has been pruned, Graft messages are necessary when a host in the local subnetwork joins into the group. A Graft message sent to the upstream router should be acknowledged hop by hop to the root of the tree guaranteeing end-to-end delivery. Pullen, et. al. Informational [Page 30]

Institute of Computer Technology - Vienna University of Technology. L73 - IP QoS Integrated Services Model. Integrated Services Model

Institute of Computer Technology - Vienna University of Technology. L73 - IP QoS Integrated Services Model. Integrated Services Model Integrated Services Model IP QoS IntServ Integrated Services Model Resource Reservation Protocol (RSVP) Agenda Integrated Services Principles Resource Reservation Protocol RSVP Message Formats RSVP in

More information

Design Intentions. IP QoS IntServ. Agenda. Design Intentions. L73 - IP QoS Integrated Services Model. L73 - IP QoS Integrated Services Model

Design Intentions. IP QoS IntServ. Agenda. Design Intentions. L73 - IP QoS Integrated Services Model. L73 - IP QoS Integrated Services Model Design Intentions Integrated Services Model IP QoS IntServ Integrated Services Model Resource Reservation Protocol (RSVP) The Internet was based on a best effort packet delivery service, but nowadays the

More information

What is Multicasting? Multicasting Fundamentals. Unicast Transmission. Agenda. L70 - Multicasting Fundamentals. L70 - Multicasting Fundamentals

What is Multicasting? Multicasting Fundamentals. Unicast Transmission. Agenda. L70 - Multicasting Fundamentals. L70 - Multicasting Fundamentals What is Multicasting? Multicasting Fundamentals Unicast transmission transmitting a packet to one receiver point-to-point transmission used by most applications today Multicast transmission transmitting

More information

Multicast Communications

Multicast Communications Multicast Communications Multicast communications refers to one-to-many or many-tomany communications. Unicast Broadcast Multicast Dragkedja IP Multicasting refers to the implementation of multicast communication

More information

ITEC310 Computer Networks II

ITEC310 Computer Networks II ITEC310 Computer Networks II Chapter 22 Network Layer:, and Routing Department of Information Technology Eastern Mediterranean University Objectives 2/131 After completing this chapter you should be able

More information

(RSVP) Speaker: Dr. Whai-En Chen

(RSVP) Speaker: Dr. Whai-En Chen Resource ReSerVation Protocol (RSVP) Speaker: Dr. Whai-En Chen Assistant Professor Institute of Computer Science and Information Engineering National Ilan University (NIU) Email: wechen@niu.edu.tw The

More information

RSVP and the Integrated Services Architecture for the Internet

RSVP and the Integrated Services Architecture for the Internet RSVP and the Integrated Services Architecture for the Internet N. C. State University CSC557 Multimedia Computing and Networking Fall 2001 Lecture # 20 Roadmap for Multimedia Networking 2 1. Introduction

More information

draft-pullen-qos-sim-models-03.txt George Mason University P. Singh OPNET Technologies November 2002

draft-pullen-qos-sim-models-03.txt George Mason University P. Singh OPNET Technologies November 2002 Internet Draft Expires: May 2003 draft-pullen-qos-sim-models-03.txt M. Pullen Y. Huang L. Huang George Mason University P. Singh OPNET Technologies November 2002 Expanded Simulation Models for IntServ

More information

MULTICAST EXTENSIONS TO OSPF (MOSPF)

MULTICAST EXTENSIONS TO OSPF (MOSPF) MULTICAST EXTENSIONS TO OSPF (MOSPF) Version 2 of the Open Shortest Path First (OSPF) routing protocol is defined in RFC-1583. It is an Interior Gateway Protocol (IGP) specifically designed to distribute

More information

Advanced Network Training Multicast

Advanced Network Training Multicast Division of Brocade Advanced Network Training Multicast Larry Mathews Systems Engineer lmathews@brocade.com Training Objectives Session will concentrate on Multicast with emphasis on Protocol Independent

More information

Multicast routing protocols

Multicast routing protocols Multicast routing protocols IGMP IP Group Management Protocol PIM Protocol Independent Multicast MOSPF Multicast OSPF DVMRP DV Multicast Routing Protocol E7310-Multicast-2/Comnet 1 Multicast in local area

More information

IP Multicast Technology Overview

IP Multicast Technology Overview IP multicast is a bandwidth-conserving technology that reduces traffic by delivering a single stream of information simultaneously to potentially thousands of businesses and homes. Applications that take

More information

Chapter 16 Networking

Chapter 16 Networking Chapter 16 Networking Outline 16.1 Introduction 16.2 Network Topology 16.3 Network Types 16.4 TCP/IP Protocol Stack 16.5 Application Layer 16.5.1 Hypertext Transfer Protocol (HTTP) 16.5.2 File Transfer

More information

Lab 4: Routing using OSPF

Lab 4: Routing using OSPF Network Topology:- Lab 4: Routing using OSPF Device Interface IP Address Subnet Mask Gateway/Clock Description Rate Fa 0/0 172.16.1.17 255.255.255.240 ----- R1 LAN R1 Se 0/0/0 192.168.10.1 255.255.255.252

More information

Multicast Communications. Slide Set were original prepared by Dr. Tatsuya Susa

Multicast Communications. Slide Set were original prepared by Dr. Tatsuya Susa Multicast Communications Slide Set were original prepared by Dr. Tatsuya Susa Outline 1. Advantages of multicast 2. Multicast addressing 3. Multicast Routing Protocols 4. Multicast in the Internet 5. IGMP

More information

CS High Speed Networks. Dr.G.A.Sathish Kumar Professor EC

CS High Speed Networks. Dr.G.A.Sathish Kumar Professor EC CS2060 - High Speed Networks Dr.G.A.Sathish Kumar Professor EC UNIT V PROTOCOLS FOR QOS SUPPORT UNIT V PROTOCOLS FOR QOS SUPPORT RSVP Goals & Characteristics RSVP operations, Protocol Mechanisms Multi

More information

Introduction to OSPF

Introduction to OSPF Introduction to OSPF ISP/IXP Workshops ISP/IXP Workshops 1999, Cisco Systems, Inc. 1 Agenda OSPF Primer OSPF in Service Provider Networks OSPF BCP - Adding Networks OSPF Command Summary 2 OSPF Primer 3

More information

HP Routing Switch Series

HP Routing Switch Series HP 12500 Routing Switch Series EVI Configuration Guide Part number: 5998-3419 Software version: 12500-CMW710-R7128 Document version: 6W710-20121130 Legal and notice information Copyright 2012 Hewlett-Packard

More information

Table of Contents 1 Static Routing Configuration RIP Configuration 2-1

Table of Contents 1 Static Routing Configuration RIP Configuration 2-1 Table of Contents 1 Static Routing Configuration 1-1 Introduction 1-1 Static Route 1-1 Default Route 1-1 Application Environment of Static Routing 1-1 Configuring a Static Route 1-2 Configuration Prerequisites

More information

Why multicast? The concept of multicast Multicast groups Multicast addressing Multicast routing protocols MBONE Multicast applications Conclusions

Why multicast? The concept of multicast Multicast groups Multicast addressing Multicast routing protocols MBONE Multicast applications Conclusions Tuomo Karhapää tuomo.karhapaa@otaverkko.fi Otaverkko Oy Why multicast? The concept of multicast Multicast groups Multicast addressing Multicast routing protocols MBONE Multicast applications Conclusions

More information

ETSF10 Internet Protocols Routing on the Internet

ETSF10 Internet Protocols Routing on the Internet ETSF10 Internet Protocols Routing on the Internet 2013, Part 2, Lecture 1.2 Jens Andersson (Kaan Bür) Routing on the Internet Unicast routing protocols (part 2) [ed.5 ch.20.3] Multicast routing, IGMP [ed.5

More information

Introduction to OSPF

Introduction to OSPF Introduction to OSPF 1 OSPF Open Shortest Path First Link state or SPF technology Developed by OSPF working group of IETF (RFC 1247) OSPFv2 standard described in RFC2328 Designed for: TCP/IP environment

More information

Introduction to OSPF OSPF. Link State Routing. Link State. Fast Convergence. Low Bandwidth Utilisation

Introduction to OSPF OSPF. Link State Routing. Link State. Fast Convergence. Low Bandwidth Utilisation Introduction to OSPF ISP/IP Workshops OSPF Open Shortest Path First Link state or SPF technology Developed by OSPF working group of IETF (RFC 47) Designed for TCP/IP Internet environment Fast convergence

More information

Introduction to OSPF

Introduction to OSPF Introduction to OSPF ISP/IXP Workshops ISP/IXP Workshops 1999, Cisco Systems, Inc. 1 OSPF Dynamic Routing Protocol Link State technology Runs over IP, protocol 89 Designed by IETF for TCP/IP Supports VLSM

More information

Computer Networks. Routing

Computer Networks. Routing Computer Networks Routing Topics Link State Routing (Continued) Hierarchical Routing Broadcast Routing Sending distinct packets Flooding Multi-destination routing Using spanning tree Reverse path forwarding

More information

OSPF Commands. Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols IP2R-61

OSPF Commands. Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols IP2R-61 OSPF Commands Use the commands in this chapter to configure and monitor the Open Shortest Path First (OSPF) routing protocol. For OSPF configuration information and examples, refer to the Configuring OSPF

More information

Multicast and Quality of Service. Internet Technologies and Applications

Multicast and Quality of Service. Internet Technologies and Applications Multicast and Quality of Service Internet Technologies and Applications Aims and Contents Aims Introduce the multicast and the benefits it offers Explain quality of service and basic techniques for delivering

More information

Table of Contents 1 PIM Configuration 1-1

Table of Contents 1 PIM Configuration 1-1 Table of Contents 1 PIM Configuration 1-1 PIM Overview 1-1 Introduction to PIM-DM 1-2 How PIM-DM Works 1-2 Introduction to PIM-SM 1-4 How PIM-SM Works 1-5 Introduction to Administrative Scoping in PIM-SM

More information

Integrated Services - Overview

Integrated Services - Overview Multicast QoS Need bandwidth/delay guarantees On many links unknown to sender Fortunately QoS development after multicast Takes multicast into account RSVP reservations from receivers toward sender rules

More information

RSVP Support for RTP Header Compression, Phase 1

RSVP Support for RTP Header Compression, Phase 1 RSVP Support for RTP Header Compression, Phase 1 The Resource Reservation Protocol (RSVP) Support for Real-Time Transport Protocol (RTP) Header Compression, Phase 1 feature provides a method for decreasing

More information

This chapter describes how to configure the Cisco ASA to use the multicast routing protocol.

This chapter describes how to configure the Cisco ASA to use the multicast routing protocol. This chapter describes how to configure the Cisco ASA to use the multicast routing protocol. About, page 1 Guidelines for, page 4 Enable, page 4 Customize, page 5 Monitoring for PIM, page 16 Example for,

More information

RSVP 1. Resource Control and Reservation

RSVP 1. Resource Control and Reservation RSVP 1 Resource Control and Reservation RSVP 2 Resource Control and Reservation policing: hold sources to committed resources scheduling: isolate flows, guarantees resource reservation: establish flows

More information

CSCE 463/612 Networks and Distributed Processing Spring 2018

CSCE 463/612 Networks and Distributed Processing Spring 2018 CSCE 463/612 Networks and Distributed Processing Spring 2018 Network Layer V Dmitri Loguinov Texas A&M University April 17, 2018 Original slides copyright 1996-2004 J.F Kurose and K.W. Ross Chapter 4:

More information

Resource Control and Reservation

Resource Control and Reservation 1 Resource Control and Reservation Resource Control and Reservation policing: hold sources to committed resources scheduling: isolate flows, guarantees resource reservation: establish flows 2 Usage parameter

More information

===================================================================== Exercises =====================================================================

===================================================================== Exercises ===================================================================== ===================================================================== Exercises ===================================================================== 1 Chapter 1 1) Design and describe an application-level

More information

Multicast Communications. Tarik Čičić, 4. March. 2016

Multicast Communications. Tarik Čičić, 4. March. 2016 Multicast Communications Tarik Čičić, 4. March. 06 Overview One-to-many communication, why and how Algorithmic approach: Steiner trees Practical algorithms Multicast tree types Basic concepts in multicast

More information

IPv6 PIM. Based on the forwarding mechanism, IPv6 PIM falls into two modes:

IPv6 PIM. Based on the forwarding mechanism, IPv6 PIM falls into two modes: Overview Protocol Independent Multicast for IPv6 () provides IPv6 multicast forwarding by leveraging static routes or IPv6 unicast routing tables generated by any IPv6 unicast routing protocol, such as

More information

Real-Time Applications. Delay-adaptive: applications that can adjust their playback point (delay or advance over time).

Real-Time Applications. Delay-adaptive: applications that can adjust their playback point (delay or advance over time). Real-Time Applications Tolerant: can tolerate occasional loss of data. Intolerant: cannot tolerate such losses. Delay-adaptive: applications that can adjust their playback point (delay or advance over

More information

Dr.S.Ravi 1, A. Ramasubba Reddy 2, Dr.V.Jeyalakshmi 3 2 PG Student- M.Tech. VLSI and Embedded System 1, 3 Professor

Dr.S.Ravi 1, A. Ramasubba Reddy 2, Dr.V.Jeyalakshmi 3 2 PG Student- M.Tech. VLSI and Embedded System 1, 3 Professor RSVP Protocol Used in Real Time Application Networks Dr.S.Ravi 1, A. Ramasubba Reddy 2, Dr.V.Jeyalakshmi 3 2 PG Student- M.Tech. VLSI and Embedded System 1, 3 Professor Dept. Electronics and Communication

More information

List of groups known at each router. Router gets those using IGMP. And where they are in use Where members are located. Enhancement to OSPF

List of groups known at each router. Router gets those using IGMP. And where they are in use Where members are located. Enhancement to OSPF Multicast OSPF OSPF Open Shortest Path First Link State Protocol Use Dijkstra s algorithm (SPF) Calculate shortest path from the router to every possible destination Areas Limit the information volume

More information

Multicast overview. Introduction to multicast. Information transmission techniques. Unicast

Multicast overview. Introduction to multicast. Information transmission techniques. Unicast Contents Multicast overview 1 Introduction to multicast 1 Information transmission techniques 1 Multicast features 3 Common notations in multicast 4 Multicast advantages and applications 4 Multicast models

More information

Table of Contents 1 OSPF Configuration 1-1

Table of Contents 1 OSPF Configuration 1-1 Table of Contents 1 OSPF Configuration 1-1 Introduction to OSPF 1-1 Basic Concepts 1-2 OSPF Area Partition 1-4 Router Types 1-7 Classification of OSPF Networks 1-9 DR and BDR 1-9 OSPF Packet Formats 1-11

More information

Topic: Multicast routing

Topic: Multicast routing Topic: Multicast routing What you will learn Broadcast routing algorithms Multicasting IGMP Multicast routing algorithms Multicast routing in the Internet Multicasting 1/21 Unicasting One source node and

More information

Multicast Technology White Paper

Multicast Technology White Paper Multicast Technology White Paper Keywords: Multicast, IGMP, IGMP Snooping, PIM, MBGP, MSDP, and SSM Mapping Abstract: The multicast technology implements high-efficiency point-to-multipoint data transmission

More information

AN RSVP MODEL FOR OPNET SIMULATOR WITH AN INTEGRATED QOS ARCHITECTURE

AN RSVP MODEL FOR OPNET SIMULATOR WITH AN INTEGRATED QOS ARCHITECTURE AN RSVP MODEL FOR OPNET SIMULATOR WITH AN INTEGRATED QOS ARCHITECTURE Sibel Tarıyan Özyer (a), Reza Hassanpour (b) (a)(b) Department of Computer Engineering, Çankaya University, Ankara Turkey (a) tariyan@cankaya.edu.tr,

More information

1: Review Of Semester Provide an overview of encapsulation.

1: Review Of Semester Provide an overview of encapsulation. 1: Review Of Semester 1 1.1.1.1. Provide an overview of encapsulation. Networking evolves to support current and future applications. By dividing and organizing the networking tasks into separate layers/functions,

More information

Contents. Configuring EVI 1

Contents. Configuring EVI 1 Contents Configuring EVI 1 Overview 1 Layer 2 connectivity extension issues 1 Network topologies 2 Terminology 3 Working mechanism 4 Placement of Layer 3 gateways 6 ARP flood suppression 7 Selective flood

More information

ICS 351: Today's plan. routing protocol comparison encapsulation network dynamics multicasting in general IP multicasting IGMP PIM

ICS 351: Today's plan. routing protocol comparison encapsulation network dynamics multicasting in general IP multicasting IGMP PIM ICS 351: Today's plan routing protocol comparison encapsulation network dynamics multicasting in general IP multicasting IGMP PIM what routing is not: Ethernet switching does not use IP addresses in any

More information

ETSF10 Internet Protocols Routing on the Internet

ETSF10 Internet Protocols Routing on the Internet ETSF10 Internet Protocols Routing on the Internet 2014, Part 2, Lecture 1.2 Jens Andersson Internet Hierarchy 2014-11-10 ETSF05/ETSF05/ETSF10 - Internet Protocols 2 Hierarchical Routing aggregate routers

More information

CompSci 356: Computer Network Architectures. Lecture 8: Spanning Tree Algorithm and Basic Internetworking Ch & 3.2. Xiaowei Yang

CompSci 356: Computer Network Architectures. Lecture 8: Spanning Tree Algorithm and Basic Internetworking Ch & 3.2. Xiaowei Yang CompSci 356: Computer Network Architectures Lecture 8: Spanning Tree Algorithm and Basic Internetworking Ch 3.1.5 & 3.2 Xiaowei Yang xwy@cs.duke.edu Review Past lectures Single link networks Point-to-point,

More information

Modelling a Video-on-Demand Service over an Interconnected LAN and ATM Networks

Modelling a Video-on-Demand Service over an Interconnected LAN and ATM Networks Modelling a Video-on-Demand Service over an Interconnected LAN and ATM Networks Kok Soon Thia and Chen Khong Tham Dept of Electrical Engineering National University of Singapore Tel: (65) 874-5095 Fax:

More information

EEC-684/584 Computer Networks

EEC-684/584 Computer Networks EEC-684/584 Computer Networks Lecture 14 wenbing@ieee.org (Lecture nodes are based on materials supplied by Dr. Louise Moser at UCSB and Prentice-Hall) Outline 2 Review of last lecture Internetworking

More information

McGill University - Faculty of Engineering Department of Electrical and Computer Engineering

McGill University - Faculty of Engineering Department of Electrical and Computer Engineering McGill University - Faculty of Engineering Department of Electrical and Computer Engineering ECSE 494 Telecommunication Networks Lab Prof. M. Coates Winter 2003 Experiment 5: LAN Operation, Multiple Access

More information

Implementing IPv6 Multicast

Implementing IPv6 Multicast Finding Feature Information, page 1 Information About Routing, page 1, page 8 Finding Feature Information Your software release may not support all the features documented in this module. For the latest

More information

Chapter 12 Network Protocols

Chapter 12 Network Protocols Chapter 12 Network Protocols 1 Outline Protocol: Set of defined rules to allow communication between entities Open Systems Interconnection (OSI) Transmission Control Protocol/Internetworking Protocol (TCP/IP)

More information

3. Evaluation of Selected Tree and Mesh based Routing Protocols

3. Evaluation of Selected Tree and Mesh based Routing Protocols 33 3. Evaluation of Selected Tree and Mesh based Routing Protocols 3.1 Introduction Construction of best possible multicast trees and maintaining the group connections in sequence is challenging even in

More information

Exercises to Communication Systems

Exercises to Communication Systems Exercises to Communication Systems IP Multicast Additional Slides Dr.-Ing. Falko Dressler Department of Computer Science 7 University of Erlangen ÜKS, WS 05/06 1 IP Multicast Introduction Internet Group

More information

Novell TCP IP for Networking Professionals.

Novell TCP IP for Networking Professionals. Novell 050-649 TCP IP for Networking Professionals http://killexams.com/exam-detail/050-649 I. RECV (Receive) J. RETR (Retrieve) Answer: Pending, Please email feedback to support@hotcerts.com QUESTION:

More information

IP Multicast. Overview. Casts. Tarik Čičić University of Oslo December 2001

IP Multicast. Overview. Casts. Tarik Čičić University of Oslo December 2001 IP Multicast Tarik Čičić University of Oslo December 00 Overview One-to-many communication, why and how Algorithmic approach (IP) multicast protocols: host-router intra-domain (router-router) inter-domain

More information

Outline. Routing. Introduction to Wide Area Routing. Classification of Routing Algorithms. Introduction. Broadcasting and Multicasting

Outline. Routing. Introduction to Wide Area Routing. Classification of Routing Algorithms. Introduction. Broadcasting and Multicasting Outline Routing Fundamentals of Computer Networks Guevara Noubir Introduction Broadcasting and Multicasting Shortest Path Unicast Routing Link Weights and Stability F2003, CSG150 Fundamentals of Computer

More information

The Internet. 9.1 Introduction. The Internet is a global network that supports a variety of interpersonal and interactive multimedia applications.

The Internet. 9.1 Introduction. The Internet is a global network that supports a variety of interpersonal and interactive multimedia applications. The Internet 9.1 Introduction The Internet is a global network that supports a variety of interpersonal and interactive multimedia applications. Associated with each access network - ISP network, intranet,

More information

CS610 Computer Network Final Term Papers Solved MCQs with reference by Virtualians Social Network

CS610 Computer Network Final Term Papers Solved MCQs with reference by Virtualians Social Network CS610 Computer Network Final Term Papers Solved MCQs with reference by Virtualians Social Network Question No: 1( M a r k s: 1 ) A ---------- Relies on the hardware manufacturer to assign a unique physical

More information

Hierarchical Routing. Our routing study thus far - idealization all routers identical network flat not true in practice

Hierarchical Routing. Our routing study thus far - idealization all routers identical network flat not true in practice Hierarchical Routing Our routing study thus far - idealization all routers identical network flat not true in practice scale: with 200 million destinations: can t store all destinations in routing tables!

More information

Networking: Network layer

Networking: Network layer control Networking: Network layer Comp Sci 3600 Security Outline control 1 2 control 3 4 5 Network layer control Outline control 1 2 control 3 4 5 Network layer purpose: control Role of the network layer

More information

Resource Reservation Protocol

Resource Reservation Protocol 48 CHAPTER Chapter Goals Explain the difference between and routing protocols. Name the three traffic types supported by. Understand s different filter and style types. Explain the purpose of tunneling.

More information

IPv6 Routing: OSPFv3

IPv6 Routing: OSPFv3 Open Shortest Path First version 3 (OSPFv3) is an IPv4 and IPv6 link-state routing protocol that supports IPv6 and IPv4 unicast address families (AFs). Finding Feature Information, page 1 Prerequisites

More information

Table of Contents. Cisco Introduction to EIGRP

Table of Contents. Cisco Introduction to EIGRP Table of Contents Introduction to EIGRP...1 Introduction...1 Before You Begin...1 Conventions...1 Prerequisites...1 Components Used...1 What is IGRP?...2 What is EIGRP?...2 How Does EIGRP Work?...2 EIGRP

More information

II. Principles of Computer Communications Network and Transport Layer

II. Principles of Computer Communications Network and Transport Layer II. Principles of Computer Communications Network and Transport Layer A. Internet Protocol (IP) IPv4 Header An IP datagram consists of a header part and a text part. The header has a 20-byte fixed part

More information

Multicast routing Draft

Multicast routing Draft Multicast routing Draft Lucia Tudose Nokia Research Center E-mail: tudose@research.nokia.com Abstract Multicast routing is establishing a tree which is routed from the source node and contains all the

More information

Multiple LAN Internet Protocol Converter (MLIC) for Multimedia Conferencing

Multiple LAN Internet Protocol Converter (MLIC) for Multimedia Conferencing Multiple LAN Internet Protocol Converter (MLIC) for Multimedia Conferencing Tat Chee Wan (tcwan@cs.usm.my) R. Sureswaran (sures@cs.usm.my) K. Saravanan (sara@network2.cs.usm.my) Network Research Group

More information

Auxiliary protocols. tasks that IP does not handle: Routing table management (RIP, OSPF, etc.). Congestion and error reporting (ICMP).

Auxiliary protocols. tasks that IP does not handle: Routing table management (RIP, OSPF, etc.). Congestion and error reporting (ICMP). Auxiliary protocols IP is helped by a number of protocols that perform specific tasks that IP does not handle: Routing table management (RIP, OSPF, etc.). Congestion and error reporting (ICMP). Multicasting

More information

Medium Access Protocols

Medium Access Protocols Medium Access Protocols Summary of MAC protocols What do you do with a shared media? Channel Partitioning, by time, frequency or code Time Division,Code Division, Frequency Division Random partitioning

More information

Internet Multicast Routing

Internet Multicast Routing Internet Multicast Routing. group addressing class D IP addresses 1110 Multicast Group ID. link layer multicast 28 bits. two protocol functions group management IGMP route establishment DVMRP, MOSPF, CBT,

More information

DD2490 p IP Multicast routing. Multicast routing. Olof Hagsand KTH CSC

DD2490 p IP Multicast routing. Multicast routing. Olof Hagsand KTH CSC DD2490 p4 2010 IP Multicast routing Multicast routing Olof Hagsand KTH CSC 1 Literature RFC 4601 Section 3 (you may need some definitions from Section 2). See reading instructions on web. 2 Deployment

More information

Multicast overview. Introduction to multicast. Information transmission techniques. Unicast

Multicast overview. Introduction to multicast. Information transmission techniques. Unicast Contents Multicast overview 1 Introduction to multicast 1 Information transmission techniques 1 Multicast features 3 Common notations in multicast 4 Multicast benefits and applications 4 Multicast models

More information

Advanced Networking. Multicast

Advanced Networking. Multicast Advanced Networking Multicast Renato Lo Cigno Renato.LoCigno@dit.unitn.it Homepage: disi.unitn.it/locigno/index.php/teaching-duties/advanced-networking Multicasting Addresses that refer to group of hosts

More information

Fundamental Questions to Answer About Computer Networking, Jan 2009 Prof. Ying-Dar Lin,

Fundamental Questions to Answer About Computer Networking, Jan 2009 Prof. Ying-Dar Lin, Fundamental Questions to Answer About Computer Networking, Jan 2009 Prof. Ying-Dar Lin, ydlin@cs.nctu.edu.tw Chapter 1: Introduction 1. How does Internet scale to billions of hosts? (Describe what structure

More information

IP Multicast Technology Overview

IP Multicast Technology Overview IP multicast is a bandwidth-conserving technology that reduces traffic by delivering a single stream of information simultaneously to potentially thousands of businesses and homes. Applications that take

More information

Broadcast Routing. Multicast. Flooding. In-network duplication. deliver packets from source to all other nodes source duplication is inefficient:

Broadcast Routing. Multicast. Flooding. In-network duplication. deliver packets from source to all other nodes source duplication is inefficient: Broadcast Routing Multicast deliver packets from source to all other nodes source duplication is inefficient: duplicate duplicate creation/transmission duplicate source duplication in-network duplication

More information

CS 268: Integrated Services

CS 268: Integrated Services Limitations of IP Architecture in Supporting Resource Management CS 268: Integrated Services Ion Stoica February 23, 2004 IP provides only best effort service IP does not participate in resource management

More information

IP Multicast. Falko Dressler Regionales Rechenzentrum Grundzüge der Datenkommunikation IP Multicast

IP Multicast. Falko Dressler Regionales Rechenzentrum Grundzüge der Datenkommunikation IP Multicast Falko Dressler Regionales Rechenzentrum falko.dressler@rrze.uni-erlangen.de 1 Agenda Basics Principles of IP multicast, addressing, TTL Internet Group Management Protocol (IGMP) IGMPv1, v2, v3 Layer-2

More information

ET4254 Communications and Networking 1

ET4254 Communications and Networking 1 Topic 10:- Local Area Network Overview Aims:- LAN topologies and media LAN protocol architecture bridges, hubs, layer 2 & 3 switches 1 LAN Applications (1) personal computer LANs low cost limited data

More information

Chapter 6. The Network Layer

Chapter 6. The Network Layer Chapter 6 The Network Layer 1 Network Layer Design Isues Store-and-Forward Packet Switching Services Provided to the Transport Layer Implementation of Connectionless Service Implementation of Connection-Oriented

More information

Configuring Multicast Routing

Configuring Multicast Routing CHAPTER 24 This chapter describes how to configure the ASA to use the multicast routing protocol and includes the following sections: Information About Multicast Routing, page 24-17 Licensing Requirements

More information

CSE 473 Introduction to Computer Networks. Final Exam. Your Name: 12/17/2014 PLEASE WRITE LEGIBLY NO POINTS FOR ILLEGIBLE ANSWERS

CSE 473 Introduction to Computer Networks. Final Exam. Your Name: 12/17/2014 PLEASE WRITE LEGIBLY NO POINTS FOR ILLEGIBLE ANSWERS CSE 47 Introduction to Computer Networks Roch Guérin Final Exam Your Name: 12/17/2014 PLEASE WRITE LEGIBLY NO POINTS FOR ILLEGIBLE ANSWERS 1. [10 points] Bob has been provided with the following pair of

More information

ETSF10 Internet Protocols Routing on the Internet

ETSF10 Internet Protocols Routing on the Internet ETSF10 Internet Protocols Routing on the Internet 2012, Part 2, Lecture 1.2 Kaan Bür, Jens Andersson Routing on the Internet Unicast routing protocols (part 2) [ed.4 ch.22.4] [ed.5 ch.20.3] Forwarding

More information

SYSC 5801 Protection and Restoration

SYSC 5801 Protection and Restoration SYSC 5801 Protection and Restoration Introduction Fact: Networks fail. Types of failures: Link failures Node failures Results: packet losses, waste of resources, and higher delay. What IGP does in the

More information

Date: June 4 th a t 1 4:00 1 7:00

Date: June 4 th a t 1 4:00 1 7:00 Kommunika tionssyste m FK, Examina tion G 5 0 7 Date: June 4 th 0 0 3 a t 4:00 7:00 KTH/IMIT/LCN No help material is allowed. You may answer questions in English or Swedish. Please answer each question

More information

Configuring IP Multicast Routing

Configuring IP Multicast Routing CHAPTER 46 This chapter describes how to configure IP multicast routing on the Catalyst 3750-E or 3560-E switch. IP multicasting is a more efficient way to use network resources, especially for bandwidth-intensive

More information

IPv6 PIM-DM configuration example 36 IPv6 PIM-SM non-scoped zone configuration example 39 IPv6 PIM-SM admin-scoped zone configuration example 42 IPv6

IPv6 PIM-DM configuration example 36 IPv6 PIM-SM non-scoped zone configuration example 39 IPv6 PIM-SM admin-scoped zone configuration example 42 IPv6 Contents Configuring IPv6 PIM 1 Overview 1 IPv6 PIM-DM overview 1 IPv6 PIM-SM overview 3 IPv6 BIDIR-PIM overview 8 IPv6 administrative scoping overview 11 IPv6 PIM-SSM overview 13 Relationship among IPv6

More information

Network Working Group. Category: Standards Track Juniper Networks J. Moy Sycamore Networks December 1999

Network Working Group. Category: Standards Track Juniper Networks J. Moy Sycamore Networks December 1999 Network Working Group Requests for Comments: 2740 Category: Standards Track R. Coltun Siara Systems D. Ferguson Juniper Networks J. Moy Sycamore Networks December 1999 OSPF for IPv6 Status of this Memo

More information

Routing, Routing Algorithms & Protocols

Routing, Routing Algorithms & Protocols Routing, Routing Algorithms & Protocols Computer Networks Lecture 6 http://goo.gl/pze5o8 Circuit-Switched and Packet-Switched WANs 2 Circuit-Switched Networks Older (evolved from telephone networks), a

More information

Index. Numerics. Index 1

Index. Numerics. Index 1 Index Numerics 802.1p priority (QoS) definition 8-6 802.1q VLAN in mesh 7-23 802.1Q VLAN standard 6-6 802.1w as a region 6-54 802.1x, mesh, not supported 7-5 A ABC enabled on edge switch 7-26 in mesh domain

More information

Mohammad Hossein Manshaei 1393

Mohammad Hossein Manshaei 1393 Mohammad Hossein Manshaei manshaei@gmail.com 1393 Voice and Video over IP Slides derived from those available on the Web site of the book Computer Networking, by Kurose and Ross, PEARSON 2 Multimedia networking:

More information

FiberstoreOS IP Routing Command Line Reference

FiberstoreOS IP Routing Command Line Reference FiberstoreOS IP Routing Command Line Reference Contents 1 IP Unicast-Routing Commands...6 1.1 ip address...6 1.2 ip icmp error-interval...7 1.3 ip redirects... 8 1.4 ip unreachables...9 1.5 ip verify unicast

More information

Configuring IP Multicast Routing

Configuring IP Multicast Routing 39 CHAPTER This chapter describes how to configure IP multicast routing on the Catalyst 3560 switch. IP multicasting is a more efficient way to use network resources, especially for bandwidth-intensive

More information

Layer 2 functionality bridging and switching

Layer 2 functionality bridging and switching Layer 2 functionality bridging and switching BSAD 141 Dave Novak Sources: Network+ Guide to Networks, Dean 2013 Overview Layer 2 functionality Error detection Bridges Broadcast and collision domains How

More information

Configuring IP Multicast Routing

Configuring IP Multicast Routing 34 CHAPTER This chapter describes how to configure IP multicast routing on the Cisco ME 3400 Ethernet Access switch. IP multicasting is a more efficient way to use network resources, especially for bandwidth-intensive

More information

DATA COMMUNICATOIN NETWORKING

DATA COMMUNICATOIN NETWORKING DATA COMMUNICATOIN NETWORKING Instructor: Ouldooz Baghban Karimi Course Book & Slides: Computer Networking, A Top-Down Approach By: Kurose, Ross Introduction Course Overview Basics of Computer Networks

More information

Acknowledgments. Part One - Introduction to the TCP/IP Protocol

Acknowledgments. Part One - Introduction to the TCP/IP Protocol Illustrated TCP/IP by Matthew G. Naugle Wiley Computer Publishing, John Wiley & Sons, Inc. ISBN: 0471196568 Pub Date: 11/01/98 Acknowledgments Part One - Introduction to the TCP/IP Protocol Chapter 1 -

More information