Network Working Group J - student fiit

painveilNetworking and Communications

Oct 24, 2013 (3 years and 9 months ago)

93 views


Na základe vzťahov možno definovať pravdepodobnosť doručenia správy v

čase
. Ide zrejme
určenie m
aximálneho počtu retransmisií a
následne o

súčet
pravdepodobností pre prípady žiadnej, jednej, dvoch až x retransmisií. Matematicky
vyj
adrené:




Po dosadení a

úprave dostaneme:






































Network Working Group




J. Reynolds

Request for Comments: 1700




J. Postel

STD: 2






ISI

Obsoletes RFCs: 1340, 1060, 1010, 99
0, 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



ASSIGNED NUMBERS


Status of this Memo


This memo is a status report on the parameters (i.e., n
umbers and

keywords) used in
protocols in the Internet community. Distribution of this memo is unlimited.


OVERVIEW


THIS RFC IS A SNAPSH
OT OF THE
ONGOING PROCESS OF T
HE ASSIGNMENT
OF PROTOCOL PARAMETE
RS FOR THE
INTERNET PROTOCOL SU
ITE. TO MAKE
THE CU
RRENT INFORMATION RE
ADILY
AVAILABLE THE ASSIGN
MENTS ARE
KEPT UP
-
TO
-
DATE IN A SET OF ONL
INE
TEXT FILES. THIS RF
C HAS BEEN
ASSEMBLED BY CATINAT
ING THESE
FILES TOGETHER WITH
A MINIMUM OF
FORMATTING "GLUE". T
HE AUTHORS
APPOLOGIZE FOR THE S
OMEWHAT
ROUGHER FORM
ATTING AND STYLE
THAN IS TYPICAL OF M
OST RFCS.


We expect that various readers will notice specific items that should be corrected. Please
send any specific corrections via email to <iana@isi.edu>.














Reynolds & Postel



[Page 1]


RFC 1700



As
signed Numbers


October 1994



INTRODUCTION


The files in this directory document the currently assigned values for several series of
numbers used in network protocol implementations.


ftp://ftp.isi.edu/in
-
notes/iana/assignments


The Internet Assigned Numb
ers 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 coor
dinate the use of
numerous Internet protocol parameters.


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, auton
omous system numbers), 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 v
alues 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 PARAMET
ER
ASSIGNMENTS (PROTOCO
LS, PORTS, ETC.)
S
HOULD BE SENT TO <IA
NA@ISI.EDU>.

REQUESTS FOR SNMP NE
TWORK
MANAGEMENT ASSIGNME
NTS SHOULD
BE SENT TO <IANA
-
MIB@ISI.EDU>.


The IANA is located at and operated by the Information Science 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 Instit
ute


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 PROTOCOL
S ARE
DOCUMENTED IN THE RF
C SERIES OF
NOTES. SOME OF THE
I
TEMS LISTED ARE
UNDOCUMENTED. INFOR
MATION ON
PROTOCOLS CAN BE FOU
ND IN THE
MEMO, "INTERNET OFFI
CIAL PROTOCOL

STANDARDS" (STD 1).


Data Notations


The convention in the documentation of Internet Protocols is to express
numbers in decimal and to picture dat
a 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 right.


The order of transmission of the header and data described in this document is resolve
d 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 numb
ered.



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|

+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+


Similarly, whenever a m
ulti
-
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 C
LASSLESS
ADDRESSING [CIDR1, C
IDR2], THE
NETWORK
-
NUMBER PART OF AN
ADDRESS MAY BE OF AN
Y LENGTH, AND
THE WHOLE NOTION OF
ADDRESS
CLASSES BECOMES LESS

IMPORTANT.


There are certain special cases for IP addresses. These speci
al CASE can be
concisely summarized using the earlier notation for an IP address:



IP
-
address ::= { <Network
-
number>, <Host
-
number> }



or


IP
-
address ::= { <Network
-
number>, <Subnet
-
number>,

<Host
-
number> }


if we also use the notation "
-
1" to
mean the field contains all 1

bits. Some common special
cases are as follows:



(a)

{0, 0}



This host on this network. Can only be used as a source


address (see note later).



(b)

{0, <Host
-
number>}



Specified host on this network. Can only b
e used as a


source address.



(c)

{
-
1,
-
1}


Limited broadcast. Can only be used as a destination

address, and a datagram with
this address must never be forwarded outside the (sub
-
)net of the source.



(d)

{<Network
-
number>,
-
1}


Directed broadc
ast to specified network. Can only be used as a destination address.


Reynolds & Postel



[Page 4]


RFC 1700



Assigned Numbers


October 1994




(e)

{<Network
-
number>, <Subnet
-
number>,
-
1}



Directed
broadcast to specified subnet.
Can only be used as a d
estination
address.



(f)

{<Network
-
number>,
-
1,
-
1}



Directed broadcast to all subnets of specified subnetted

network.

Can only be used as a
destination address.



(g)

{127, <any>}



Internal host loopback address. Should never appear outside a host.



REFERENCES


[COHEN] Cohen, D., "On Holy Wars and a Plea for Peace", IEEE Computer Magazine,
October 1981.


[CIDR1] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter
-
Domain
Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC
1
519, September 1993.


[CIDR2] REKHTER, Y
., AND T. LI, "AN
ARCHITECTURE FOR IP
ADDRESS
ALLOCATION WITH CIDR
", RFC 1518,
SEPTEMBER 1993.


[]



URL = ftp://ftp.isi.edu/in
-
notes/iana/assignments/introduction












Reynolds & Postel



[Page 5]


RFC 1700



Assigned Numbers


October 1994



VERSION NUMBERS


In the Internet Protocol (IP) [RFC791] there is a field to identify

the version of the
internetwork general protocol. This field is 4

bits in size.


Assigned Internet Version Numbers


Decima

Keyword

Ver
sion



References

-------



-------


-------





----------

0


Reserved

[JBP]

1
-
3


Unassigned

[JBP]

4


IP


Internet Protocol


[RFC791,JBP]

5


ST


ST Datagram Mode


[RFC1190,JWF]

6


SIP


Simple Internet Protoco
l

[RH6]

7


TP/IX


TP/IX: The Next Internet

[R
XU]

8


PIP


The P Internet Protocol

[PXF]

9


TUBA


TUBA




[RXC]

10
-
14


Unassigned

[JBP]

15


Reserved

[JBP]


REFERENCES


[RFC791] Postel, J., ed., "Internet Protocol
-

DARPA Internet Program

Protocol
Specification", STD 5, RFC 791, USC/Information

Sciences

Institute, September 1981.


[RFC1190] Topolcic, C., Editor, "Experimental Internet Stream

Protocol, Version 2 (ST
-
II)",
RFC 1190, CIP Working Group,

October 1990.


PEOPLE


[JPB] Jon Postel <postel@isi.edu>


[JWF] Jim Forgie <FORGIE@XN.LL.MIT.ED>


[RH6] Ro
bert Hinden <Hinden@ENG.SUN.COM>


[RXU] Robert Ullmann <ariel@world.std.com>


[PXF] Paul Francis <francis@cactus.ntt.jp>


[RXC] Ross Callon <callon@wellfleet.com>


[]

Reynolds & Postel



[Page 6]


RFC 1700



Assigned Numbers


October 1994


URL = ftp://ftp
.isi.edu/in
-
notes/iana/assignments/version
-
numbers














































Reynolds & Postel



[Page 7]

RFC 1700



Assigned Numbers


October 1994


PROTOCOL NUMBERS


In the Internet Protocol (IP) [DDN], [RFC791] there is a field, calle
d

Protocol, to identify the
next level protocol. This is an 8 bit

field.


Assigned Internet Protocol Numbers


Decima

Keyword

Protocol




References

-------


-------


--------





----------

0


Reserved

[JBP]

1


ICMP


Internet Control Message


[RFC792,JBP]

2


IGMP



Internet Group Management


[RFC1112,JBP]

3


GGP


Gateway
-
to
-
Gateway



[RFC823,MB]

