Real-Time Streaming Protocol -RTSP

RLOGIN

Remote LOGIN (RLOGIN) allows UNIX users of one machine to connect to other UNIX systems across an Internet and interact as if their terminals are directly connected to the machines. This protocol offers essentially the same services as TELNET.

RTSP

The Real-Time Streaming Protocol (RTSP) is an application level protocols for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms bases upon RTP.

The streams controlled by RTSP may use RTP, but the operation of RTSP does not depend on the transport mechanism used to carry continuous media. The protocol is intentionally similar in syntax and operation to HTTP/1.1 so that extension mechanisms to HTTP can in most cases also be added to RTSP. However, RTSP differs in a number of important aspects from HTTP:

• RTSP introduces a number of new methods and has a different protocol identifier.
• An RTSP server needs to maintain state by default in almost all cases, as opposed to the stateless nature of HTTP.
• Both an RTSP server and client can issue requests.
• Data is carried out-of-band by a different protocol. (There is an exception to this.)
• RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1, consistent with current HTML internationalization efforts.
• The Request-URI always contains the absolute URI. Because of backward compatibility with a historical blunder, HTTP/1.1 carries only the absolute path in the request and puts the host name in a separate header field.

This makes virtual hosting easier, where a single host with one IP address hosts several document trees.

The Stream Control Transmission Protocol (SCTP) is designed to transport PSTN signalling messages over IP networks, but is capable of broader applications. SCTP is an application-level datagram transfer protocol operating on top of an unreliable datagram service such as UDP. It offers the following services:

• Acknowledged error-free non-duplicated transfer of user data.
• Application-level segmentation to conform to discovered MTU size.
• Sequenced delivery of user datagrams within multiple streams, with an option for order-of-arrival delivery of individual datagrams.
• Optional multiplexing of user datagrams into SCTP datagrams, subject to MTU size restrictions.
• Enhanced reliability through support of multi-homing at either or both ends of the association.

The design of SCTP includes appropriate congestion avoidance behaviour and resistance to flooding and masquerade attacks. The SCTP datagram is comprised of a common header and chunks. The chunks contain either control information or user data.

The following is the format of the SCTP header.

Source Port Number
This is the SCTP sender's port number. It can be used by the receiver, in combination with the source IP Address, to identify the association to which this datagram belongs.

Destination Port Number
This is the SCTP port number to which this datagram is destined. The receiving host will use this port number to de-multiplex the SCTP datagram to the correct receiving endpoint/application.

Verification Tag
The receiver of this 32 bit datagram uses the Verification tag to identify the association. On transmit, the value of this Verification tag must be set to the value of the Initiate tag received from the peer endpoint during the association initialization.

For datagrams carrying the INIT chunk, the transmitter sets the Verification tag to all 0's. If the receiver receives a datagram with an all-zeros Verification tag field, it checks the Chunk ID immediately following the common header. If the chunk type is not INIT or SHUTDOWN ACK, the receiver drops the datagram. For datagrams carrying the SHUTDOWN-ACK chunk, the transmitter sets the Verification tag to the Initiate tag received from the peer endpoint during the association initialization, if known. Otherwise the Verification tag is set to all 0's.

Adler 32 Checksum
This field contains an Adler-32 checksum on this SCTP datagram.

Chunk Field Descriptions

The following is the field format for the chunks transmitted in the SCTP datagram. Each chunk has a chunk ID field, a chunk specific Flag field, a Length field and a Value field.

Chunk ID
The type of information contained in the chunk value field. The values of the chunk ID are defined as follows:

Chunk Flags
The type of chunk flag as defined in the chunk ID defines whether these bits will be used. Their value is generally 0 unless otherwise specified.

Chunk Length
The size of the chunk in octets including the Chunk ID, Flags, Length and Value fields.

Chunk Value
This field contains the actual information to be transferred in the chunk. This is dependent on the chunk ID.

Chunk Types

Initiation (INIT)
This chunk is used to initiate a SCTP association between two endpoints. The INIT chunk contains the following parameters. Unless otherwise noted, each parameter is only be included once in the INIT chunk.

