TCP / IP Suite

NARP

RFC1735 http://www.cis.ohio-state.edu/htbin/rfc/rfc1735.html

The NBMA Address Resolution Protocol (NARP) allows a source terminal (a host or router), wishing to communicate over a Non-Broadcast, Multi-Access (NBMA) link layer network, to find out the NBMA addresses of a destination terminal if the destination terminal is connected to the same NBMA network as the source.

The general format of the header is shown in the following illustration. The configuration varies according to whether the value of the type field is request type or reply type.

Version
NARP version number. Currently this value is 1.

Hop Count
Indicates the maximum number of NASs that a request or reply is allowed to traverse before being discarded.

Checksum
Standard IP checksum over the entire NARP packet (starting with the fixed header).

Type
NARP packet type. The NARP Request has a type code 1, NARP Reply has a type code 2.

Code
A response to an NARP request may contain cached information. If an authoritative answer is desired, then code 2 (NARP Request for Authoritative Information) should be used. Otherwise, a code value of 1 (NARP Request) should be used. NARP replies may be positive or negative. A positive, non-authoritative reply carries a code of 1, while a positive, authoritative reply carries a code of 2. A negative, non- authoritative reply carries a code of 3 and a negative, authoritative reply carries a code of 4.

Source and Destination IP Address
Respectively, these are the IP addresses of the NARP requestor and the target terminal for which the NBMA address is destined.

NBMA Length and NBMA Address
The NBMA length field is the length of the NBMA address of the source terminal in bits. The NBMA address itself is zero-filled to the nearest 32-bit boundary.

Interested in more details about testing this protocol?

SCSP

http://www.faqs.org/rfcs/rfc2334.html

SCSP is designed to serve distributed server entities that are bound to a Server Group (SG) through some means and need to synchronize the contents (or a portion thereof) of their caches, which contain information about the state of clients being served.

SCSP works as follows:
1 A Hello phase where two devices determine they can talk to one another.
2 Data base synchronization where it is determined whether one databases has information required by its neighbor and passes that information on to the neighbor.
3 New information learned is sent to all nodes on the link (apart from the node that supplied the new information).
This process is represented by the following three sub protocols. Hello, Cache Alignment and Cache State update.

• The Hello protocol is used to check connectivity between the sending server (the LS) and one of its directly connected neighbor servers (DCS).
• The Cache Alignment (CA) messages allow a Local Server (LS) to synchronize its entire cache with the cache of one of its Directly Connected Servers (DCSs).
• The Cache State Update protocol is used to update the state of cache entries in servers for a given SG (Server Group).
  SCSP messages contain a fixed part, a mandatory part and extensions.

The SCSP fixed part structure is as follows:

Type code
The code for the message type.

Packet size
Total length of the SCSP packet in octets (excluding link layer and/or other protocol encapsulation).

Checksum
The standard IP checksum over the entire SCSP packet, starting at the fixed header. If the packet is an odd number of bytes in length, this calculation is performed as if a byte set to 0x00 is appended to the end of the packet.

Start of extensions
When no extensions are present, this field has a value of zero. Otherwise, this field has the value of the offset (from the top of the fixed header to the beginning of the first extension). The mandatory part is specific to the message type. It contains the operation-specific information for the message type and in addition zero (or more) records which contain information concerning the state of a particular cache entry.

Record Types
Record types can be:

CSA Record
Cache State Advertisements (CSAs) are records within CSU messages, which identify updates to the status of specific cache entries.

CSAS Record
Cache State Advertisement Summary (CSAS) records contain a summary of the information in CSAs. During the cache alignment process, a server sends the CSAS records describing its cache entries to another server. In addition, when the LS requests an entire CSA from the DCS, it includes CSAS records in its CSUS messages. (The LS requests the CSA from the DCS because it assumes that the DCS has more recent information about the cache entry in question.)

Other message types are:

CSU Message
Cache State Update (CSU) messages are sent from the LS to the DCS when the LS becomes aware of a chance in the state of a cache entry.