4


IP


IP in IP (encasulation)


[JBP]

5


ST


Stream





[RFC1190,IEN119,JWF]

6


TCP


Transmission
Kontrol



[RFC793,JBP]

7


UCL


UCL





[PK]

8


EGP


Exterior Gate
way Protocol


[RFC888,DLM1]

9


IGP


any private interior gateway


[JBP]

10


BBN
-
RCC
-
MON BBN RCC Monitoring


[SGC]

11


NVP
-
II

Network Voice Protocol


[RFC741,SC3]

12


PUP


PUP





[PUP,XEROX]

13


ARGUS

ARGUS




[RWS4]

14


EMCON

EMCON




[BN7]

15


XNET


Cro
ss Net Debugger



[IEN158,JFH2]

16


CHAOS

Chaos





[NC3]

17


UDP


User Datagram



[RFC768,JBP]

18


MUX


Multiplexing




[IEN90,JBP]

19


DCN
-
MEAS

DCN Measurement
Subsystéme

[DLM1]

20


HMP


Host Monitoring



[RFC869,RH6]

2
1


PRM


Packet Radio Measurement


[
ZSU]

22


XNS
-
IDP

XEROX NS IDP



[ETHERNET,XEROX]

23


TRUNK
-
1

Trunk
-
1




[BWB6]

24


TRUNK
-
2

Trunk
-
2




[BWB6]

25


LEAF
-
1

Leaf
-
1





[BWB6]

26


LEAF
-
2

Leaf
-
2





[BWB6]

27


RDP


Reliable Data Protocol


[RFC908,RH6]

28


IRT


Internet Reliable Transaction


[RF
C938,TXM]

2
9


ISO
-
TP4

ISO Transport Protocol Class 4

[RFC905,RC77]

30


NETBLT

Bulk Data Transfer Protocol


[RFC969,DDC1]

31


MFE
-
NSP

MFE Network Services Protocol

[MFENET,BCH2]

32


MERIT
-
INP

MERIT Internodal Protocol


[HWB]

33


SEP


Sequential Exchange Pro
tocol

[JC120]

34


3PC


Third Party Connect Protocol

[SAF3]

35


IDPR


Inter
-
Domain Policy Rou
ting Protocol
[MXS1]


Reynolds & Postel



[Page 8]

RFC 1700



Assigned Numbers


October 1994

36


XTP


XTP





[GXC]

37


DDP


Datagram Delivery Protocol


[WXC]

38


I
DPR
-
CMTP

IDPR Control Message Transport Proto [MXS1]

39


TP++


TP++ Transport Protocol


[DXF]

40


IL


IL Transport Protocol



[DXP2]

41


SIP


Simple Internet Protocol


[SXD]

42


SDRP


Source Demand Routing Protocol

[DXE1]

4
3


SIP
-
SR

SIP Source Route



[SXD
]

44


SIP
-
FRAG

SIP Fragment




[SXD]

45


IDRP


Inter
-
Domain Routing Protocol

[Sue Hares]

46


RSVP


Reservation Protocol



[Bob Braden]

47


GRE


General Routing Encapsulation

[Tony Li]

48


MHRP


Mobile Host Routing Protocol

[David Johnson]

49


BNA


BNA





[Gary Salamon]

50


SIPP
-
ESP

SIPP Encap Security Payload

[Steve Deering]

51


SIPP
-
AH

SIPP Authentication
Leader


[Steve Deering]

52


I
-
NLSP

Integrated Net Layer Security

TUBA [GLENN]

53


SWIPE

IP with Encryption



[JI6]

54


NHRP


NBMA Next Hop Resolution Pr
otocol

55
-
60


Unassigned






[JBP]

61


any host internal protocol




[JBP]

62


CFTP


CFTP





[CFTP,HCF2]

63


any local network





[JBP]

64


SAT
-
EXPAK

SATNET and Backroom EXPAK

[SHB]

65


KRYPTOLAN

Kryptolan



[PXL1]

66


RVD


MIT Remote Virtual Disk Proto
col

[MBG]

67


IPPC