Initiate Acknowledgement (INIT ACK)
The INIT ACK chunk is used to acknowledge the initiation of a SCTP association. The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable parameters: The Responder Cookie and the Unrecognized Parameter.

Selective Acknowledgement (SACK)
This chunk is sent to the remote endpoint to acknowledge received Data chunks and to inform the remote endpoint of gaps in the received subsequences of Data chunks as represented by their TSNs.

The selective acknowledgement chunk contains the highest consecutive TSN ACK and Rcv Window Credit (rwnd) parameters. By definition, the value of the highest consecutive TSN ACK parameter is the last TSN received at the time the Selective ACK is sent, before a break in the sequence of received TSNs occurs; the next TSN value following this one has not yet been received at the reporting end. This parameter therefore acknowledges receipt of all TSNs up to and including the value given.

The Selective ACK also contains zero or more fragment reports. Each fragment report acknowledges a sub-sequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by fragment reports are higher than the value of the Highest Consecutive TSN ACK.

Heartbeat Request (HEARTBEAT)
An endpoint should send this chunk to its peer endpoint of the current association to probe the reachability of a particular destination transport address defined in the present association. The parameter fields contain the time values.

Heartbeat Acknowledgement (HEARTBEAT ACK)
An endpoint should send this chunk to its peer endpoint as a response to a Heartbeat Request. The parameter field contains the time values.

Abort Association (ABORT)
The Abort Association chunk is sent to the peer of an association to terminate the association. The Abort chunk may contain cause parameters to inform the receiver the reason for the abort. Data chunks are not bundled with the abort, control chunks may be bundled with an abort, but must be placed before the abort in the SCTP datagram or they will be ignored.

SHUTDOWN
An endpoint in an association uses this chunk to initiate a graceful termination of the association with its peer.

Shutdown Acknowledgement (SHUTDOWN ACK)
This chunk is used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process. The SHUTDOWN ACK chunk has no parameters.

Operation Error (ERROR)
This chunk is sent to the other endpoint in the association to notify certain error conditions. It contains one or more error causes.

State Cookie (COOKIE)
This chunk is used only during the initialization of an association. It is sent by the initiator of an association to its peer to complete the initialization process. This chunk precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same datagram.

Cookie Acknowledgement (COOKIE ACK)
This chunk is used only during the initialization of an association. It is used to acknowledge the receipt of a COOKIE chunk. This chunk precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same SCTP datagram.

Payload Data (DATA)
This contains the user data.

Vendor Specific Chunk Extensions
This chunk type is available to allow vendors to support their own extended data formats not defined by the IETF. It must not affect the operation of SCTP. Endpoints not equipped to interpret the vendor-specific chunk sent by a remote endpoint must ignore it. Endpoints that do not receive desired vendor specific information should make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.

RFC 2165

The Service Location Protocol (SLP) provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration for network services for network-based applications. This is especially important as computers become more portable and users less tolerant or able to fulfill the demands of network system administration.

Traditionally, users find services by using the name of a network host (a human readable text string), which is an alias for a network address. The Service Location Protocol eliminates the need for a user to know the name of a network host supporting a service. Rather, the user names the service and supplies a set of attributes, which describe the service. The Service Location Protocol allows the user to bind this description to the network address of the service.

Service Location provides a dynamic configuration mechanism for applications in local area networks. It is not a global resolution system for the entire Internet; rather it is intended to serve enterprise networks with shared services. Applications are modeled as clients that need to find servers attached to the enterprise network at a possibly distant location. For cases where there are many different clients and/or services available, the protocol is adapted to make use of nearby Directory Agents that offer a centralized repository for advertised services. The basic operation in Service Location is that a client attempts to discover the location for a service. In small installations, each service is configured to respond individually to each client. In larger installations, service will register their services with one or more directory agents and clients contact the directory agent to fulfill request for service location information. This is intended to be similar to URL specifications and make user of URL technology.

The header is used in all the SLP messages

Version
The current version is version 1

Length
Number of bytes in the message including the Service location header.

O
The overflow bit.

M
The monolingual bit.

U
URL Authentication bit present.