CSUS Message
Cache State Update Solicit (CSUS) messages are sent from the LS to the DCS after the LS and DCS have exchanged CA messages. The CSUS message contains one or more CSAS records, representing solicitations for entire CSA records (as opposed to the summary information held in the CSAS).

CA Message
Cache Alignment (CA) messages allow a Local Server (LS) to synchronize its entire cache with the cache of one of its Directly Connected Servers (DCSs).

Hello Message
Hello messages are used to check connectivity between the sending server (the LS) and one of its directly connected neighbor servers (DCS).

Interested in more details about testing this protocol?

NHRP

RFC2332 http://www.cis.ohio-state.edu/htbin/rfc/rfc2332.html
draft http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-rolc-nhrp-15.txt

The NBMA Next Hop Resolution Protocol (NHRP) allows a source station (a host or router), wishing to communicate over a Non-Broadcast, Multi-Access (NBMA) subnetwork, to determine the internetworking layer addresses and NBMA addresses of suitable NBMA next hops toward a destination station.

The format of the header is shown in the following illustration:

ar$afn
Defines the type of link layer address being carried.

ar$pro.type
This field is a 16 bit unsigned integer.

ar$pro.snap
When ar$pro.type has a value of 0x0080, a snap encoded extension is being used to encode the protocol type. This snap extension is placed in the ar$pro.snap field; otherwise this field should be set to 0.

ar$hopcnt
The hop count. This indicates the maximum number of NHSs that an NHRP packet is allowed to traverse before being discarded.

ar$pktsz
The total length of the NHRP packet in octets.

ar$chksum
The standard IP checksum over the entire NHRP packet.

ar$extoff
This field identifies the existence and location of NHRP extensions.

ar$op.version
This field indicates what version of generic address mapping and management protocol is represented by this message.

ar$op.type
If the ar$op.version is 1 then this field represents the NHRP packet type. Possible values for packet types are:

ar$shtl
The type and length of the source NBMA address interpreted in the context of the address family number.

ar$sstl
The type and length of the source NBMA subaddress interpreted in the context of the "address family number".

Interested in more details about testing this protocol?

OSPF

RFC1583 http://www.cis.ohio-state.edu/htbin/rfc/rfc1583.html
This RFC has been replaced by RFC 2328.
The information on this page will be updated to suit the new RFC in the near future.

IETF RFC1583 defines the OSPF (Open Shortest Path First) protocol as a link-state routing protocol used for routing IP.

OSPF is an interior gateway protocol which is used for routing within a group of routers. It uses link-state technology in which routers send each other information about the direct connections and links which they have to other routers.

The OSPF header structure is shown in the illustration below.

Version number
Protocol version number (currently 1).

Packet type
Valid types are as follows:

Packet length
The length of the protocol packet in bytes. This length includes the standard OSPF header.

Router ID
The router ID of the packet’s source. In OSPF, the source and destination of a routing protocol packet are the two ends of an (potential) adjacency.

Area ID
A 32-bit number identifying the area that this packet belongs to. All OSPF packets are associated with a single area. Most travel a single hop only. Packets traveling over a virtual link are labeled with the back bone area ID of 0.0.0.0.

Checksum
The standard IP checksum of the entire contents of the packet, starting with the OSPF packet header but excluding the 64-bit authentication field. This checksum is calculated as the 16-bit one’s complement of the one’s complement sum of all the 16-bit words in the packet, except for the authentication field. If the packet length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming.

AU type
Identifies the authentication scheme to be used for the packet.

Authentication
A 64-bit field for use by the authentication scheme.

Enlarge	More Details

Interested in more details about testing this protocol?

TRIP
ftp://ftp.isi.edu/in-notes/rfc3219.txt

The function of TRIP (Telephony Routing over IP) is to advertise the reachability of telephony destinations, attributes associated with the destinations, as well as the attributes of the path towards those destinations.
TRIP can be used to manage routing tables for multiple protocols (SIP, H323, etc.). In TRIP, a destination is the combination of (a) a set of addresses (given by an address family and address prefix), and (b) an application protocol (SIP, H323, etc). The structure of the TRIP protocol header is as follows:

Length
Total length of message inclucing the header in octets

Type
The type code of the message. The following type codes are available:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE

Interested in more details about testing this protocol?

ISTP

http://www.packetcable.com/specifications/specifications10.html
PKT-SP-ISTP-I02-011221

ISTP (Internet Signaling Transport Protocol for PacketCable PSTN signaling gatways) is a protocol that provides a signaling interconnection service between the PacketCable network control elements (Call Management Server and Media Gateway Controller) and the PSTN SS7 Signaling network through the SS7 Signaling Gateway. ISTP contains features for initialization; address mapping from the SS7 domain to the IP domain; message delivery for SS7 ISUP and TCAP; congestion management, fault management, maintenance operations; and redundant configuration support.

ISTP bridges the gap between basic IP transport mechanisms and application level signaling. Although not a translation of the SS7 MTP3 and SCCP protocols, ISTP implements analogues to some of the MTP3 and SCCP functions in a fashion appropriate to distributed systems communicating over an IP network. It describes the protocol to implement SS7 signaling interconnection in a distributed PacketCable PSTN Gateway architecture. Specifically, it defines the messages and procedures for transporting SS7 ISUP, TCAP, and TUP messages between the PacketCable control functions (Media Gateway Controller and Call Management Server) and the SS7 Signaling Gateway.

In order to meet the performance and reliability requirements mandated by the PacketCable Service Requirements Specification and SS7 interconnection, ISTP requires the services of an underlying reliable transport service. The reliable transport provided by the Stream Control Transport Protocol (SCTP) as defined in the IETF SIGTRAN is the preferred solution; however, managed TCP over IP network may be used as an alternative. The header structure appears as follows:

The parameter structure appears as follows:

MessageType
Identifies the message type.
The following message types are available:

MessageNature
Identifies requests, responses or indications.
The following values are available for the message nature:

MessageLength
Length of the message to follow.

ParameterId
The identifier of the parameter to follow.

ParameterLength
The length of the parameter to follow.

ParameterContent
The content of the parameter specified.

Various other parameters are available.

Interested in more details about testing this protocol?

Mobile IP

RFC 2002: http://www.cis.ohio-state.edu/htbin/rfc/rfc2002.html
RFC 2290: http://www.cis.ohio-state.edu/htbin/rfc/rfc2290.html
RFC 2344: http://www.isi.edu/in-notes/rfc2344.txt

The Mobile IP protocol enables nodes to move from one IP subnet to another. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol allows registration of the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. It can be used for mobility across both homogeneous and heterogeneous media. Mobile IP defines a set of new control messages, sent with UDP, Registration Request and Registration Reply.
The IP packet consists of the IP source and destination addresses, followed by the UDP source and destination ports, followed by the Mobile IP fields. Mobile IP packets can be either registration request or registration reply.
The format of the Mobile IP registration request message is shown in the following illustration:

Type
1 signifies a registration request.

S
Simultaneous bindings. When set, the mobile node is requesting that the home agent retain its prior mobility bindings.

B
Broadcast datagrams. When set, the mobile node requests that the home agent tunnel to it any broadcast datagrams that it receives on the home network.

D
Decapsulation by mobile node. When set, the mobile node will itself decapsulate datagrams which are sent to the care-of address. In other words, the mobile node is using a co-located care-of address.

M
Minimal encapsulation. When set, the mobile node requests that its home agent use minimal encapsulation for datagrams tunneled to the mobile node.

G
GRE encapsulation. When set, the mobile node requests that its home agent use GRE encapsulation for datagrams tunneled to the mobile node.

V
The mobile node requests that its mobility agent use Van Jacobson header compression over its link with the mobile node.

T
When set, the mobile node asks its home agent to accept a reverse tunnel from the care-of address. Mobile nodes using a foreign agent care-of address ask the foreign agent to reverse-tunnel its packets.

