Friday, 16 March 2012

What is a Routing Protocol ?

A routing protocol can be analyzed as a process. A protocol is formalized through the Request for Comments (RFC) process. This process involves open written commentary on a proposed technology in an effort to bring about standardization of that technology. An example of a routing protocol standard would be OSPF as defined in RFC 2328.
 
The basic reason you are here is to understand how, through the use of OSPF, you can get packets from one host to another over a network. This process can be summarized, from a router's perspective, as consisting of two steps, forwarding and routing:
  • Forwarding-Refers to the process of a router receiving a packet on an interface and then knowing which interface to retransmit that packet out of so that the packet can continue to its destination. However, forwarding is entirely dependent on the router knowing where to send the packet; if it does not know this, it just discards the packet.
  • Routing-For the router to know in which direction to forward packets, it requires a route or road map that illustrates the path from source to destination. This route can be generated by either a static or dynamic configuration; at this point, you need to be concerned with only the dynamic aspect of routing. OSPF is a dynamic routing protocol, and when a router is running OSPF, it dynamically develops routes to all destinations within a network. You can view these routes when you view a router's routing table.
The following are broad categories of protocols:
  • Routed protocols-Protocols that forward data via routers. A router must be able to interpret the logical network as specified by the routed protocol for the router to operate properly. The most commonly known routed protocol is Internet protocol (IP); other examples include AppleTalk and DECnet. Routed protocols rely on the routing protocols for transport over a LAN or WAN.
  • Dynamic routing protocols-Protocols that accomplish dynamic routing with a routing algorithm. A dynamic routing protocol supports a routed protocol and maintains routing tables. A dynamic routing protocol dynamically exchanges information about paths or topology of the network by distributing routing information throughout a network. Examples of dynamic routing protocols include OSPF, interior gateway routing protocol (IGRP), and routing information protocol (RIP).
A routed protocol such as IP is used as the method of communication between devices on a network. Using a selected routing protocol, such as OSPF, which is supported by the routed protocol, such as IP, you can build the network so that every device can communicate. For example, as previously mentioned, IP is a routed protocol that can use either OSPF or RIP as its routing protocol.
In summary, a dynamic routing protocol is a set of standardized rules that allow routers to determine routes. The routing protocol builds routing tables that tell the router the optimal path to a destination. Routing protocols compare numeric values known as metrics to determine the optimal route (sometimes referred to as path). Metrics are numeric values that represent route path characteristics. Metrics can be thought of as costs; therefore, the numeric value is explained as the cost of transiting a link. This information is then stored in the routing table to be used by the router when determining the best route to a destination network.

Basic Routing Protocol Operation

Consider an example of a router that is initially configured with two networks to which it directly connects. The router has only these two networks in its routing tables. However, other networks beyond the initial two are not entered into the routing table because they do not directly connect to the router. So how does the router recognize these other networks? This can be accomplished in the following ways:
  • Static routing-A manually defined and installed type of route within the router as the only path to a given destination. This type of routing forces the destination within routing tables. This type of routing also takes precedence over routes chosen by dynamic routing protocols. Figure below shows an example of where to place a static route and how a static route is used. Static routing is not an effective stand-alone solution in a medium- to large-sized network because the work needed to make the network run something is very large. The most common use of static routes is in stub networks, as shown in Figure below. In conjunction with a dynamic routing protocol such as OSPF, this synergy works well.

    Placement of Static Routes
  • Default routing-A type of route within the router that is manually defined as the path to take when no route to the destination is known. The router to which this information is sent is also known as the router or gateway of last resort. Figure below shows the use of a default route, which can make routing easy.
    In Figure below, all traffic that Router B receives is forwarded to Router A's S0 interface if it is not for the E0 network, 192.168.254.0/24.
  • Dynamic routing-Uses routing algorithms that analyze incoming routing update messages from one or more routing protocols to determine the optimal path to a destination. This type of routing has the greatest advantage in that routing automatically adapts to a change in the network's topology.
Placement of a Default Route
Dynamic routing is the most commonly used method of routing. Associated with this type of routing are several terms and characteristics that define how it operates, such as convergence and accuracy.

In dynamic routing, the routing table must consistently reflect accurate and up-to-date information concerning the network topology. The amount of time that it takes for changes to be reflected in every network router's routing table is known as the convergence time. Convergence, in this context, is the act of approaching the state where all routing tables have congruent information and are in steady state.

Having a routing protocol with a fast convergence time is desirable because disruption of routing can occur during the time that a router spends calculating the new optimal path.

Thursday, 16 February 2012

IPv4 Packet Header

The Internet Protocol (IP) uses a Datagram service to transfer packets of data between end systems using routers.

The IPv4 packet header consists of 20 bytes of data. An option exists within the header that allows further optional bytes to be added, but this is not normally used (with the occasional exception of something called "Router Alert"). The full header is shown below:





The header fields are discussed below:
  • Version (always set to the value 4 in the current version of IP)
  • IP Header Length (number of 32 -bit words forming the header, usually five)
  • Type of Service (ToS), now known as Differentiated Services Code Point (DSCP) (usually set to 0, but may indicate particular Quality of Service needs from the network, the DSCP defines the way routers should queue packets while they are waiting to be forwarded).
  • Size of Datagram (in bytes, this is the combined length of the header and the data)
  • Identification ( 16-bit number which together with the source address uniquely identifies this packet - used during reassembly of fragmented datagrams)
  • Flags (a sequence of three flags (one of the 4 bits is unused) used to control whether routers are allowed to fragment a packet (i.e. the Don't Fragment, DF, flag), and to indicate the parts of a packet to the receiver)
  • Fragmentation Offset (a byte count from the start of the original sent packet, set by any router which performs IP router fragmentation)
  • Time To Live (Number of hops /links which the packet may be routed over, decremented by most routers - used to prevent accidental routing loops)
  • Protocol  which indicates the type of transport packet being carried (e.g. 1 = ICMP; 2= IGMP; 6 = TCP; 17= UDP).
  • Header Checksum (A 1's complement checksum inserted by the sender and updated whenever the packet header is modified by a router - Used to detect processing errors introduced into the packet inside a router or bridge where the packet is not protected by a link layer cyclic redundancy check. Packets with an invalid checksum are discarded by all nodes in an IP network)
  • Source Address (the IP address of the original sender of the packet)
  • Destination Address (the IP address of the final destination of the packet)
  • Options (not normally used, but, when used, the IP header length will be greater than five 32-bit words to indicate the size of the options field)

Tuesday, 12 July 2011

Capability Negotiation

The basic motive of this process is to KNOW about the other node to which a node intended to communicate before establishing the connection, ie. whether other node contains the applications for which node wants to communicate. 

Technically speaking, It is the process where two diameter peer exchange their identity and its capabilities (such as protocol version number, supported diameter applications, security mechanism etc.). Peer share their capabilities by CER/CEA Message (Capability-Exchange-Request/Capability-Exchange-Answer).

If one peer sends a CER message to another Peer and receiver does not have support for 
 
1) any common application then it must return the CEA with Result-Code Avp set toDIAMETER_NO_COMMON_APPLICATION and should disconnect the transport layer connection.

2)no common security mechanism then it must return the CEA with Result-Code Avp set to DIAMETER_NO_COMMON_SECURITY and should disconnect the transport layer connection. (Only maintained to have backward compatibility Because in latest release Transport Level security is establish before diameter connection so CER/CEA message is also comes under TLS/DTLS for more Info Click Here)

3)If CER is received from any unknown peer then receiver should discard the message, or send the CEA with the Result-Code Avp set to DIAMETER_UNKNOWN_PEER.
 
If the local implementation policy permits to receive CER from unknown hosts,a successful CEA MAY be returned, and the life time of the peer entry in PEER-Table is equal to the lifetime of the transport connection. If in any case transport connection fails then all the pending transactions destined to the unknown peer can be discarded.

The CER and CEA messages MUST NOT be proxied, redirected or relayed. Since CER/CEA messages can not be proxied, but still it is possible that proxy will receive a CER message and proxy does not have any peer to handle the application requested in CER, in this case proxy set the E bit in CEA and set the Result-Code Avp to DIAMETER_UNABLE_TO_DELIVER, sends back to CER generator peer.

For Example:- consider two nodes A and B and Node-A contains three applications X,Y,Z and two security mechanism s1 and s2 while Node-B contains two applications A,X and s1 security mechanism. Now Node-A will send CER to Node-B. Node -B will process the request and will create and send the CEA showing success and the common application i.e. X and s1 security mechanism. Now Node-A become aware of the fact that it can communicate for X application and s1 security mechanism.

Probable CER And CEA would be:-
      ________          CER                     ________
     | Node-A | ------------------------------>| Node-B |
     |________| <------------------------------|________|
                                          CEA 
               
<CER> ::= < Diameter Header: 257, REQ >                          <CEA> ::= < Diameter Header: 257 >
    { Origin-Host }                                               { Result-Code =SUCCESS}
    { Origin-Realm }                                              { Origin-Host }
    { Host-IP-Address }                                           { Origin-Realm }
    { Vendor-Id }                                                 
{ Host-IP-Address }  
    { Product-Name }                                              { Vendor-Id } 
    [ Inband-Security-Id =s1 ]                                    { Product-Name } 
    [ Inband-Security-Id =s2]                                     [ Inband-Security-Id =s1 ]   
    [ Vendor-Specific-Application-Id =X]                          [ Vendor-Specific-Application-Id =X]
    [ Vendor-Specific-Application-Id =Y]
 
    [ Vendor-Specific-Application-Id =Z]  
 
                 CER/CEA Message Exchange