A
Attribute authentication bit present.

F
The F bit is set. If the F bit is set in a Service Acknowledgement, the directory agent has registered the service as a new entry.

Rsvd
These bits are reserved and must have a value of 0.

Dialect
To be use by future versions of the SLP. Must be set to zero.

Language Code
The language encoded in this field indicates the language in which the remainder of the message should be interpreted.

Character Encoding
The characters making up strings within the remainder of this message may be encoded in any standardized encoding

Transaction Identifier (XID)
Allows matching replies to individual requests.

SMPP Developer’s Forum, SMPP Protocol Specification v3.4, 10/12/1999

The Short Message Peer to Peer (SMPP) protocol is designed to provide a flexible data communications interface for transfer of short message data between a Message Center such as a Short Message Service Center (SMSC), GSM Unstructured Supplementary Services Data (USSD) Server or other type of Message Center, and an SMS application system such as a WAP Proxy Server, Email Gateway or other Messaging Gateway.
The SMPP PDU format is as follows:

Command length
Defines the total octet length of the SMPP PDU packet, including the length field. The Command Length field is 4 octets long.

Command ID
Identifies the particular SMPP PDU, e.g., submit_sm, query_sm, etc. The Command ID field is 4 octets long. The following is a list of possible Command ID values:

Command status
Indicates the success or failure of an SMPP request. It is relevant only in the SMPP response PDU and it must contain a NULL value in an SMPP request PDU. The Command Status field is 4 octets long.

Sequence number
Contains a sequence number which allows SMPP requests and responses to be associated for correlation purposes. The use of sequence numbers for message correlation allows SMPP PDUs to be exchanged asynchronously. The Sequence Number field is 4 octets long.

Mandatory Parameters
Following the header is a set of mandatory parameters, corresponding to the SMPP PDU defined in the Command ID field.

Optional Parameters
Optional parameters corresponding to the SMPP PDU defined in the Command ID field, and included as required. Each optional parameter has the following structure:

Tag
A field (2 octets long) that uniquely identifies the particular optional parameter in question. The following is a list of possible Tag values:

Length
Indicates the length (in octets) of the Value field. The Length field is 2 octets long.

Value
The actual data of the optional parameter.

RFC821

IETF RFC821 defines the Simple Mail Transfer Protocol (SMTP) which is a mail service modeled on the FTP file transfer service. SMTP transfers mail messages between systems and provides notification regarding incoming mail.

Commands

SMTP commands are ASCII messages sent between SMTP hosts. Possible commands are as follows:

Messages

SMTP response messages consist of a response code followed by explanatory text, as follows:

SNMP

RFC1157
SNMP Protocol Overview: 

IETF RFCs 1155, 1156, and 1157 define the Simple Network Management Protocol (SNMP). The Internet community developed SNMP to allow diverse network objects to participate in a global network management architecture. Network managing systems can poll network entities implementing SNMP for information relevant to a particular network management implementation. Network management systems learn of problems by receiving traps or change notices from network devices implementing SNMP.

SNMP Message Format

SNMP is a session protocol which is encapsulated in UDP. The SNMP message format is shown below:

Version
SNMP version number. Both the manager and agent must use the same version of SNMP. Messages containing different version numbers are discarded without further processing.

Community
Community name used for authenticating the manager before allowing access to the agent.

PDU
There are five different PDU types: GetRequest, GetNextRequest, GetResponse, SetRequest, and Trap. A general description of each of these is given in the next section.

PDU Format

The format for GetRequest, GetNext Request, GetResponse and SetRequest PDUs is shown here.

PDU type
Specifies the type of PDU:

Request ID
Integer field which correlates the manager’s request to the agent’s response.

Error status
Enumerated integer type that indicates normal operation or one of five error conditions. The possible values are:

Error index
Identifies the entry within the variable bindings list that caused the error.

Object/value
Variable binding pair of a variable name with its value.

Trap PDU Format

The format of the Trap PDU is shown below:

PDU type
Specifies the type of PDU (4=Trap).

Enterprise
Identifies the management enterprise under whose registration authority the trap was defined.

Agent address
IP address of the agent, used for further identification.