Rsv
Reserved bit, set to zero.

Lifetime
The number of seconds remaining before the registration expires.

Home address
IP address of the mobile node.

Home agent
IP address of the mobile node’s home agent.

Care-of address
IP address for the end of the tunnel.

Identification
A 64-bit number, constructed by the mobile node, used for matching registration requests with registration replies, and for protecting against replay attacks of registration messages.

Extensions
The fixed portion of the registration request is followed by one or more of the extensions listed in Section 3.5 of RFC2002. The Mobile-Home Authentication Extension must be included in all registration requests.
The format of the Mobile IP registration reply message is shown in the following illustration:

Type
3 indicates a registration reply.

Lifetime
If the Code field indicates that the registration was accepted, the Lifetime field is set to the number of seconds remaining before the registration expires. A value of zero indicates that the mobile node has been deregistered. A value of 0xffff indicates infinity. If the Code field indicates that the registration was denied, the contents of the Lifetime field are unspecified and are ignored on reception.

Interested in more details about testing this protocol?

RUDP

Draft-ietg-sigtran-reliable-udp-00.txt (1999)

The Reliable UDP protocol is a simple packet based transport protocol, based on RFCs 1151 and 908. A reliable transport protocol is needed to transport telephony signalling across IP networks. This should provide architecture for a variety of signalling protocols needing transport over IP. RUDP is designed to allow characteristics of each connection to be individually configured so that a number of protocols with different transport requirement can be implemented simultaneously not on the same platform. It is layered on the UDP/IP protocols and provides reliable in-order delivery (up to a maximum number of retransmissions) for virtual connections. RUDP has a very flexible design that would make it suitable for a variety of transport uses. One such use would be to transport telecommunication-signalling protocols.

RUDP Header

Each UDP packet sent by RUDP must start with at least a 6-octet header. The first octet contains a series of single bit flags. The next 3 fields are one octet in size. They are followed by a 2-octet checksum.

Control bits
The 8 control bits are altogether one byte in length and indicate what is present in the packet.

SYN
The SYN bit indicates a synchronization segment is present.

ACK
The ACK bit indicates the acknowledgment number in the header is valid.

EACK
The EACK bit indicates an extended acknowledge segment is present.

RST
The RST bit indicates the packet is a reset segment.

NUL
The NUL bit indicates the packet is a null segment.

CHK
The CHK bit indicates whether the Checksum field contains the checksum of just the header or the header and the body (data).

TCS
The TCS bit indicates the packet is a transfer connection state segment.

0
The value of this field must be zero.

Header length
It is one byte in length and indicates where user data begins in the packet.

Sequence number
When a connection is first opened, each peer randomly picks an initial sequence number. This sequence number is used in the SYN segments to open the connection. Each transmitter increments the sequence number before sending a data, null, or reset segment. It is one byte in length.

Acknowledgement number
The acknowledgment number field indicates to a transmitter the last in- sequence packet the receiver has received. It is one byte in length.

Checksum
The checksum is always calculated on the RUDP header to ensure integrity. The checksum here is the same algorithm used in UDP and TCP headers.

Segments

The following segments can appear in the packet: SYN, Ack EACK, RST, NUL and TCS segments:

The Syn segment
The SYN is used to establish a connection and synchronize sequence numbers between two hosts. The SYN segment also contains the negotiable parameters of the connection. All configurable parameters that the peer must know about are contained in this segment. This includes the maximum number of segments the local RUDP is willing to accept and option flags that indicate the features of the connection being established.

Ack segment
The Ack segment is used to acknowledge in-sequence segments. It contains both the next send sequence number and the acknowledgement sequence number in the RUDP header.

The Eack segment:
The EACK segment is used to acknowledge segments received out of sequence. It contains the sequence numbers of one or more segments received out of sequence. The EACK is always combined with an ACK in the segment, giving the sequence number of the last segment received in sequence. The header length is variable for the EACK segment. Its minimum value is seven and its maximum value depends on the maximum receive queue length.

