TCP/IP: physical, network interface (SLIP and PPP), internet (IP, ICMP and routing protocols), transport (TCP and UDP) and application (http, ftp, smtp, snmp, dhcp and dns)
IP -> addressing, delivery, datagram packaging, fragmentation and reassembly.
TCP/UDP -> encapsulating user data and managing connections
TCP/IP suite is client/server network communication
PPP is connection-oriented and runs on top of physical link (serial, dialup, ISDN..)
+ encapsulating higher layer protocol datagrams
+ LCP: setup, maintain and terminate link b/w two devices and many configuration parameters to be exchanged to ensure that both devices agree on how the link will be used
+ NCP: PPP supports the encapsulation of many different layer three datagram types. Some of these require additional setup before the link can be activated. After the general link setup is completed with LCP, control is passed to the PPP Network Control Protocol (NCP) specific to the layer three protocol being carried on the PPP link. For example, when IP is carried over PPP the NCP used is the PPP Internet Protocol Control Protocol (IPCP).
LCP support protocols: CHAP and PAP
LCP optional feature protocols: the PPP Compression Control Protocol (CCP) allows compression of PPP data, the PPP Encryption Control Protocol (ECP) enables datagrams to be encrypted for security, and the PPP Multilink Protocol (PPP MP) allows a single PPP link to be operated over multiple physical links
LCP: Configure-Request
Configure-Ack: all options in Configure-Request are recognizable and okay to end B
Configure-Nak: all options are recognizable but some values are not okay to end B. This msg includes those options end B doesnt like
Configure-Reject: some options or not recognizable or non negotiable for end B. msg includes all those options.
Echo-Request --> for loopback test -- to test the link
Echo-Reply
Terminate-Request
Terminate-Ack
PAP (Password Authentication Protocol):
Authenticatie-Request: contains user name password in clear text; sent by end A which is initiating the link.
Authenticate-Ack
Authenticate-Nak
CHAP (Challenge Handshake Authentication Protocol):
Challenge: sent by end B after LCP; simple text message called challenge text
Response: end A uses its password and encrypts the challenge text and sends it in Response
Success/Failure: end B does the same. Informs end A success or failure.
PPP general header format:
Flag (1 byte): indicates start of the frame; always has the value 0x7e
Address (1 byte): as it is point-to-point, this is always 0xff
Control (1 byte): always 0x03
Protocol (2 bytes): identifies the protocol of the datagram encapsulated (for IP, it is 0x0021; for IPCP, it is 0x8021)
Information(variable):
Padding(variable):
FCS (2 or 4 bytes): checksum
Flag(1 byte): indicates end of the frame; always 0x7e
PPP control header format:
Code: type of the control msg (configure-request, configure-ack...)
Identifier: new id is generated for each new request. ack/nak/reject copies id from request.
Length: total length of the control msg
Data: data of the msg
IP addressing schemes:
Classful: dividing line occurs only in one of a few locations: on octet boundaries. Three main classes of addresses, A, B and C are differentiated based on how many octets are used for the network ID and how many for the host ID. For example, class C addresses devote 24 bits to the network ID and 8 to the host ID.
+ address follows rules of A, B, C or D classes
Subnetted Classful Addressing: In the subnet addressing system, the two-tier network/host division of the IP address is made into a three-tier system by taking some number of bits from a class A, B or C host ID and using them for a subnet identifier. The network ID is unchanged. The subnet ID is used for routing within the different subnetworks that constitute a complete network. For example, consider a class C address that normally uses the first 24 bits for the network ID and remaining 8 bits for the host ID. The host ID can be split into, say, 3 bits for a subnet ID and 5 for the host ID.
The dividing line between the subnet ID and the “sub-host” ID is indicated by a 32-bit number called a subnet mask. In the example above, the subnet mask would be 27 ones followed by 5 zeroes—the zeroes indicate what part of the address is the host. In dotted decimal notation, this would be 255.255.255.224.
Classless Addressing: The division between the network ID and host ID can occur at an arbitrary point, not just on octet boundaries like in the “classful” scheme.
The dividing point is indicated by putting the number of bits used for the network ID, called the prefix length, after the address (recall that the network ID bits are also sometimes called the network prefix, so the network ID size is the prefix length). For example, if 227.82.157.177 is part of a network where the first 27 bits are used for the network ID, that network would be specified as 227.82.157.160/27. The “/27” is conceptually the same as the 255.255.255.224 subnet mask, since it has 27 one bits followed by 5 zeroes.
Software Routing:
If a host has interfaces to two or more different networks, then could it not pass IP datagrams between them? Of course, it certainly could, if it had the right software running on it. If it does this, wouldn't that make the host a router, of sorts? In fact, that is exactly the case! A multihomed host with interfaces to two networks can use software to function as a router. This is sometimes called software routing.
Using a host as a router has certain advantages and disadvantages compared to a hardware router. A server that is multihomed can perform routing functions and also, well, act as a server. A dedicated hardware router is designed for the job of routing and usually will be more efficient than a software program running on a host.
Suppose you have two PCs networked together and a single phone line to connect to the Internet. One computer dials up to your Internet Service Provider, and runs software such as Microsoft's Internet Connection Sharing (ICS) to let the other computer access the Internet. Millions of people do this every day—they have a multihomed system (the one connecting to the Internet and the other PC) with ICS acting in the role of a software router (though there are some technical differences between ICS and a true router, of course.)
IP header format: 20 bytes is standard
Version
IP Header Length
Type Of Service: Precedence, D (Delay - 0 for normal delay in delivery and 1 for low delay delivery), T (Throughput - 0 for normal delivery throughput; 1 for higher throughput delivery), R (Reliability - 0 for normal reliablity; 1 for higher reliablity delivery)
Total Length
Identification - common to each of the fragments belonginging to a particular msg.
Flags - DF: Dont Fragment - upper layers use this flag to test MTU of a link by setting this flag; MF: More Fragments - if 0, indicates last fragment. if 1, more fragments are coming
Fragment Offset
Time To Live
Protocol: higher layer protocol
Header Checksum
Source Address
Destination Address
Options
Padding
Data
Mobile IP:
in the computer world, when a device travels using Mobile IP, things are more complicated. Suppose our consultant flies to Tokyo, turns on his notebook and plugs it in to the network. When the notebook is first turned on, it has no clue what is going on. It has to figure out that it is in Tokyo. It needs to find a foreign agent in Tokyo. It needs to know what address to use while in Tokyo. It needs to communicate back with its home agent back in London to tell it that it is in Tokyo and to start forwarding datagrams. Furthermore, it must accomplish its communication without any “telephone”.
To this end, Mobile IP includes a host of special functions that are used to set up and manage datagram forwarding. To see how these support functions work, we can describe the general operation of Mobile IP as a simplified series of steps:
Agent Communication: The mobile node finds an agent on its local network by engaging in the Agent Discovery process. It listens for Agent Advertisement messages sent out by agents and from this can determine where it is located. If it doesn't hear these messages it can ask for one using an Agent Solicitation message.
Network Location Determination: The mobile node determines whether it is on its home network or a foreign one by looking at the information in the Agent Advertisement message.
If it is on its home network it functions using regular IP. To show how the rest of the process works, let's say the device sees that it just moved to a foreign network. The remaining steps are:
Care-Of Address Acquisition: The device obtains a temporary address called a care-of address. This either comes from the Agent Advertisement message from the foreign agent, or through some other means. This address is used only as the destination point for forwarding datagrams, and for no other purpose.
Agent Registration: The mobile node informs the home agent on its home network of its presence on the foreign network and enables datagram forwarding, by registering with the home agent. This may be done either directly between the node and the home agent, or indirectly using the foreign agent as a conduit.
Datagram Forwarding: The home agent captures datagrams intended for the mobile node and forwards them. It may send them either directly to the node or indirectly to the foreign agent for delivery, depending on the type of care-of address in use.
Datagram forwarding continues until the current agent registration expires. The device can then renew it. If it moves again, it repeats the process to get a new care-of address and then registers its new location with the home agent. When the mobile node returns back to its home network, it deregisters to cancel datagram forwarding and resumes normal IP operation.
Foreign Agent Care-Of Address
This is a care-of address provided by a foreign agent in its Agent Advertisement message. It is, in fact, the IP address of the foreign agent itself. When this type of care-of address is used, all datagrams captured by the home agent are not relayed directly to the mobile node, but indirectly to the foreign agent, which is responsible for final delivery.
Co-Located Care-Of Address
This is a care-of address assigned directly to the mobile node using some means external to Mobile IP. For example, it may be assigned on the foreign network manually, or automatically using DHCP. In this situation, the care-of address is used to forward traffic from the home agent directly to the mobile node. The co-located care-of address has the advantage that traffic can be forwarded directly from the home agent to the mobile node. In this type of arrangement, it is possible for a Mobile IP device to travel to a foreign network where there is no Mobile-IP-aware router to act as a foreign agent. This does mean, however, that the Mobile IP implementation must include all the functions of communicating with the home agent that the foreign agent normally performs.
Mobile nodes are required to accept and process Agent Advertisements. They distinguish these from regular Router Advertisements by looking at the size of the message.
-> listen for agent advertisements
-> if not, send agent solicitation messges
-> by looking at the size of the msg, node learns it is regular icmp or icmp msgs with mobile ip extension
-> agent advt contains one or more care-of-addresses
-> register with home agent of the home network with the new care-of-address to establish mobility binding in ha (Registration-Request and Registratino-Reply: these are not icmp, but UDP messages on port 434)
-> need to re-register before expiry or de-register
-> The home agent will intercept datagrams intended for the mobile node as they are routed to its home network, and forward them to the mobile node. This is done by encapsulating the datagrams and then sending them to the node's care-of address.
The default encapsulation process used in Mobile IP is called IP Encapsulation Within IP, defined in RFC 2003 and commonly abbreviated IP-in-IP. It is a relatively simple method that describes how to take an IP datagram and make it the payload of another IP datagram.
In addition to IP-in-IP, two other encapsulation methods may be optionally used: Minimal Encapsulation Within IP, defined in RFC 2004, and Generic Routing Encapsulation (GRE), defined in RFC 1701. To use either of these, the mobile node must request the appropriate method in its Registration Request and the home agent must agree to use it. If foreign agent care-of addressing is used, the foreign agent also must support the method desired.
---> The encapsulation process creates a LOGICAL construct called a tunnel between the device that encapsulates and the one that decapsulates.
Normally, the tunnel described above is used only for datagrams that have been sent to the mobile node and captured by the home agent. When the mobile nodes wants to send a datagram, it doesn't tunnel it back to the home agent; this would be needlessly inefficient. Instead it just sends out the datagram directly using whatever router it can find on its current network, which may or may not be a foreign agent. When it does this, it uses its own home address as the source address for any requests it sends. As a result, any response to those requests will go back to the home network. This sets up a “triangle” of sorts for these kinds of transactions:
The mobile node sends a request from the foreign network to some third party device somewhere on the internetwork.
The third party device responds back to the mobile node. However, this sends the reply back to the mobile node's home address on its home network.
The home agent intercepts the response on the home network and tunnels it back to the mobile node.
--> There may be situations where it is not feasible or desired to have the mobile node send datagrams directly to the internetwork using a router on the foreign network as we just saw. In this case, an optional feature called reverse tunneling may be deployed, if it is supported by the mobile node, the home agent and if relevant, the foreign agent.
All transmissions from the mobile node are tunneled back to the home network where the home agent transmits them over the internetwork
--> One situation where reverse tunneling may be required is if the network where the mobile node is located has implemented certain security measures that prohibit the node from sending datagrams using its normal IP address. In particular, a network may be set up to disallow outgoing datagrams with a source address that doesn’t match its network prefix. This is often done to prevent “spoofing”
Difficulties with mobileIP and ARP:
What happens when a local device on the home network itself wants to transmit to a mobile node that has traveled elsewhere? Remember that this device may not be mobile itself and probably knows nothing about Mobile IP. It will follow the standard process for deciding what to do with a datagram it needs to send as explained in the topic discussing direct and indirect delivery of IP datagrams. It will compare its network ID to that of the mobile node and realize it doesn't need to route its datagram; it can send it directly to the mobile node.
The local host will attempt to use ARP to find the data link layer address of the mobile node so it can send the datagram to it directly. It will start by looking in its ARP cache and if it finds the node's data link layer address there, will use it to send at layer two. Of course the mobile node is no longer on the local network segment so the message will never be received. If there is no ARP cache entry, the host on the home network will attempt to send an ARP Request to the mobile node to determine its layer two address. Again, the mobile node has traveled away, so this request will go unanswered.
Solving this problem requires the intervention of, you guessed it, the home agent. It must perform two tasks to enable local hosts to send to the mobile node:
ARP Proxying: The home agent must listen for any ARP Requests sent by nodes on the same network as any of the mobile nodes that are currently registered to it. When it hears one, it replies in the mobile node's stead, and specifies its own data link layer address as the binding for the mobile node's IP address. This will cause hosts on the home network to send any datagrams intended for the mobile node to the home agent where they can be forwarded. This process is illustrated in Figure 135.
“Gratuitous” ARP: Proxying helps with ARP Requests but what about devices that already have cache entries for the mobile node? As soon as the mobile node leaves the network, these become automatically stale. To correct them, the home agent sends what is called a gratuitous ARP message that tells devices on the local network to associate the mobile node's IP address with the home agent's data link layer address. The term “gratuitous” refers to the fact that the message isn't being sent in order to perform an actual address resolution but merely to cause caches to be updated. It may be sent more than once to ensure that every device “gets the message”.
NAT:
Network Address Port Translation: Source address and source port are translated. Checksum is recalculated for ip and tcp headers.
UDP:
Message format:
Source Port -- usually ephemeral (temporary) port
Destination Port -- well-known/registered port
Length
Checksum -- instead of calculating the checksum over just the fields in the UDP datagram itself, the UDP software first constructs a “fake” additional header that contains the following fields: The IP Source Address field, The IP Destination Address field, The IP Protocol field, The UDP Length field. The total length of this “pseudo header” is 11 bytes. It is padded to 12 bytes with a byte of zeroes and then prepended to the real UDP message. The checksum is then computed over the combination of the pseudo header and the real UDP message, and the value is placed into the Checksum field. The pseudo header is used only for this calculation and is then discarded; it is not actually transmitted. The UDP software in the destination device creates the same pseudo header when calculating its checksum to compare to the one transmitted in the UDP header. Computing the checksum over the regular UDP fields protects against bit errors in the UDP message itself. Adding the pseudo header allows the checksum to also protect against other types of problems as well, most notably the accidental delivery of a message to the wrong destination.
Data
TCP:
TCP is said to treat data coming from an application as a stream; thus, the description of TCP as stream-oriented. Each application sends the data it wishes to transmit as a steady stream of octets (bytes). It doesn't need to carve them into blocks, or worry about how lengthy streams will get across the internetwork. It just “pumps bytes” to TCP. Of course, TCP must take these bytes and send them using a network-layer protocol, meaning the Internet Protocol. IP is a message-oriented protocol, not stream-oriented. Thus, we have simply “passed the buck” to TCP, which must take the stream from the application and divide it into discrete messages for IP. These messages are called TCP segments. They are placed into IP datagrams and transmitted to the destination device. The recipient unpackages the segments and passes them to TCP, which converts them back to a byte stream to send to the application.
-- each byte will have sequence id
-- tcp breaks the byte stream into segments
-- receiving end acks with the sequence # of the last byte in the last segment it received
type of TCP control messages:
SYN: A synchronize message, used to initiate and establish a connection. It is so named since one of its functions is to synchronizes sequence numbers between devices.
FIN: A finish message, which is a TCP segment with the FIN bit set, indicating that a device wants to terminate the connection.
ACK: An acknowledgment, indicating receipt of a message such as a SYN or a FIN.
--> socket 'bind': Server creates Transmission Control Block during passive open (socket opens; listens to well-known port; waits for connections). When SYN is received from client, It then binds the socket number of the client to the TCB for the passive OPEN as part of the connection process
Connection Establishment:
client server
CLOSED CLOSED
(passive open; create TCB) -> LISTEN
(active open; create TCB; send SYN) -> SYN-SENT
SYN-RECEIVED -> after receiving SYN, it sends SYN+ACK in the same segment
ESTABLISHED (receives SYN+ACK, sends ACK)
ESTABLISED
--> Client: Sequence Number X is sent with SYN
Server: in its SYN+ACK msg, sends Acknowledgement Number as X+1 and its own Sequence Number Y
Client: Sends ACK msg with Acknowledgement Number as Y+1
--> SYN messages are used to exchange MSS (Maximum Segment Size) -- Each device sends the other the MSS that it wants to use for the connection, if it wishes to use a non-default value. When receiving the SYN, the server records the MSS value that the client sent, and will never send a segment larger than that value to the client. The client does the same for the server. The client and server MSS values are independent, so a connection can be established where the client can receive larger segments than the server or vice-versa.
Connection Termination: termination isn't a three-way handshake like establishment: it is a pair of two-way handshakes. The states that the two devices in the connection move through during a normal connection shutdown are different because the device initiating the shutdown must behave differently than the one that receives the termination request. In particular, the TCP on the device receiving the initial termination request must inform its application process and wait for a signal that the process is ready to proceed. The initiating device doesn't need to do this, since the application is what started the ball rolling in the first place.
client server
ESTABLISHED ESTABLISHED
receives close signal from upper layer app
(send FIN) FIN-WAIT-1
(receive FIN; send ACK; tell app to close) CLOSE_WAIT
(receive ACK) FIN-WAIT-2
wait for app to close
app is ready to close
(send FIN) LAST-ACK
(FIN received; send ACK) TIME-WAIT
(ACK received) CLOSED
wait for double Maximum Segment Lifetime
to ensure the ACK it sent was received
(standard says it is 120 sec)
CLOSED
TCP header format:
Source Port
Destination Port
Sequence Number -- For normal transmissions, the sequence number of the first byte of data in this segment. In a connection request (SYN) message, this carries the initial sequence number (ISN) of the source TCP
Acknowledgement Number
Data Offset
Rserved
Control Bits -- URG (urgent bit - priority data transfer), ACK, PSH (data be immediately pused to app on receving side), RST (sender encoutered a prob so want to reset the connection), SYN, FIN
Window -- Indicates the number of octets of data the sender of this segment is willing to accept from the receiver at one time.
Checksum
Urgent Pointer
Options -- includes MSS and others
Padding
Data
PDSN:
The A10/A11 (also known as R-P interface) provides a signaling (A11) and user data (A10) path between the CDMA2000 Radio Access Network (CDMA2000 or HRPD 1xEV-DO) and the PSDN using the Internet Protocol (IP).
The A10 interface is a connection-oriented interface and one A10 connection is set up for each packet data call/session. The A10 connection is set up and released using A11 signaling as described in IS-2001. Once the A11 registration process for connection set up is successful, the user IP/PPP data is carried using GRE headers over IP on the A10 connection.
the R-P interface connection is set up
using A11 signaling defined in IS-2001. Once the A11 registration
process is successful, the user PPP data is carried over IP using
GRE encapsulation. For Simple IP service, the PDSN establishes a
PPP link to the mobile station and in the process assigns a dynamic
IP address to the mobile station. The address could be a dynamic IP
address taken from a local pool every time the user sets up a PPP
link. It could also be a static IP address associated with the user
profile, which is received from the USIS in the access accept
message and assigned to the mobile station at the time of IPCP
negotiation.
-> mobile station sends an Origination/Connection Request
Message with Layer 2 Ack required indication over the Access
Channel to the BS.
-> The BSS acknowledges the receipt of the Message with a Base
Station Ack to the mobile.
-> The BSS constructs a CM Service Request message, places it in
the Complete Layer 3 Information message, sends the message
to the MSC
-> The MSC sends an Assignment Request message to the BSS
requesting assignment of radio resources
-> The BSS and the mobile station perform radio
resources setup procedures if the mobile is not already on a
traffic channel
-> The BSS recognizes that no A10 connection associated with this
mobile is available and selects a PDSN for this call. The BSS
sends an A11-Registration Request message to the selected
PDSN.
-> The A11-Registration Request is validated and the PDSN
accepts the connection by returning an A11-Registration Reply
message. Both the PDSN and the BSS create a binding record for the A10
connection.
-> The service negotiation is done and service connect and RLP
setup has taken place, and A10 connection are set up. The BSS
sends an Assignment Complete message to the MSC.
-> The mobile station and the PDSN establish the link layer (PPP)
connection. In the PPP negotiation phase, the mobile station
indicates whether it requires Mobile IP or Simple IP service
-> After PPP link setup and, in the case of Mobile IP service, after
completion of Mobile IP registration, the mobile can send/receive
data via GRE encapsulation of PPP packets over the A10
connection.
===> The physical layer of the A10/A11 interface between CRAN and the PDSN
is implemented with a combination of OC3 and Fast Ethernet. CRAN
has an ATM PVC connection (over OC3) to the first-hop router along
the route to the PDSN. The PDSN supports Fast Ethernet interface
for user data only. CRAN and the PDSN are assumed to connect
using a private network.
C++
// classes example
#include
using namespace std;
class CRectangle {
int x, y;
public:
void set_values (int,int);
int area () {return (x*y);}
};
void CRectangle::set_values (int a, int b) {
x = a;
y = b;
}
int main () {
CRectangle rect;
rect.set_values (3,4);
cout << "area: " << rect.area(); return 0;
}
operator of scope (::, two colons) is used to define a member of a class from outside the class definition itself. You may notice that the definition of the member function area() has been included directly within the definition of the CRectangle class given its extreme simplicity, whereas set_values() has only its prototype declared within the class, but its definition is outside it. In this outside declaration, we must use the operator of scope (::) to specify that we are defining a function that is a member of the class CRectangle and not a regular global function. The scope operator (::) specifies the class to which the member being declared belongs, granting exactly the same scope properties as if this function definition was directly included within the class definition. For example, in the function set_values() of the previous code, we have been able to use the variables x and y, which are private members of class CRectangle, which means they are only accessible from other members of their class. basic concept of object-oriented programming: Data and functions are both members of the object. We no longer use sets of global variables that we pass from one function to another as parameters, but instead we handle objects that have their own data and functions embedded as members. Notice that we have not had to give any parameters in any of the calls to rect.area or rectb.area. Those member functions directly used the data members of their respective objects rect and rectb.
constructor and destructor:
// example on constructors and destructors
#include
using namespace std;
class CRectangle {
int *width, *height;
public:
CRectangle (int,int);
~CRectangle ();
int area () {return (*width * *height);}
};
CRectangle::CRectangle (int a, int b) {
width = new int;
height = new int;
*width = a;
*height = b;
}
CRectangle::~CRectangle () {
delete width;
delete height;
}
int main () {
CRectangle rect (3,4), rectb (5,6);
cout << "rect area: " << rect.area() << endl;
cout << "rectb area: " << rectb.area() << endl;
return 0;
}
C vs C++
Classes can be defined not only with keyword class, but also with keywords struct and union.
The concepts of class and data structure are so similar that both keywords (struct and class) can be used in C++ to declare classes (i.e. structs can also have function members in C++, not only data members). The only difference between both is that members of classes declared with the keyword struct have public access by default, while members of classes declared with the keyword class have private access. For all other purposes both keywords are equivalent.