Generic trap type
Field describing the event being reported. The following seven values are defined:

Specific trap type
Used to identify a non-generic trap when the Generic Trap Type is enterpriseSpecific.

Timestamp
Value of the sysUpTime object, representing the amount of time elapsed between the last (re-)initialization and the generation of that Trap.

Object/value
Variable binding pair of a variable name with its value.

This protocol provides a framework for client-server applications in both the TCP and UDP domains to conveniently and securely use the services of a network firewall. The protocol is conceptually a "shim-layer" between the application layer and the transport layer, and as such does not provide network layer gateway services, such as forwarding of ICMP messages. SOCKS Version 4 provides unsecured firewall traversal for TCP-based client-server applications, including TELNET, FTP, and protocols such as HTTP, WAIS and GOPHER. This version of SOCKS extends the SOCKS Version 4 model to include UDP, and extends the framework to include provisions for generalized strong authentication schemes. It also adapts the addressing scheme to encompass domain-name and V6 IP addresses.

The implementation of the SOCKS protocol typically involves the recompilation or relinking of TCP-based client applications to use the appropriate encapsulation routines in the SOCKS library.

Protocol Structure for TCP-based Clients

Version identifier/method selection message:

Version
The version is 05.

Nmethod
The NMETHODS field contains the number of method identifier octets that appear in the METHODS field.

The method selection message:

Methods
Possible values for methods are:

Socks Request Message

Version
The Protocol version is 5.

CMD
Possible values for the cmnd field are:

Reserved
The value of this field is 0.

ATYP
Address type of the following address:

Destination Address
The destination address desired.

Destination Port
The desired destination port in network octet order.

Socks Reply Message

Version
The protocol version is 5.

REP
The reply field.
Possible values for the reply field are:

RSV
Reserved, the value of this field is 0.

ATYP
Address type of the following address:

BND Address
Server bound address.

BND Port
Server bound port in network octet order.

Protocol Structure for UDP-based Clients

Each UDP datagram carries a UDP request header with it:

UDP Request Header

RSV
This field is reserved. Its value is 0000.

FRAG
This field contains the current fragment number, and indicates whether the datagram is one of a number of fragments.

ATYP
Address type of the following address:

DST addr
Desired destination address.

DST Port
Desired destination port.

Data
User data.

RFC1492 

TACACS+ is a protocol providing access control for routers, network access servers and other networked computing devices via one or more centralized servers. TACACS+ provides separate authentication, authorization and accounting services.
(Compliant with IETF draft-grant-tacacs-00.txt 10-1996.)

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

Major version
The major TACACS+ version number.

Minor version
The minor TACACS+ version number. This is intended to allow revisions to the TACACS+ protocol while maintaining backwards compatibility.

Packet type
Possible values are:
TAC_PLUS_AUTHEN:= 0x01 (Authentication).
TAC_PLUS_AUTHOR:= 0x02 (Authorization).
TAC_PLUS_ACCT:= 0x03 (Accounting).

Sequence number
The sequence number of the current packet for the current session. The first TACACS+ packet in a session must have the sequence number 1 and each subsequent packet will increment the sequence number by one. Thus clients only send packets containing odd sequence numbers, and TACACS+ daemons only send packets containing even sequence numbers.

Flags
This field contains various flags in the form of bitmaps. The flag values signify whether the packet is encrypted.

Session ID
The ID for this TACACS+ session.

Length
The total length of the TACACS+ packet body (not including the header).

TELNET is the terminal emulation protocol of TCP/IP. Modern TELNET is a versatile terminal emulation due to the many options that have evolved over the past twenty years. Options give TELNET the ability to transfer binary data, support byte macros, emulate graphics terminals, and convey information to support centralized terminal management.

TELNET uses the TCP transport protocol to achieve a virtual connection between server and client. After connecting, TELNET server and client enter a phase of option negotiation that determines the options that each side can support for the connection. Each connected system can negotiate new options or renegotiate old options at any time. In general, each end of the TELNET connection attempts to implement all options that maximize performance for the systems involved.