RST segment
This is used to close or reset a connection. Upon receipt of an RST segment, the sender must stop sending new packets, but continue to attempt delivery of packets already accepted from the API.

NUL segment
This segment is used to determine whether the other side of a connection is still active. When a NUL segment is received, an RUDP implementation must immediately acknowledge the segment if a valid connection exists and the segment acknowledge number is the next one in sequence.

TCS segment
The TCS is used to transfer the state of connection.

Interested in more details about testing this protocol?

TALI

http://search.ietf.org/internet-drafts/draft-benedyk-sigtran-tali-00.txt

This protocol proposes the interfaces of a Signalling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. Since the Gateway is the central point of signalling information, not only does it provide transportation of signalling from one network to another, but can also provide additional functions such as protocol translation, security screening, routing information, and seamless access to Intelligent Network (IN) services on both networks.
The Transport Adapter Layer Interface (TALI) protocol provides TCAP, ISUP, and MTP messaging over TCP/IP and is used to support reliable communication between the SS7 Signalling Network and applications residing within the IP network.
This version of TALI provides 3 SS7 signalling transport methods and provides functionality for MTP over TCP/IP (lmtp3), SCCP/TCAP over TCP/IP (sccp), and ISUP over TCP/IP (isot). These three methods comprise the service messages.
The following is a description of the TALI payload:

SYNC
Four bytes must be (54 41 4C 49) TALI in ASCII.

Length
The length of the frame. Non zero if message contains a Service or Monitor Socket message.
Service message data:
The service message data.

Interested in more details about testing this protocol?

Van Jacobson

RFC1144 http://www.cis.ohio-state.edu/htbin/rfc/rfc1144.html

Van Jacobson is a compressed TCP protocol which thereby improves the TCP/IP performance over low speed (300 to 19,200 bps) serial links.

The format of the compressed TCP is as follows:

	C	I	P	S	A	W	U
Connection number (C)
TCP checksum
Urgent pointer (U)
D Window (W)
D Ack (A)
D Sequence (S)
D IP ID (I)
data
Compressed TCP structure

C, I, P, S, A, W, U
Change mask. Identifies which of the fields expected to change per-packet actually changed.

Connection number
Used to locate the saved copy of the last packet for this TCP connection.

TCP checksum
Included so that the end-to-end data integrity check will still be valid.

Urgent pointer
This is sent if URG is set.

D values for each field
Represent the amount the associated field changed from the original TCP(for each field specified in the change mask).

Interested in more details about testing this protocol?

XOT

RFC1613 http://www.cis.ohio-state.edu/htbin/rfc/rfc1613.html

XOT is Cisco Systems X.25 over TCP.
(Compliant with IETF RFC1613).

The format of the header is shown in the following illustration:

Version
The version number.

Length
The length of the packet.

Interested in more details about testing this protocol?

1 2 3 4 5 6 7 8 9

TCP/IP Family Protocol Information
AH | ATMP | ARP/RARP | BGMP | BGP-4 | COPS | DCAP | DHCP | Diameter | DIS | DNS | DVMRP | EGP | EIGRP | ESP | FANP | Finger | FTP | HSRP | HTTP | ICMP/ICMPv6 | IGMP | IGRP | IMAP4 | IMPPpre/IMPPmes | IPDC | IP | IPv6 | IRC | ISAKMP | ISAKMP/IKE | iSCSI | ISTP | ISP | LDAP | L2F | L2TP | MARS | Mobile IP | MZAP | NARP | NetBIOS/IP | NHRP | NTP | OSPF | PIM | POP3 | PPTP | Radius | RLOGIN | RIP2 | RIPng for IPv6 | RSVP | RTSP | RUDP | SCTP | S-HTTP | SLP | SMTP | SNMP | SOCKS | TACACS+ | TALI | TCP | TELNET | TFTP | TLS | TRIP | UDP | Van Jacobson | VRRP | WCCP | X-Window | XOT