Internet Pluribus Packet Core

[SHB]

68


any distributed file
systém




[JBP]

69


SAT
-
MON

SATNET Monitoring



[SHB]

70


VISA


VISA Protocol



[GXT1]

71


IPCV


Internet Packet Core Utility


[SHB]

7
2


CPNX


Computer Protocol Network Execut
ive[DXM2]

73


CPHB


Computer Protocol Heart Beat

[DXM2]

74


WSN


Wang Span Network



[VXD]

75


PVP


Packet Video Protocol


[SC3]

76


BR
-
SAT
-
MON Backroom SATNET Monitoring

[SHB]

77


SUN
-
ND

SUN ND PROTOCOL
-
Temporary

[WM3]

78


WB
-
MON

WIDEBAND Monitoring


[SH
B]

79


WB
-
EXPAK

WIDEBAND EXPAK


[SHB]

80


ISO
-
IP


ISO Internet Protocol



[MTR]

81


VMTP


VMTP





[DRC3]

82




SECURE
-
VMTP SECURE
-
VMTP

[DRC3]

83


VINES


VINES





[BXH]

84


TTP


TTP





[JXS]

85




NSFNET
-
IGP NSFNET
-
IGP

[HWB]

86


DGP


Dissimilar Gateway
Protocol


[DGP,ML109]

87


TCF


TCF





[GAL5]

88


IGRP


IGRP




[CISCO,GXS]

Reynolds & Postel



[Page 9]

RFC 1700



Assigned Numbers


October 1994


89


OSPFIGP


OSPFIGP




[RFC1583,JTM4]

90


Sprite
-
RPC


Sprite RPC Protocol



[SPRITE,BXW]

91


LARP



Locus

Address Resolution Protocol

[BXH]

92


MTP



Multicast Transport Protocol


[SXA]

93


AX.25



AX.25 Frames




[BK29]

9
4


IPIP



IP
-
within
-
IP Encapsulation Protocol

[JI6]

95


MICP



Mobile Internetworking Control Pro.[JI6]

96


SCC
-
SP


Semaphore Communication
s Sec. Pro.[HXH]

97


ETHERIP


Ethernet
-
within
-
IP Encapsulation

[RXH1]

98


ENCAP


Encapsulation
Leader



[RFC1241,RXB3]

99


any private encryption
schneme




[JBP]

100


GMTP



GMTP





[RXB5]

101
-
254

Unassigned







[JBP]

255


Reserved







[JBP]


REFEREN
CES


[CFTP] Forsdick, H., "CFTP", Network Message, Bolt Beranek and

Newman, January 1982.


[CISCO] Cisco Systems, "Gateway Server Reference Manual", Manual Revision B, January
10, 1988.


[DDN] Feinler, E., Editor, "DDN Protocol Handbook", Network Informati
on Center, SRI
International, December 1985.


[DGP] M/A
-
COM Government Systems, "Dissimilar Gateway Protocol Specification, Draft
Version", Contract no. CS901145, November 16, 1987.


[ETHERNET] "The Ethernet, A Local Area Network: Data Link Layer and

Phys
ical Layer Specification", AA
-
K759B
-
TK, Digital

Equipment Corporation, Maynard, MA. Also as: "The

Ethernet
-

A Local Area Network", Version 1.0, Digital

Equipment Corporation, Intel Corporation, Xerox

Corporation, September 1980. And: "The Ethernet, A Lo
cal

Area Network: Data Link Layer and Physical Layer

Specifications", Digital, Intel and Xerox, November 1982.

And: XEROX, "The Ethernet, A Local Area Network: Data Link

Layer and Physical Layer Specification", X3T51/80
-
50,

Xerox Corporation, Stamford, CT.
, October 1980.


[IEN90] Cohen, D. and J. Postel, "Multiplexing Protocol", IEN 90,

USC/Information Sciences Institute, May 1979.


[IEN119] Forgie, J., "ST
-

A Proposed Internet Stream Protocol",

IEN 119, MIT Lincoln Laboratory, September 1979.

Reynolds & Postel



[Page 10]