In a typical implementation, the TELNET client sends single keystrokes, while the TELNET server can send one or more lines of characters in response. Where the Echo option is in use, the TELNET server echoes all keystrokes back to the TELNET client.

Dynamic Mode Negotiation

During the connection, enhanced characteristics other than those offered by the NVT may be negotiated either by the user or the application. This task is accomplished by embedded commands in the data stream. TELNET command codes are one or more octets in length and are preceded by an interpret as command (IAC) character, which is an octet with each bit set equal to one (FF hex). The following are the TELNET command codes:

Each negotiable option has an ID, which immediately follows the command for option negotiation, that is, IAC, command, option code. Following is a list of TELNET option codes:

The Web Cache Coordination Protocol (WCCP) has 2 main functions. The first is to allow a router enabled for transparent redirection to discover, verify, and advertise connectivity to one or more web-caches.

Transparent redirection is a technique used to deploy web-caching without the need for reconfiguration of web-clients. It involves the interception and redirection of HTTP traffic to one or more web-caches by a router or switch, transparently to the web-client.

The second function of WCCP is to allow one of the web-caches, the designated web-cache, to dictate how the router distributes redirected traffic across the web-cache farm. It is recommended that the web-cache with the lowest IP address be elected as designated web-cache for a farm.

Each WCCP protocol packet is carried in a UDP packet with a destination port of 2048.

 Packets can be of the following types; HERE_I_AM, I_SEE_YOU, ASSIGN_BUCKETS.

HERE I AM

The format of the Here I am message isL

Type
WCCP_HERE_I_AM

Protocol Version
This field has a value of 4.

Hash Revision
The value of this field is 0.

Hash Information
A 256-element bit-vector. A set bit indicates that the corresponding bucket in the Redirection Hash Table is assigned to this web-cache.

U
The value of the U flag present in the last WCCP_I_SEE_YOU message received by this cache. Set in first WCCP_HERE_I_AM to indicate that Hash Information is historical.

Received ID
The value of the Received ID present in the last WCCP_I_SEE_YOU received by this web-cache.

I SEE YOU Message

The format of the I SEE YOU message is:

Type
WCCP_I_SEE_YOU

Protocol Version
4

Change Number
Incremented if a Web-Cache List Entry has been added, removed or its hash information has been modified since the last WCCP_I_SEE_YOU sent by the router.

Received ID
Incremented each time the router generates a WCCP_I_SEE_YOU.

Number of WCs
Number of Web-Cache List Entry elements in the packet.

Web Cached List entry
The Web-Cache List Entry describes a Web-Cache by IP Address and lists the redirection hash table entries assigned to it.

WCCP ASSIGN BUCKET

The format of the WCCP ASSIGN BUCKET message is: 

Type
WCCP_ASSIGN_BUCKET

Received ID
Value of Received ID in last WCCP_I_SEE_YOU received from router.

Number of Web Caches
Number of Web Caches to which redirect traffic can be sent.

Web Cache IP address 0-n
IP Addresses of Web-Caches to which redirect traffic can be sent. The position of a Web-Cache's IP Address in this list is the Web-Cache's index number. The first entry in the list has an index number of zero.

Buckets 0-255
These 256 buckets represent the redirection hash table. The value of each bucket may be 0xFF (Unassigned) or a Web-Cache index number (0-31).

X-Window

RFC1013  

The X-Window protocol provides a remote windowing interface to distributed network applications. It is an application layer protocol which uses TCP/IP or DECnet protocols for transport.

The X-Window networking protocol is client-server based, where the server is the control program running on the user workstation and the client is an application running elsewhere on the network. An X-server control program running on a workstation can simultaneously handle display windows for multiple applications, with each application asynchronously updating its window with information carried by the X-Window networking protocol.

To provide user interaction with remote applications, the X-server program running on the workstation generates events in response to user input such as mouse movement or a keystroke. When multiple applications display, the system sends mouse movements or click events to the application currently highlighted by the mouse pointer. The current input focus selects which application receives keystroke events. In certain cases, applications can also generate events directed at the X-server control program.

Request and Reply Frames

Request and reply frames can use the following commands:

Event Frames

Event frames can have the following commands: