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
Hop Count
Checksum
Type Code Unused
Destination IP address
Source IP address
NBNA Len.
NBMA address (variable length)
NARP header structure
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? click here   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:

0        1              2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Version Type code Packet size
Checksum Start of extensions
SCSP header structure
Version The version of the SCSP protocol that is used. The current version is 1.

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? click here

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:

8
16
24
32 bits
ar$afn
ar$pro.type
ar$pro.snap
ar$pro.snap
ar$hopcnt
ar$pkstz
ar$chksum
ar$extoff
ar$op.version
ar$op.type
ar$shtl ar$sstl
NHRP header structure
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:
1 NHRP Resolution Request.
2 NHRP Resolution Reply.
3 NHRP Registration Request.
4 NHRP Registration Reply.
5 NHRP Purge Request.
6 NHRP Purge Reply.
7 NHRP Error Indication.
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? click here   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.

8
16
32 bits
Version No.
Packet Type
Packet length
Router ID
Area ID
Checksum
AU type
Authentication
OSPF header structure
Version number Protocol version number (currently 1). Packet type Valid types are as follows:
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment.
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.
Interested in more details about testing this protocol? click here   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:

0
1
2
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
0
Length
Type
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? click here   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:

8

7

6

5

4

3

2

1

Octet

    Message Type

1

Message Nature
2
Message Length
3-4

Parameters

5-n

Parameter Structure The parameter structure appears as follows:

8

7

6

5

4

3

2

1

Octet

Parameter ID

1-2

Parameter Length

3-4

Parameter Content

5-n

The header parameters are as follows: MessageType Identifies the message type. The following message types are available:
Circuit-Registration 0
Circuit-De-Registration 1
Circuit-Activation 2
Exclusive-Circuit-Activation 3
Circuit-Deactivation 4
Forced-Circuit-Deactivation 5
New-Work-Circuit-Activation 6
New-Work-Circuit-Deactivation 7
Subsystem- Registration 8
Subsystem- De-Registration 9
Subsystem- Activation 10
Exclusive-Subsystem- Activation 11
Subsystem- Deactivation 12
Forced-Subsystem- Deactivation 13
ISUP-Message-Transfer 14
TCAP-Message-Transfer 15
Signaling-Point-Inaccessible 16
Signaling-Point-Accessible 17
Subsystem-Inaccessible 18
Subsystem-Accessible 19
Signaling-Point-Congestion 20
Local-Congestion 21
SS7-Network-Accessible 22
SS7-Network-Inaccessible 23
Heartbeat 24
reserved 255
MessageNature Identifies requests, responses or indications. The following values are available for the message nature:
Request 0
Response 1
Indication 2
reserved 255
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? click here   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:
8
9
10
11
12
13
14
15
16
Octet
Type
S
B
D
M
G
V
T
Rsv
2
Lifetime
4
Home address
8
Home agent
12
Care of address
16
Identification
20
Extensions …
Mobile IP registration request message structure
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:
8 16 32 Octets
Type
Code
Lifetime
4
Home address 8
8
Home agent 12
12
Identification 20
20
Extensions …
Mobile IP registration reply message structure
Type 3 indicates a registration reply.
Code A value indicating the result of the Registration Request. Values may be as follows: Registration successful:
0 1 Registration accepted. Registration accepted, but simultaneous mobility bindings unsupported.
Registration denied by the foreign agent:
64 65 66 67 68 69 70 71 72 73 Reason unspecified. Administratively prohibited. Insufficient resources. Mobile node failed authentication. Home agent failed authentication. Requested Lifetime too long. Poorly formed Request. Poorly formed Reply. Requested encapsulation unavailable. Requested Van Jacobson compression unavailable.
Service denied by the foreign agent:
74 75 76 Requested reverse tunnel unavailable. Reverse tunnel is mandatory and T bit not set. Mobile node too distant
Registration denied by the home agent:
80 81 82 88 Home network unreachable (ICMP error received). Home agent host unreachable (ICMP error received). Home agent port unreachable (ICMP error received). Home agent unreachable (other ICMP error received).
Service denied by the home agent:
137 138 139 Requested reverse tunnel unavailable. Reverse tunnel is mandatory and T bit not set. Requested encapsulation unavailable.
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? click here   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.
SYN ACK EAK RST NUL CHK TCS 0 Header Length
Sequence number Ack number
Checksum
RUDP header
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? click here   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:
2 bytes
2 bytes
SYNC
OpCode
Length
Sevice message data
TALI Payload structure
SYNC Four bytes must be (54 41 4C 49) TALI in ASCII.
OpCode The kind of TALI frame. The following types of frame exist
Type of frame Ascii OpCode
Test Service on this Socket test
Allow Service messages on this socket allo
Prohibit Service messages on this socket proh
Prohibit Service messages Ack proa
Monitor Socket message on this socket moni
Monitor Socket message Ack mona
SCCP Service message sccp
ISUP Service message isot
MTP3 Service message mtp3
MTP Primitives mtpp
SCCP Primitives scpp
Routing Key Registration rkrg
Routing Key De-Registration rkdr
Special Service Message spcl
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? click here   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? click here   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
Length
2 bytes
2 bytes
XOT header structure
Version The version number. Length The length of the packet. Interested in more details about testing this protocol? click here   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
Additional Information