Kde Po dosadení a úprave dostaneme

Дата канвертавання24.04.2016
Памер1.61 Mb.
  1   2   3   4   5   6   7   8   9   ...   19
Na základe vzťahov možno definovať pravdepodobnosť doručenia správy v čase . Ide

zrejme o určenie maximálneho počtu retransmisií a následne o súčet pravdepodobností pre

prípady žiadnej, jednej, dvoch až x retransmisií. Matematicky vyjadrené:

, kde

Po dosadení a úprave dostaneme:

Network Working Group J. Reynolds
Request for Comments: 1700 J. Postel


Obsoletes RFCs: 1340, 1060, 1010, 990, 960, October 1994

943, 923, 900, 870, 820, 790, 776, 770,

762, 758,755, 750, 739, 604, 503, 433, 349

Obsoletes IENs: 127, 117, 93

Category: Standards Track


Status of this Memo
This memo is a status report on the parameters (i.e., numbers and

keywords) used in protocols in the Internet community. Distribution

of this memo is unlimited.


This RFC is a snapshot of the ongoing process of the assignment of

protocol parameters for the Internet protocol suite. To make the

current information readily available the assignments are kept up-to-

date in a set of online text files. This RFC has been assembled by

catinating these files together with a minimum of formatting "glue".

The authors appologize for the somewhat rougher formatting and style

than is typical of most RFCs.

We expect that various readers will notice specific items that should be
corrected. Please send any specific corrections via email to


Reynolds & Postel [Page 1]

RFC 1700 Assigned Numbers October 1994


The files in this directory document the currently assigned values for

several series of numbers used in network protocol implementations.
The Internet Assigned Numbers Authority (IANA) is the central

coordinator for the assignment of unique parameter values for Internet

protocols. The IANA is chartered by the Internet Society (ISOC) and

the Federal Network Council (FNC) to act as the clearinghouse to

assign and coordinate the use of numerous Internet protocol


The Internet protocol suite, as defined by the Internet Engineering
Task Force (IETF) and its steering group (the IESG), contains numerous

parameters, such as internet addresses, domain names, autonomous

system numbers (used in some routing protocols), protocol numbers,

port numbers, management information base object identifiers,

including private enterprise numbers, and many others.

The common use of the Internet protocols by the Internet community
requires that the particular values used in these parameter fields be

assigned uniquely. It is the task of the IANA to make those unique

assignments as requested and to maintain a registry of the currently

assigned values.
Requests for parameter assignments (protocols, ports, etc.) should be
sent to .
Requests for SNMP network management private enterprise number

assignments should be sent to .

The IANA is located at and operated by the Information Sciences
Institute (ISI) of the University of Southern California (USC).
If you are developing a protocol or application that will require the

use of a link, socket, port, protocol, etc., please contact the IANA

to receive a number assignment.
Joyce K. Reynolds

Internet Assigned Numbers Authority

USC - Information Sciences Institute

4676 Admiralty Way

Marina del Rey, California 90292-6695
Electronic mail: IANA@ISI.EDU

Phone: +1 310-822-1511

Reynolds & Postel [Page 2]

RFC 1700 Assigned Numbers October 1994

Most of the protocols are documented in the RFC series of notes. Some
of the items listed are undocumented. Further information on

protocols can be found in the memo, "Internet Official Protocol

Standards" (STD 1).

Data Notations

The convention in the documentation of Internet Protocols is to

express numbers in decimal and to picture data in "big-endian" order

[COHEN]. That is, fields are described left to right, with the most

significant octet on the left and the least significant octet on the


The order of transmission of the header and data described in this
document is resolved to the octet level. Whenever a diagram shows a

group of octets, the order of transmission of those octets is the

normal order in which they are read in English. For example, in the

following diagram the octets are transmitted in the order they are


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


| 1 | 2 | 3 | 4 |


| 5 | 6 | 7 | 8 |


| 9 | 10 | 11 | 12 |


Transmission Order of Bytes

Whenever an octet represents a numeric quantity the left most bit in the

diagram is the high order or most significant bit. That is, the bit

labeled 0 is the most significant bit. For example, the following

diagram represents the value 170 (decimal).

0 1 2 3 4 5 6 7


|1 0 1 0 1 0 1 0|

Significance of Bits

Similarly, whenever a multi-octet field represents a numeric quantity

the left most bit of the whole field is the most significant bit. When

Reynolds & Postel [Page 3]

RFC 1700 Assigned Numbers October 1994

a multi-octet quantity is transmitted the most significant octet is

transmitted first.

Special Addresses

There are five classes of IP addresses: Class A through Class E. Of

these, Classes A, B, and C are used for unicast addresses, Class D is

used for multicast addresses, and Class E addresses are reserved for

future use.

With the advent of classless addressing [CIDR1, CIDR2], the
network-number part of an address may be of any length, and the whole

notion of address classes becomes less important.

There are certain special cases for IP addresses. These special cases
can be concisely summarized using the earlier notation for an IP

IP-address ::= { ,
  1   2   3   4   5   6   7   8   9   ...   19

База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка