Internet-DRAFT Mykyta Yevstifeyev
Expires: 25 April, 2011 October 25, 2010
Intended status: Standards Track
Hardware Configuration Transfer Protocol
<draft-yevstifeyev-hctp-05>
Abstract
This document is a specification of Hardware Configuration
Transfer Protocol.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified
as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)
in effect on the date of publication of this document. Please
review these documents carefully, as they describe your rights and
restrictions with respect to this document.
Yevstifeyev Expires April 25, 2011 [Page 1]
Internet-Draft HCTP October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Interaction with Other Protocols . . . . . . . . . . . . . . 3
2.2. Functional Description . . . . . . . . . . . . . . . . . . . 3
2.3. Modes of Work . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Model of Work . . . . . . . . . . . . . . . . . . . . . . . 4
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The Parameters of the Protocols of Lower Levels . . . . . . 5
3.1.1. UDP Parameters . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. IPv4 Parameters . . . . . . . . . . . . . . . . . . . . 5
3.2. The Format of Packets . . . . . . . . . . . . . . . . . . . 5
3.2.1. The Header . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1.1. The Format of the Header . . . . . . . . . . . . . . 5
3.2.1.2. Fields Description . . . . . . . . . . . . . . . . . 5
3.2.2. Body Formation Rules . . . . . . . . . . . . . . . . . . 7
3.3. Error Messages Formation . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
6. Normative References . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Yevstifeyev Expires April 25, 2011 [Page 2]
Internet-Draft HCTP October 2010
1. Introduction
Many protocols of the Internet are used to transfer large amount of
information which can be displayed at the receiver's computer only if
required hardware is present or its configuration allow to do this.
Now if the receiver is not able to display the information, this
information is being sent. This causes the overload of the network.
Using HCTP will solve this problem by preceding transfer of
information about hadrware configuration of the client.
2. Review
2.1. Interaction with Other Protocols
The interaction of HCTP and other protocols are shown at the picture
below.
+---------+
| HCTP |
+---------+
|
+---------+
| UDP |
+---------+
|
+---------+
| IP |
+---------+
|
+-------------------------+
| Local Network Protocol |
+-------------------------+
Picture 1. The interaction of protocols.
2.2. Functional Description
HCTP is used to request and transfer information about hardware
configuration of the computer. Moreover, it can be used like a
ping-tool by sending special types of messages.
HCTP use packets to exchange information. Packets consist of header
and body.
The format of packets is described by this document.
Each side of the exchange mustn't open more than 256 connection
at the same time.
Yevstifeyev Expires April 25, 2011 [Page 3]
Internet-Draft HCTP October 2010
2.3. Modes of Work
HCTP has 3 modes of work:
a) casual. If HCTP works in this mode, it just transfers the
information about hardware configuration.
b) "If has". This mode allows to get known the fact of presence
of a device.
c) trace. This mode is similar to ICMP Echo messages and is used
to check the availability of using HCTP.
These modes will be described below more detalized.
2.4. Model of Work
HCTP is a client-server protocol. Each computer can be as server,
as client.
A computer which requests information is a client. A computer which
answers the client is a server.
After a server receives the HCTP request, it forms an answer and
sends it to a client. Then a client should send Thank You Message
(TUm) in order a server close a transaction.
While processing request some errors may occure. In this case a
server should send an Error Answer (EA). After receiving EA a client
may repeat the request.
The information about requested hardware or errors is transfered
in the body.
If the information is rerquested about the device which is not
present in the server's system, it should send EA with the
corresponding error code. In that case a client shouldn't repeat the
request.
HCTP trace messages can be used like ICMP Echo messages. Generally
they are used to check if HCTP can be used. The text of body in HCTP
trace request must be similar to the text in HCTP trace answer.
Yevstifeyev Expires April 25, 2011 [Page 4]
Internet-Draft HCTP October 2010
3. Specification
3.1. The Parameters of the Protocols of Lower Levels
3.1.1. UDP Parameters (as described in RFC 768 [1])
HCTP uses UDP with the following parameters:
a) Protocol - is being approved by IANA;
b) Client and Server ports - is being approved by IANA.
3.1.2. IPv4 Parameters (as described in RFC 791 [2])
HCTP uses IP with the following parameters:
a) Version - 4;
b) Flags - DF;
c) ToS - 00000000;
d) TTL - 128;
e) another fields - depending on the packet.
3.2. The Format of Packets
3.2.1. The Header
3.2.1.1. The Format of the Header
The HCTP header has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ToP|AT |vers.|I| Transaction number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subject |B| IH |Msg. num.|Tr.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.1.2. Fields Description
ToP (Type of Packet) - 2 bits. Can be set into:
00 - request;
01 - answer;
10 - TUm;
11 - Trace Message.
AT (Answer Type) - 2 bits. Can be set into:
00 - this packet is not answer;
01 - answer, no error;
10 - answer, error;
11 - reserved for future use.
Version - 3 bits. This specification described version 1.
Yevstifeyev Expires April 25, 2011 [Page 5]
Internet-Draft HCTP October 2010
I (Importance flag) - 1 bit. Shows if this packet should be processed
first.
Transaction number - 16 bits. Shows the number of transaction. Is unique
for a client.
Subject - 5 bits. Shows the device, information about which is
requested. Can be set into:
00000 - used for Trace MSGs and TUms;
00001 - processor information;
00010 - RAM information;
00011 - motherboard information;
00100 - HDD information;
00101 - NetWork Card information;
00110 - VGA information;
00111 - soundcard information;
01000 - CD drive information;
01001 - floppy drive information;
01010 - monitor information;
01011 - printer information;
01100 - scanner information;
01101 - web-camera information;
01110 - mouse information;
01111 - keyboard information;
10000 - OS information;
10001-11111 - reserved for future use.
When the server receives the request with certain "Subject" field, it
forms the answer with the same "Subject" field, but with the information
about the device defined in "Subject" field.
B (Body present flag) - 1 bit. Shows, if the body is present in the
packet.
IH ("If has" mode option) - 3 bits. Shows, if "If has" mode is enabled.
"If has" mode is used when only fact of presence of the requested device
is needed to be known.
Consists of 3 bits:
0 1 2
+---+---+---+
| | | |
| E | T | A |
| | | |
+---+---+---+
Bit 0 (enabled flag):0 - "If has" not enabled,
1 - "If has" enabled.
If this bit is set into 0, then bits 1 and 2
must be set into 0 either.
Yevstifeyev Expires April 25, 2011 [Page 6]
Internet-Draft HCTP October 2010
Bit 1 (type flag): 0 - "If has" request",
1 - "If has" answer.
Used only if bit 0 is set into 1. If this bit is
set into 0, bit 2
must be set into 0 either.
Bit 2 (answer): 0 - requested device is not present,
1 - requested device is present.
Used only if bit 0 and 1 are set into 1.
Msg. num. (Message in transaction number) - 5 bits. Shows the number
of the message in transaction. Each side while forming answer increases
this number in 1.
Tr. (Trace state option) - 2 bits. Shows if Trace mode is used.
Consists of 2 bits:
0 1
+---+---+
| | |
| E | T |
| | |
+---+---+
Bit 0 (enabled flag):0 - Trace not enabled,
1 - Trace enabled.
If this bit is set into 0, then bits 1 must be
set into 0 either.
Bit 1 (type flag): 0 - Trace request,
1 - Trace answer.
Used only if bit 0 is set into 1.
3.2.2. Body Formation Rules
This paragraph describes the rules of formation the body of the packet
for each device.
Device Body formation rules
+------------------+------------------------------------------------+
| Processor |[clock frequency in Mhz] [capacity - integer] |
+------------------+------------------------------------------------+
| RAM |[size in Mb] |
+------------------+------------------------------------------------+
| Motherboard |[manufactor] [model] |
+------------------+------------------------------------------------+
| HDD |[size in Mb] |
+------------------+------------------------------------------------+
| NetWork card |[maximum speed in Kbit/sec] |
| |[current speed in Kbit/sec] |
+------------------+------------------------------------------------+
| VGA |[size of video memory in Mb] |
| |[3D-accelerator: 1 - present 0 - not present] |
+------------------+------------------------------------------------+
Yevstifeyev Expires April 25, 2011 [Page 7]
Internet-Draft HCTP October 2010
+------------------+------------------------------------------------+
| Sound card |[manufactor] [model] |
+------------------+------------------------------------------------+
| CD drive |[discs posssible to be read] |
| | | |
| |[discs possible to be written] |
+------------------+------------------------------------------------+
| Floppy drive |[1 - present; 0 - not present] |
+------------------+------------------------------------------------+
| Monitor |[resolution (wide)] [resolution (heigh)] |
+------------------+------------------------------------------------+
| Printer |[1 - present; 0 - not present] |
+------------------+------------------------------------------------+
| Scanner |[1 - present; 0 - not present] |
+------------------+------------------------------------------------+
| Web-camera |[1 - present; 0 - not present] |
+------------------+------------------------------------------------+
| Mouse |[manufactor] [model] |
+------------------+------------------------------------------------+
| Keyboard |[manufactor] [model] |
+------------------+------------------------------------------------+
| OS |[name] [1st registry of version] |
| |[2nd registry of version] ... |
+------------------+------------------------------------------------+
3.3. Error Messages Formation
If an error occures while processing the request or a device
is not present, the server should send the Error Answer (EA).
It is done by setting AT in 10 and putting the error code into
the body of the packet.
There are following error codes for HCTP:
100 - HCTP not used;
101 - it is restricted send information about this device;
102 - the requested device not present in the system;
103 - incorrect request;
104 - another error;
105-199 - reserved for future use.
Yevstifeyev Expires April 25, 2011 [Page 8]
Internet-Draft HCTP October 2010
4. IANA Considerations
[TODO: IANA Considerations.]
5. Security Considerations.
HCTP, as mentioned before, supports only 256 connection at the same
time on one of the side of exchange. It won't make possible DDoS
attacks using HCTP.
We consider that formation of HCTP answers is laborious task. That
is why we make the restriction, mentioned in previous paragraph.
6. Normative References
[1] Postel, J., "Address Mappings," RFC 768, August 1980.
[2] Postel, J., "Internet Protocol," RFC 791, September 1981.
Author's Address
Mykyta Yevstifeyev
Email: evnikita2@gmail.com
Yevstifeyev Expires April 25, 2011 [Page 9]