UNIT IV- TCP/IP-II Transport Control Protocol (TCP) TCP is a connection oriented, reliable protocol used in internet to provide a reliable endto-end byte stream over an unreliable internetwork (IP) An internetwork differs from a single network because different parts have different topologies, Bandwidths, Delays, Packet sizes and other parameters TCP has been designed to dynamically adapt to the properties of the internetwork. TCP is connection oriented, two processes hand shake each other to establish a connection Connection is established between two processes by initializing variables in a connection record called transmission control block (TCB). Connection is established bidirectional; hence data transfer takes place simultaneously in both directions. Stream Data Transfer:- transfers a contiguous stream of bytes across the network, with no indication of boundaries Doesn t support multicasting or broadcasting. Uses selective repeat ARQ to implement reliability. A TCP connection is uniquely identified by 4 parameters: 1) Sender IP address 2) Sender port number 3) Receiver IP address 4) Receiver port number Typically server is assigned a well known port number and client is assigned an ephemeral port number. Port addresses 1
TCP Protocol Source Port and Destination port:-the source and destination ports identify the sending and receiving applications. Sequence number:- 32 bit sequence numbers are used for acknowledgements and window mechanism The three phases of TCP communication are:1. TCP Connection establishment 2. Data transfer phase 3. TCP connection Termination TCP Connection establishment To establish a connection, TCP uses a three-way handshake. Before a client attempts to connect with a server, the server must first bind to a port to open it up for connections: this is called a passive open. Once the passive open is established, a client may initiate an active open. To establish a connection, the three-way (or 3-step) handshake occurs: 1. The active open is performed by the client sending a SYN to the server. 2. In response, the server replies with a SYN-ACK. 3. Finally the client sends an ACK back to the server. At this point, both the client and server have received an acknowledgment of the connection. Example: 1. The initiating host (client) sends a synchronization packet (SYN flag set to 1) to initiate a connection. It sets the packet's sequence number to a random value x. 2. The other host receives the packet, records the sequence number x from the client, and replies with an acknowledgment and synchronization (SYN-ACK). The Acknowledgment is a 32-bit field in TCP segment header. It contains the next sequence number that this host is expecting to receive (x + 1). The host also initiates a return session. This includes a TCP segment with its own initial Sequence Number of value y. 3. The initiating host responds with the next Sequence Number (x + 1) and a simple Acknowledgment Number value of y + 1, which is the Sequence Number value of the other host + 1. 2
Figure:- Three-way handshake Each SYN message during connection establishment can specify options such as maximum segment size (MSS), window scaling and time stamps. The three way handshake procedure ensures that both host s agree on their initial sequence numbers. Let us consider a situation why the initial sequence number must be different at every time and what happened if a host can always use the same initial sequence number. Figure: - Justifying a three way handshake: If a host always uses the same initial sequence, old segments cannot be distinguished from the current ones. In above case, after connection is established, a delayed segment from the previous connection arrives. Host B accepts this segment, since the sequence number is legal. 3
If a segment from current connection arrives later, it will be rejected by host B, thinking that the segment is a duplicate. Thus host B cannot distinguish a delayed segment from the new one. The below figure is an example for client server application TCP Data Transfer TCP uses Selective Repeat ARQ protocol as sliding window mechanisms. TCP also applies flow control by dynamically advertising the window size (flow control is the mechanism of regulating the traffic between two points and is used to prevent the sender from overwhelming the receiver with too much data. In each TCP segment, the receiver specifies in the receive window field the amount of additional received data (in bytes) that it is willing to buffer for the connection. The sending host can send only up to that amount of data before it must wait for an acknowledgment and window update from the receiving host. 4
Figure:-TCP Window flow control The above figure illustrates an example for TCP Window flow control Suppose at time t0, the TCP module in host B advertised a window of 2048 and expected next byte received to have a sequence number 2000. This advertised window size allows host A to transmit upto 2048 bytes of unacknowledged data. At time t1, host A has only assumed 1024 bytes to transmits all the data starting with sequence number 2000, and this TCP entity also advertises a window of size 1024 bytes to host B and next byte expected to have a sequence number 1. When the segment arrives, host B chooses to delay the acknowledgement for piggybacking (the technique of temporarily delaying outgoing acknowledgments so that they can be looked onto the next outgoing data frame is known as piggybacking). Meanwhile at t2, host A has another 1024 bytes of data and transmits it. After the transmission, A s sending window closes completely. It is not allowed to transmit any more data until an acknowledgment comes back. At time t3, host B has 128 bytes of data to transmit. Host B simply piggybacks the acknowledgment (ACK=4048) to the data segment. at this time also host B also advertises the window size of 512 bytes (because of some other connection the window size may shrink). When host A receives the segment, at time t4, assume that host A has nearly 2048 bytes of data, but it is allowed only 512 bytes. Like this, window advertisement dynamically controls the flow of data from one host to another and it prevents the receiver buffer from being overrun. 5
Nagle Algorithm Situation: user types 1 character at a time Transmitter sends TCP segment per character (41B) Receiver sends ACK (40B) Receiver echoes received character (41B) Transmitter ACKs echo (40 B) 162 bytes transmitted to transfer 1 character! Solution: TCP sends data & waits for ACK New characters buffered Send new characters when ACK arrives Algorithm adjusts to RTT Short RTT send frequently at low efficiency Long RTT send less frequently at greater efficiency Silly Window Syndrome Situation: Transmitter sends large amount of data Receiver buffer depleted slowly, so buffer fills Every time a few bytes read from buffer, a new advertisement to transmitter is generated Sender immediately sends data & fills buffer Many small, inefficient segments are transmitted Solution: Receiver does not advertise window until window is at least ½ of receiver buffer or maximum segment size Transmitter refrains from sending small segments. TCP Connection Termination TCP provides two types of connection terminations i.e. graceful and abrupt termination. A graceful termination can be initiated by an application, when it is having no more data to send. The TCP entity completes transmission of its data and, upon receiving acknowledgement from the receiver, issues a segment with the FIN bit set. Upon receiving the FIN segment, a TCP entity informs its application that other entity has terminated its transmission of data. For example, in below figure, The host A terminates its transmission by issuing a FIN segment. Host B sends an ACK segment upon receiving the FIN segment from host A. After B receives the FIN segment, host B sends 150 bytes of data in one segment, followed by FIN segment. 6
Host A sends then sends an acknowledgment. Host A enters the TIME_WAIT state and starts TIME_WAIT timer with an initial value=2*msl. If such a FIN segment arrives while host A is the TIME_WAIT state, then the ACK segment is transmitted and the TIME_WAIT timer is restarted at 2MSL. When TIME_WAIT timer expires, host A closes the connection. Figure:- TCP Graceful close The second type of termination is an abrupt connection termination through reset (RST) segments. If an application decides to terminate a connection abruptly, it issues an ABORT command, which causes TCP to discard any data that is queued for transmission and to send an RST segment. The TCP that receives the RST segment then notifies its application process that the connection has been terminated. 7
TCP state Transition diagram Figure: - TCP state Transition diagram Note: - thick solid line is normal state trajectory for a client and the dashed line is normal state trajectory for a server A connection progresses through a series of states during its lifetime. The states are: LISTEN, SYN-SENT, SYNRECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and the fictional state CLOSED. CLOSED is fictional because it represents the state when there is no TCB, and therefore, no connection. Briefly the meanings of the states are: LISTEN represents waiting for a connection request from any remote TCP and port. SYN-SENT represents waiting for a matching connection request after having sent a connection request. SYN-RECEIVED represents waiting for a confirming connection request acknowledgment after having both received and sent a connection request. ESTABLISHED represents an open connection, data received can be delivered to the user. The normal state for the data transfer phase of the connection. FIN-WAIT-1 represents waiting for a connection termination request from the remote TCP, or an acknowledgment of the connection termination request previously sent. FIN-WAIT-2 represents waiting for a connection termination request from the remote TCP. 8
CLOSE-WAIT represents waiting for a connection termination request from the local user. CLOSING represents waiting for a connection termination request acknowledgment from the remote TCP. LAST-ACK represents waiting for an acknowledgment of the connection termination request previously sent to the remote TCP (which includes an acknowledgment of its connection termination request). TIME-WAIT represents waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request. CLOSED represents no connection state at all. A TCP connection progresses from one state to another in response to events. The events are the user calls, OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS; the incoming segments, particularly those containing the SYN, ACK, RST and FIN flags; and timeouts. TCP Congestion Control TCP uses sliding window protocol for end-to-end flow control. The receiver specifies in its acknowledgement (ACK) the amount of bytes it is willing to receive in advertised window. The advertised window ensures that the receiver s buffer will never overflow, since TCP uses a congestion window in the sender side to avoid congestion. The congestion window indicates the maximum amount of data that can be sent out on a connection without being acknowledged. Advertised window size is used to ensure that receiver s buffer will not overflow however, buffers at intermediate routers between source and destination may overflow Congestion occurs when total arrival rate from all packet flows exceeds R over a sustained period of time. Buffers at multiplexer will fill and packets will be lost. Sources must control their sending rates so that aggregate arrival rate is just before knee. TCP sender maintains a congestion window (cwnd) to control congestion at intermediate routers. Effective window is minimum of congestion window and advertised window. Problem: source does not know what its fair share of available bandwidth should be Solution: adapt dynamically to available BW. Sources probe the network by increasing cwnd. When congestion detected, sources reduce rate, Ideally, sources sending rate stabilizes near ideal point TCP detects congestion when it fails to receive an acknowledgement for a packet within the estimated timeout. In such a situation, it decreases the congestion window to one maximum segment size (MSS), and under other cases it increases the congestion window by one MSS. There also exists a congestion window threshold, which is set to half the congestion window size at the time when a re-transmit was required. 9
The operation of TCP congestion control algorithm may be divided into three phases and they are as follows:tcp Congestion Control: Slow Start Slow start: increase congestion window size by one segment upon receiving an ACK from receiver initialized at 2 segments used at (re)start of data transfer congestion window increases exponentially TCP Congestion Control: Congestion Avoidance Algorithm progressively sets a congestion threshold When cwnd > threshold, slow down rate at which cwnd is increased Increase congestion window size by one segment per round-triptime (RTT) Each time an ACK arrives cwnd is increased by 1/cwnd In one RTT, cwnd segments are sent, so total increase in cwnd is cwnd x 1/cwnd = 1 cwnd grows linearly with time Internet Routing Protocols The job of the internet routing protocols is to determine the path taken by a datagram between source and destination. The Global Internet consists of Autonomous Systems (AS) interconnected with each other. An Autonomous system (AS) is loosely defined as a set of routers or networks that are administered by a single organization. There is no restriction that an AS should run a single routing protocol within the AS. There are three categories of Autonomous system (AS s) Stub AS: small corporation: one connection to other AS s 10
Multihomed AS: large corporation (no transit): multiple connections to other AS s, it carries only local traffic and does not support transit traffic. Transit AS: provider, it has multiple connections to the outside world and can carry transit and local traffic. Intra-AS Routing Also known as Interior Gateway Protocols (IGP) Most common Intra-AS routing protocols: o RIP: Routing Information Protocol o OSPF: Open Shortest Path First o IGRP: Interior Gateway Routing Protocol (Cisco proprietary) Routing Information Protocol (RIP) The Routing Information Protocol (RIP) is a dynamic routing protocol used in local and wide area networks. it is classified as an interior gateway protocol (IGP) using the distance-vector routing algorithm. A RIP run on top of UDP, port number 520 is used. RIP is a distance-vector routing protocol, Which employs the hop count as a routing metric. Suitable for small networks (local area environments) The maximum number of hops allowed with RIP is 15, and the hold down time is 180 seconds. Value of 16 is reserved to represent infinity, i.e. node is not reachable. Small number limits the count-to-infinity problem. Originally each RIP router transmits full updates every 30 seconds by default. A router expects to receive an update message from each of its neighbors within 180 seconds in the worst case If router does not receive update message from neighbor X within this limit, it assumes the link to X has failed and sets the corresponding minimum cost to 16 (infinity) Originally, routing tables were small enough that the traffic was not significant. RIP implements the split horizon, route poisoning and holddown mechanisms to prevent incorrect routing information from being propagated. These are some of the stability features of RIP. RIP is available in two versions, i.e. RIP1 and RIP2. In many current networking environments RIP would not be the preferred choice for routing as its time to converge and scalability are poor compared to EIGRP, OSPF The hop limit severely limits the size of network it can be used in. The periodic routing updates do not carry subnet information, lacking support for variable length subnet masks (VLSM). This limitation makes it impossible to have different-sized subnets inside of the same network class. 11
Figure:- RIP Message format Command: - specifies the purpose of the message, two values are defined value 1 requests the system to send its routing information and values 2 indicates a response containing the routing information. Version: - two versions, RIPV1 and RIPV2 Address Family Identifier:-identifies type of address used currently only IP address is defined IP address: - indicates the address of destination, which can be network or host address. Open Shortest Path First (OSPF) Open Shortest Path First (OSPF) routing protocol is a Link State protocol based on cost rather than hops or ticks (i.e. it is not a vector based routing protocol). OSPF is an Interior Gateway Protocol (IGP) Protocol, uses flooding of link state information and Dijkstra s least-cost path algorithm. With OSPF, router constructs a complete topological map of the entire autonomous system. The router then locally runs the Dijkstra s shortest-path algorithm to determine shortest-path tree to all networks with itself as rootnode. The router s routing table is then obtained from this shortest-path tree. At steady state: All routers have same LS database, Know how many routers in network, Interfaces & links between routers, Cost of each link Occasional Hello messages (10 sec) & LS updates sent (30 min) Advantages of OSPF: Changes in an OSPF network are propagated quickly. OSPF is hierarchical, using area 0 as the top of the hierarchy. OSPF is a Link State Algorithm. OSPF supports Variable Length Subnet Masks (VLSM). OSPF uses multicasting within areas. After initialization, OSPF only sends updates on routing table sections which have changed, it does not send the entire routing table. 12
Using areas, OSPF networks can be logically segmented to decrease the size of routing tables. Table size can be further reduced by using route summarization. OSPF is an open standard, not related to any particular vendor. Disadvantages of OSPF: OSPF maintains multiple copies of routing information, increasing the amount of memory needed. Using areas, OSPF can be logically segmented (this can be a good thing and a bad thing). OSPF is not as easy to learn as some other protocols. In the case where an entire network is running OSPF and one link within it is "bouncing" every few seconds, OSPF updates would dominate the network by informing every other router every time the link changed state. OSPF Network To improve scalability, AS may be partitioned into areas. Area is identified by 32-bit Area ID Router in area only knows complete topology inside area & limits the flooding of linkstate information to area Area border routers summarize info from other areas, each area must be connected to backbone area (0.0.0.0) Distributes routing info between areas o Internal router has all links to network within the same area i.e. these are in nonbackbone areas and perform only inter-as routing o Area border router has links to more than one area that belongs to both an area and backbone. o Backbone router has links connected to the backbone, these routers perform routing within the backbone, but themselves are not area border routers. Within a nonbackbone area, internal routers learn of the existence of routers of other area from the information broadcast within the area by its backbone routers. o Autonomous system boundary (ASB) router has links to another autonomous system. ASBR s learn about routers outside the AS through an exterior gateway protocol such as BGP. 13
Figure: - OSPF Areas Neighbor & Adjacent Routers Neighbor routers: two routers that have interfaces to a common network Neighbors are discovered dynamically by Hello protocol Adjacent router: neighbor routers become adjacent when they synchronize topology databases by exchange of link state information Neighbors on point-to-point links become adjacent Routers on multi-access networks become adjacent only to designated & backup designated routers Reduces size of topological database & routing traffic Designated Routers Reduces number of adjacencies Elected by each multi-access network after neighbor discovery by hello protocol Election based on priority & id fields Generates link advertisements that list routers attached to a multi-access network Forms adjacencies with routers on multi-access network Backup prepared to take over if designated router fails 14
OSPF Operation: - The header format of OSPF is shown in below figure Figure: - OSPF Common Header Each OSPF packet consists of an OSPF header followed by the packet body (data) The description of each field in the OSPF header is given below: Version: This field specifies the protocol version, current version is 2. Type: This field specifies the type of OSPF packet. The following types are defined hello, database description, link-state request, link-state update, link-state acknowledgements. Packet length: This field specifies the length of OSPF packet in bytes, including OSPF header. Router ID: This field identifies the sending router s ip address. Area ID: This field identifies the area this packet belongs to. The area ID of 0.0.0.0 is reserved for backbone. Checksum: to detect errors in packet. Authentication type and Authentication: Combination of these fields can be used to authenticate OSPF packets. There are five types of OSPF packets Hello Packet Database description Packet Link-state request Packet Link-state update Packet and Link-state acknowledgement The operation of OSPF can be explained in 3 steps. Step1: Discovery of neighbors can be done by sending hello packets in point-to-point links and designated routers in multi-access networks. The format of hello packet is shown in below figure: To discover, establish and maintain relationships, the OSPF transmit hello packet to each interface periodically, typically for every 10 to 30 sec. When a router receives a hello packet, it replies with a hello packet containing router ID of each neighbor it has seen. When a router receives a hello packet containing its router ID in one of the neighbor fields, the router is assured that communication to sender is bidirectional. 15
Figure:- OSPF Hello packets The function of each field is given below Step 2: Establishment of adjacent and synchronization of link-state databases Once the connection is established between two neighbor routers, the database description packet is used to synchronize their link-state databases One router acts as master and other as slave. The format of database description is as follows Figure: - OSPF Database Description 16
The function of each field is given below LSA Header: The Link State Advertisement (LSA) header describes the state of the router or network. Each LSA header contains enough information to uniquely identify an entry in the LSA (type, ID and advertising router). The format contains multiple LSA headers and routers will send only their LSA header instead of entire database. The format of LSA header is as shown below Figure: - LSA Header The function of LSA header is given below Step 3: Propagation of OSPF Link State Request and building routing tables When a router wants to update the link-state database, it sends a LS request packet to neighbor to update part of its link-state database 17
Each LSA request is specified by the link state type, link state ID, and the advertising router. Figure: - OSPF Link State Request Packet OSPF Link State Update In response to LS request or trigger router will send new LS info trigger, using the LS update message Contents are composed of link state advertisements (LSA s) LS update message is acknowledged using LS ack pkt to ensure that the flooding algorithm is reliable; Link state acknowledgement packets consist of a list of LSA headers. Figure: - OSPF Link State Update Packet BGP (Border Gateway Protocol): The de facto standard for inter-as routing, BGP: glues the whole Internet together Path Vector protocol Uses TCP (service port: 179) Similar to Distance Vector protocol. Each Border Gateway broadcast to neighbors (peers) entire path (i.e., sequence of AS s) to destination BGP is an exterior gateway protocol (EGP), which means that it performs routing between multiple autonomous systems or domains and exchanges routing and reachability information with other BGP systems. The information exchanged among BGP routers allow a router to construct a graph of AS s and each AS is identified by Autonomous System Number (ASN). BGP routes to networks (ASs), not individual hosts BGP messages exchanged using TCP and BGP messages are: o OPEN: opens TCP connection to peer and authenticates sender o UPDATE: advertises new path (or withdraws old) 18
o KEEPALIVE keeps connection alive in absence of UPDATES; also ACKs OPEN request o NOTIFICATION: reports errors in previous msg; also used to close connection Session is established between two BGP speakers to exchange information regarding - New active routes - Old inactive routers or - To report error conditions The below figure illustrates core routers using BGP to route traffic between autonomous systems All BGP message types use the basic packet header. Open, update, and notification messages have additional fields, but keep-alive messages use only the basic packet header. The below figure illustrates the fields used in the BGP header. BGP Packet-Header Fields Marker contains an authentication value that the message receiver can predict. Length indicates the total length of the message in bytes. Type specifies the message type as one of the following: Open Update Notification Keep-alive Data Contains upper-layer information in this optional field. Open Message Format BGP open messages are comprised of a BGP header and additional fields. The below figure illustrates the additional fields used in BGP open messages. 19
BGP Open Message Fields BGP packets in which the type field in the header identifies the packet to be a BGP open message packet include the following fields. These fields provide the exchange criteria for two BGP routers to establish a peer relationship. Version Provides the BGP version number so that the recipient can determine whether it is running the same version as the sender. Autonomous System Provides the autonomous system number of the sender. Hold-Time Indicates the maximum number of seconds that can elapse without receipt of a message before the transmitter is assumed to be nonfunctional. BGP Identifier Provides the BGP identifier of the sender (an IP address), which is determined at startup and is identical for all local interfaces and all BGP peers. Optional Parameters Length Indicates the length of the optional parameters field (if present). Optional Parameters Contains a list of optional parameters (if any). Only one optional parameter type is currently defined: authentication information. Authentication information consists of the following two fields: Authentication code: Indicates the type of authentication being used. Authentication data: Contains data used by the authentication mechanism (if used). Update Message Format BGP update messages are comprised of a BGP header and additional fields. The below figure illustrates the additional fields used in BGP update messages. BGP Update Message Fields BGP packets in which the type field in the header identifies the packet to be a BGP update message packet include the following fields. Upon receiving an update message packet, routers will be able to add or delete specific entries from their routing tables to ensure accuracy. Update messages consist of the following fields: Unfeasible Routes Length Indicates the total length of the withdrawn routes field or that the field is not present. Withdrawn Routes Contains a list of IP address prefixes for routes being withdrawn from service. Total Path Attribute Length Indicates the total length of the path attributes field or that the field is not present. Path Attributes Describes the characteristics of the advertised path. The following are possible attributes for a path: Origin: Mandatory attribute that defines the origin of the path information 20
AS Path: Mandatory attribute composed of a sequence of autonomous system path segments Next Hop: Mandatory attribute that defines the IP address of the border router that should be used as the next hop to destinations listed in the network layer reachability information field Mult Exit Disc: Optional attribute used to discriminate between multiple exit points to a neighboring autonomous system Local Pref: Discretionary attribute used to specify the degree of preference for an advertised route Atomic Aggregate: Discretionary attribute used to disclose information about route selections Aggregator: Optional attribute that contains information about aggregate routes Network Layer Reachability Information Contains a list of IP address prefixes for the advertised routes Notification Message Format The below figure illustrates the additional fields used in BGP notification messages. BGP Notification Message Fields BGP packets in which the type field in the header identifies the packet to be a BGP notification message packet include the following fields. This packet is used to indicate some sort of error condition to the peers of the originating router. Error Code Indicates the type of error that occurred. The following are the error types defined by the field: Message Header Error: Indicates a problem with a message header, such as unacceptable message length, unacceptable marker field value, or unacceptable message type. Open Message Error: Indicates a problem with an open message, such as unsupported version number, unacceptable autonomous system number or IP address, or unsupported authentication code. Update Message Error: Indicates a problem with an update message, such as a malformed attribute list, attribute list error, or invalid next-hop attribute. Hold Time Expired: Indicates that the hold-time has expired, after which time a BGP node will be considered nonfunctional. Finite State Machine Error: Indicates an unexpected event. Cease: Closes a BGP connection at the request of a BGP device in the absence of any fatal errors. Error Subcode Provides more specific information about the nature of the reported error. Error Data Contains data based on the error code and error subcode fields. This field is used to diagnose the reason for the notification message. 21
Multicast Routing The sending of a packet from one sender to multiple receivers with a single "transmit" operation is known as multicast routing. Teleconferencing is an example which requires multicast routing. The goal of multicast routing is to find a tree of links that connects all of the routers that have attached hosts belonging to the multicast group. Multicast packets will then be routed along this tree from the sender to all of the hosts belonging to the multicast tree. There are many ways to generate multicast tree, MBONE is also one approach to generate multicast tree. The Internet Multicast Backbone (MBone) is an interconnected set of subnetworks and routers that support the delivery of IP multicast traffic. An IP multicast group is identified by a Class D address. Figure: Multicast tree routed at source S In the above figure, the source S wants to transmit to destinations with multicast group G1. The source can send each copy of the packet separately to each destination by using conventional unicast routing or else a more efficient method which will reduce the number of copies For example, when router 1 receives a packet from the source, router 1 copies the packet to router 2 and router 5 simultaneously. Upon receipt of these packets, router 2 forwards the packet to its local network, and router 5 copies the packet to router 7 and router 8. the packet will be received by each intended destinations. RPB (Reverse Path Broadcasting) The fundamental algorithm to construct these source-based trees is referred to as Reverse Path Broadcasting (RPB). The RPB operation is very simple. 22
For each source, if a packet arrives on a link that the local router believes to be on the shortest path back toward the packet's source, then the router forwards the packet on all interfaces except the incoming interface. If the packet does not arrive on the interface that is on the shortest path back toward the source, then the packet is discarded. The interface over which the router expects to receive multicast packets from a particular source is referred to as the "parent" link. The outbound links over which the router forwards the multicast packet are called "child" links for this source. The key benefit to reverse path broadcasting is that it is reasonably efficient and easy to implement. It does not require that the router know about the entire spanning tree, nor does it require a special mechanism to stop the forwarding process (as flooding does). In addition, it guarantees efficient delivery since multicast packets always follow the "shortest" path from the source station to the destination group. Finally, the packets are distributed over multiple links, resulting in better network utilization since a different tree is computed for each source. One of the major limitations of the RPB algorithm is that it does not take into account multicast group membership when building the delivery TRPB Truncated Reverse Path Broadcasting (TRPB) was developed to overcome the limitations of Reverse Path Broadcasting. With information provided by IGMP, multicast routers determine the group memberships on each leaf subnetwork and avoid forwarding datagrams onto a leaf subnetwork if it does not contain at least one member of a given destination group. Thus, the delivery tree is "truncated" by the router if a leaf subnetwork has no group members. RPM (Reverse Path Multicasting) Reverse Path Multicasting (RPM) is an enhancement to Reverse Path Broadcasting and Truncated Reverse Path Broadcasting. RPM creates a delivery tree that spans only 1) subnetworks with group members, and 2) routers and subnetworks along the shortest path to those subnetworks. RPM allows the source-based "shortest-path" tree to be "pruned" so that datagrams are only forwarded along branches that lead to active members of the destination group. When a multicast router receives a packet for a (source, group) pair, the first packet is forwarded following the TRPB algorithm across all routers in the internetwork. Routers on the edge of the network (which have only leaf subnetworks) are called leaf routers. The TRPB algorithm guarantees that each leaf router will receive at least the first multicast packet. 23
If there is a group member on one of its leaf subnetworks, a leaf router forwards the packet based on this group membership information. If none of the subnetworks connected to the leaf router contain group members, the leaf router may transmit a "prune" message on its parent link, informing the upstream router that it should not forward packets for this particular (source, group) pair on the child interface on which it received the prune message. Prune messages are sent just one hop back toward the source. An upstream router receiving a prune message is required to store the prune information in memory. If the upstream router has no recipients on local leaf subnetworks and has received prune messages from each downstream neighbor on each of the child interfaces for this (source, group) pair, then the upstream router does not need to receive any more packets for this (source, group) pair. Therefore, the upstream router can also generate a prune message of its own, one hop further back toward the source. Figure: Grafting to cancel Pruning A host may later decide to join a multicast group after a prune message has been sent by its leaf router. In this case the leaf router may send graft message to its upstream router to cancel its earlier prune message The above figure shows the graft message flow when a host attached to router 6 wants to join the group. Subsequently, router 1 will forward the multicast packets to router 4, which will forward the multicast packets to router 6. then the multicast packets arrive at the host. DVRMP The first multicast routing protocol used in the Internet and the most widely supported multicast routing algorithm is the distance vector multicast routing protocol (DVMRP) DVMRP implements source-based trees with reverse path forwarding, pruning, and grafting. 24
DVMRP is based on combination of RIP and RPM. DVMRP uses a distance vector algorithm that allows each router to compute the outgoing link (next hop) that is on its shortest path back to each possible source. This information is then used in the RPF algorithm. In addition to computing next hop information, DVMRP also computes a list of dependent downstream routers for pruning purposes. When a router has received a prune message from all of its dependent downstream routers for a given group, it will propagate a prune message upstream to the router from which it receives its multicast traffic for that group. A DVMRP prune message contains a prune lifetime (with a default value of two hours) that indicates how long a pruned branch will remain pruned before being automatically restored. DVMRP graft messages are sent by a router to its upstream neighbor to force a previously-pruned branch to be added back on to the multicast tree. IGMP (Internet Group Management Protocol) The (IGMP) runs between hosts and their immediately-neighboring multicast routers. The mechanisms of the protocol allow a host to inform its local router that it wishes to receive transmissions addressed to a specific multicast group. Also, routers periodically query the LAN to determine if any group members are still active. If there is more than one IP multicast router on the LAN, one of the routers is elected "querier" and assumes the responsibility of querying the LAN for the presence of any group members. Based on the group membership information learned from the IGMP, a router is able to determine which (if any) multicast traffic needs to be forwarded to each of its "leaf" subnetworks. "Leaf" subnetworks are those that have no further downstream routers; they either contain receivers for some set of groups, or they do not. Multicast routers use the information derived from IGMP, along with a multicast routing protocol, to support IP multicasting across the MBone. Figure: IGMP message format Version: This field identifies the version number Type: This field identifies the message type. There are two message types, type1 indicates a query message sent by router and type 2 indicates a report sent by host Unused: This field must be set to zero. Checksum: This field contains checksum for all eight bytes of IGMP message Group Address: This address is the class D IPV4 address. This field is set to zero in a query message and is set to a valid group address in the response. 25
Multicast routers periodically transmit Host Membership Query messages to determine which host groups have members on their directly-attached networks. Mobile IP The Mobile IP protocol allows location-independent routing of IP datagrams on the Internet. Each mobile node is identified by its home address disregarding its current location in the Internet. While away from its home network, a mobile node is associated with a care-of address which identifies its current location and its home address is associated with the local endpoint of a tunnel to its home agent. Mobile IP specifies how a mobile node registers with its home agent and how the home agent routes datagrams to the mobile node through the tunnel. Mobile IP provides an efficient, scalable mechanism for roaming within the Internet. Using Mobile IP, nodes may change their point-of-attachment to the Internet without changing their home IP address. Mobile IP allows portable devices called mobile hosts (MHs) to roam from one area to another. A common analogy to understand Mobile IP is that when someone moves his residence from one location to another. Person moves from Boston to New York. Person drops off new mailing address to New York post office. New York post office notifies Boston post office of new mailing address. When Boston post office receives mail for person it knows to forward mail to person's New York address. The below figure describes the mobile hosts routing Figure: Routing for mobile hosts Mobile IP operates as follows:- 26
When a correspondent host (CH) wants to send a packet to MH, the CH transmits the standard IP packet with its address as the source IP address and MH s address as destination IP address. This packet will be intercepted by the mobile host s router called home agent (HA), which keeps track of the current location of the MH. The HA manages all MHs in its home network that use the same address prefix If the MH is located in the home network, the HA simply forwards the packet to its home network. When an MH moves to a foreign network, the MH obtains a care of address from the foreign agent (FA) and registers the new address with its HA. The care-of-address reflects the MH s current location and is typically the address of FA. Once the HA knows the care-of-address of the MH, the HA can forward the registration packet to the MH via the FA. To transmit a packet by HA to MH directly when MH is in foreign network, instead of using FA, tunneling mechanisms is used. It has two addresses, Destination address of the other end of the tunnel (FA) and Final destination MH. NAT (Network Address Translation or Network Address Translator) NAT is the translation of an Internet Protocol address (IP address) used within one network to a different IP address known within another network. One network is designated the inside network and the other is the outside. Typically, a company maps its local inside network addresses to one or more global outside IP addresses and unmaps the global IP addresses on incoming packets back into local IP addresses. This helps ensure security since each outgoing or incoming request must go through a translation process that also offers the opportunity to qualify or authenticate the request or match it to a previous request. NAT also conserves on the number of global IP addresses that a company needs and it lets the company use a single IP address in its communication with the world. NAT is included as part of a router and is often part of a corporate firewall. Network administrators create a NAT table that does the global-to-local and local-toglobal IP address mapping. NAT can be statically defined or it can be set up to dynamically translate from and to a pool of IP addresses. NAT lets an administrator to create tables that map: A local IP address to one global IP address statically A local IP address to any of a rotating pool of global IP addresses that a company may have a local IP address plus a particular TCP port to a global IP address or one in a pool of them A global IP address to any of a pool of local IP addresses on a round-robin basis 27
Address translation 28
DHCP (Dynamic Host Configuration Protocol) DHCP protocol is used to assign IP addresses to hosts or workstations on the network. Usually a DHCP server on the network performs this function. Basically it "leases" out address for specific times to the various hosts. If a host does not use a given address for some period of time, that IP address can then be assigned to another machine by the DHCP server. When assignments are made or changed, the DHCP server must update the information in the DNS server. As with BOOTP, DHCP uses the machine's or NIC ethernet (MAC) or hardware address to determine IP address assignments. The DHCP protocol is built on BOOTP and replaces BOOTP. DHCP Lease Stages 1. Lease Request - The client sends a broadcast requesting an IP address 2. Lease Offer - The server sends the above information and marks the offered address as unavailable. The message sent is a DHCPOFFER broadcast message. 3. Lease Acceptance - The first offer received by the client is accepted. The acceptance is sent from the client as a broadcast (DHCPREQUEST message) including the IP address of the DNS server that sent the accepted offer. Other DHCP servers retract their offers and mark the offered address as available and the accepted address as unavailable. 4. Server lease acknowledgement - The server sends a DHCPACK or a DHCPNACK if an unavailable address was requested. DHCP discover message - The initial broadcast sent by the client to obtain a DHCP lease. It contains the client MAC address and computer name. This is a broadcast using 255.255.255.255 as the destination address and 0.0.0.0 as the source address. Dynamic Host Configuration Protocol (DHCP) is a network protocol that enables a server to automatically assign an IP address to a computer from a defined range of numbers (i.e., a scope) configured for a given network. DHCP assigns an IP address when a system is started, for example: 1. A user turns on a computer with a DHCP client. 2. The client computer sends a broadcast request (called a DISCOVER or DHCPDISCOVER), looking for a DHCP server to answer. 3. The router directs the DISCOVER packet to the correct DHCP server. 4. The server receives the DISCOVER packet. Based on availability and usage policies set on the server, the server determines an appropriate address (if any) to give to the client. The server then temporarily reserves that address for the client and sends back to the client an OFFER (or DHCPOFFER) packet, with that address information. The server also configures the client's DNS servers, WINS servers, NTP servers, and sometimes other services as well. 5. The client sends a REQUEST (or DHCPREQUEST) packet, letting the server know that it intends to use the address. 29
6. The server sends an ACK (or DHCPACK) packet, confirming that the client has a been given a lease on the address for a server-specified period of time. When a computer uses a static IP address, it means that the computer is manually configured to use a specific IP address. One problem with static assignment, which can result from user error or inattention to detail, occurs when two computers are configured with the same IP address. This creates a conflict that results in loss of service. Using DHCP to dynamically assign IP addresses minimizes these conflicts. Figure 1 In figure 1, a new client that just joined the network, needs an IP address. Since it does not know the DHCP server's location, the client broadcasts (step 1) a DHCPDISCOVER message on the local network. The message packet contains a hardware identifier (usually the MAC address), the source port (68), the destination IP (255.255.255.255), destination port (67), and a randomly generated transaction id. Optionally the client can specify the IP address it wants and the lease duration in the message. Once the DHCP relay receives the broadcasted message, it fills in the "giaddr" field of the packet with the gateway IP address of 10.1.2.9. This piece of information is critical because the DHCP Server needs it to determine which subnet the client is on and thus which IP address to allocate to the client. Afterwards the DHCPDISCOVER message is relayed to the DHCP Server via unicast (step 2). A unicast, instead of a broadcast, is sufficient because the DHCP relay knows the exact location of the DHCP server. For this same reason, the DHCP relay does not allow the other network segment, 10.1.1.X, to receive the message. Once the DHCP server receives the DHCPDISCOVER request, it allocates an IP address, marks it as taken, and then broadcasts a DHCPOFFER message back to the requesting client. This message packet contains the DHCP server's IP address, the client's hardware identifier, the same transaction id, and the IP address allocated for the client. Optionally, the message 30
may also contain the lease time, subnet mask, default TTL, default router(s), and numerous other parameters. Figure 2 In figure 2, the DHCP server allocates new IP address 10.1.2.3 for the client and broadcasts a DHCPOFFER message to its network (step 3). When the DHCP relay sees the DHCPOFFER broadcast, it relays the broadcast to the 10.1.2.X network and only that network (step 4). Once the new client sees the DHCPOFFER message, it accepts the IP address (step 5) and prepares a confirmation message to the DHCP server with a DHCPREQUEST packet. Please note that the client does not have to accept this IP address, in which case it will not send a DHCPREQUEST message. If multiple DHCP servers sends out a DHCPOFFER, the client can choose which one to accept. If for some reason, the DHCPOFFER message fails to ever arrive, the client will rebroadcast the DHCPDISCOVER message. Figure 3 31
If the client included optional information in the initial DHCPDISCOVER message, it must include that same information in the subsequent DHCPREQUEST message. In step 6 of figure 3, the new client confirms it wants the IP address 10.1.2.3 by broadcasting a DHCPREQUEST to the DHCP server. Once the DHCP Server receives this message (with help again from the DHCP Relay), it first ensures that it is the intended target - because the client could be responding to another DHCP Server. If this DHCP server is not the intended target, then it knows some other DHCP server is handling this client. So this DHCP server can discard any previously allocated IP address for that client. If this DHCP Server is the intended recipient, then it has to verify the optional parameters that it specified in the previous DHCPOFFER message to this client, are still valid. Assuming everything is fine up to this point, the DHCP Server sends a DHCPACK broadcast (step 8) to tell the client that its new IP address can now officially be used. However, if something is wrong, then a DHCPNACK is broadcasted instead. Either way, a DHCPACK or DHCPNACK will be the final message sent by the DHCP server in the dynamic IP address allocation sequence.. Assuming it receives the DHCPACK relayed by the router (step 9), the client is encouraged to verify no other hosts has the same IP address. This is usually accomplished through a simple ARP probe. Any response to the probe means that another client is already using the IP address. In such a situation, the client must send a DHCPDECLINE message to the DHCP server. Afterwards the client will then need to restart this whole process beginning with DHCPDISCOVER phase. In most cases, there's no response to the client's ARP probe. This means the client can go ahead and use the allocated IP address along with any other optional information stored in the message packet. If the client got a DHCPNAK instead of DHCPACK, then it has no choice but to restart everything from the very beginning i.e. the DHCPDISCOVER stage. Finally, if the client doesn't receive any DHCPACK or DHCPNAK message after a certain period of time, then it rebroadcasts the DHCPREQUEST message. 32