rfc1277.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 686 行 · 第 1/2 页

organisation, the telex number of that organisation would be a good
choice.  Some well known networks are given assignments in Appendix A.


4.3  The DSP Encoding

The network address is used as follows.


 o  A (sub)network is identified by the IDP and a small part of the
    DSP.

 o  The remainder of the DSP encodes network specific information

The DSP format is now defined.  The top level format is independent of
the means used to provde COTS. Two formats for the remainder of the
DSP are then defined, for specific means of providing COTS.

A decimal abstract encoding is defined for the DSP. The ECMA 117
format might have been used, but it is not suitable.  [TC386].  Use of
a binary encoding, with the DSP structured in ASN.1 would have been a

Hardcastle-Kille                                                Page 6




RFC 1277           Encoding Network Addresses            November 1991


very attractive approach.  However, there is insufficient space in the
Network Address for this to be feasible.
The following structure is defined:

                 ____________________________________
                 |_Digit___||1-2__|______3-27_______|_
                 |_Meaning_||PrefixN|etwork_Specific_|

2 digits Prefix.  This allows for multiple usage of the same DSP, by
    not consuming it all.  It also allows for the DSP to be used with
    different encodings.

Network Specific The network specific allocation should be less than
    20 digits if this DSP structure is to be used with any IDI format.
    This is increased to 27 for the Telex format.


The IDP + 2 digit prefix identify a subnetwork in which the value of
the remainder of the DSP (Network Specific Part) is to be interpreted.

4.4  X.25(80) Network Specific Format

The IDP/Prefix identifies an X.25(80) subnetwork.  There is a need to
represent a DTE Number, and optionally an X.25 Protocol ID or CUDF
(many implementations require these due to shortage of X.121 address
space) in the DSP. This is structured in one of two possible ways:

                       ________________________
                       |_Digit___||1R|emainder_|
                       |_Meaning_||0_|_DTE____|_

     ____________________________________________________________
     |_Digit___||_1___|_______2________|3_--_(n*3)+2_|Remainder_|_
     |_Meaning_||Type__|PID/CUDF_Length_|_PID/CUDF___|___DTE____|_
     |_Values__||1_or_2_|_____n________|_____________|__________|_

The network specific part is structured as follows:


Type This has the following values

    0 DTE only

    1 DTE + PID

Hardcastle-Kille                                                Page 7




RFC 1277           Encoding Network Addresses            November 1991


    2 DTE + CUDF

    3-9 Reserved

PID/CUDF Length The length of the PID/CUDF in octets

PID/CUDF The PID/CUDF takes as many digits as indicated by 3 times
    octet 2.  Each octet of the PID/CUDF is encoded as three decimal
    digits, representing the decimal value of the octet.

DTE The DTE is terminated by the end of the Network Address.



For example, the JANET DTE 000005111600 with ASCII CUDF ``12'' would
be encoded in the following way.  The first lines describe the
abstract notation.  Note that where the IDI is not of maximum length,
that the translation to concrete decimal is not mechanical


_______________________________________________________________________________
|Part___|_|_____IDP_________|_______________________DSP_______________________|_
|Comp___|_|AFI__|___IDI_____|Prefix_|Dte+Cudf_|Len|________CUDF_+_DTE_________|_
|Octet__|_|____|____________|_1-2___|___3_____|_4_|___________5-20____________|_
|Value__|T|elex_|007_28722__|__02___|___2_____|_2_|____049050_000005111600____|__
|Ct_Dec_|_|54___|007_28722__|__02___|___2_____|_2_|____049050_000005111600____|_
|Ct_Bin_|_|54___|00_72_87_22_|_02___|_____22______|04_90_50_00_00_51_11_60_0f_|_

Note that concrete binary is representing octets in hexadecimal.  This
is the syntax most likely to be used in practice.  The CUDF is
represented by two octets 049 and 050 (decimal), which map to six
digits.


4.5  TCP/IP (RFC 1006) Network Specific Format

The IDP and 2 digit prefix identifies a TCP/IP network where RFC 1006
is applied.  It is necessary to use an IP Address, as there are
insufficient bits to fit in a domain.  It is structured as follows:

      __________________________________________________________
      |_Digit___||_1-12____|13-17_(optional)_|18-22_(optional)_|_
      |_Meaning_||IP_Address_|____port_______|__Transport_Set__|_


Hardcastle-Kille                                                Page 8




RFC 1277           Encoding Network Addresses            November 1991


For TCP/IP there shall be a 20 digit long network-specific part.
First 12 digits are for the IP address.  The port number can be up to
65535, and needs 5 digits (this is optional, and is defaulted as
defined in RFC 1006).  Finally, there is a third part to the address,
which is defined here as ``transport set'' that indicates what kind of
IP-based transport protocols is used.  This is a decimal number from
0-65535 which is really a 16-bit flag word.  1 is TCP, 2 is UDP.
Further values of this code are assigned by the IANA. If the transport
set is not there or no bits are set, it means ``default'' which is
TCP. This is encoded in 5 digits.
For example, the IP Address 10.0.0.6 with port 9 over UDP is encoded
as:


____________________________________________________________________________
|Part______|_|_____IDP_________|____________________DSP____________________|_
|Component_|_|AFI__|___IDI_____|Prefix_|___IP_Address_____|_Port__|_T_Set__|_
|Octet_____|_|____|____________|_1-2___|______3-14________|_15-19_|_20-24__|_
|Value_____|T|elex_|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|__
|Cncrt_Dec_|_|54___|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|_
|Cncrt_Bin_|_|54___|00_72_87_22_|_03___|01_00_00_00_00_06_|00_00_9|0_00_02_|_

5  Encoding


This document describes allocation of Network Addresses, with the DSP
considered in Abstract Decimal.  The encoding of this for use in
protocols (typically as Concrete Binary) is described in ISO 8348
Addendum 2 [ISO87a].


6  References

References

[CCI80]  CCITT. Recommendation X.25, interface between DTE and DCE
         for packet mode terminals, 1980.

[CCI88]  The Directory --- overview of concepts, models and services,
         December 1988. CCITT X.500 Series Recommendations.

[CGC91]  R. Colella, E. Gardner, and R. Callon.  Guidelines for OSI
         NSAP Allocation in the Internet. Request for Comments 1237,


Hardcastle-Kille                                                Page 9




RFC 1277           Encoding Network Addresses            November 1991


         NIST, July 1991.

[ISO87a] Information processing systems - data communications -
         network services definition:  Addendum 2 - network layer
         addressing, March 1987. ISO TC 97/SC 6.

[ISO87b] ISO DIS 7498-3 on naming and addressing, May 1987.
         ISO/IEC/JTC-1/SC 21.

[Kil88]  S.E. Kille. The QUIPU directory service.  In IFIP WG 6.5
         Conference on Message Handling Systems and Distributed
         Applications, pages 173--186. North Holland Publishing,
         October 1988.

[Kil89]  S.E. Kille. An interim approach to use of network addresses.
         Research Note RN/89/13, Department of Computer Science,
         University College London, February 1989.

[RC87]   Marshall T. Rose and Dwight E. Cass. ISO Transport Services
         on top of the TCP. Request for Comments 1006, Northrop
         Corporation Technology Center, May 1987.

[Ros90]  M.T. Rose. The ISO development environment:  User's manual
         (version 6.0), January 1990.

[SA88]   F. Sirovich and M. Antonellini. The THORN X.500 distributed
         directory environment. In Esprit Conference Week, November
         1988.

[TC386]  ECMA TC32. Domain specific part of network layer addresses.
         ECMA Standard 117, ECMA, June 1986.


7  Security Considerations

Security considerations are not discussed in this memo.


8  Author's Address

    Steve Hardcastle-Kille
    Department of Computer Science
    University College London


Hardcastle-Kille                                               Page 10




RFC 1277           Encoding Network Addresses            November 1991


    Gower Street
    WC1E 6BT
    England

    Phone:  [phone]


    EMail:  [e-mail]





































Hardcastle-Kille                                               Page 11




RFC 1277           Encoding Network Addresses            November 1991


A  Allocations for well known networks

A.1  Values


This appendix gives an allocation for three well known networks.  All
are allocated on the basis of the supposed Telex number 00728722.
This number is being used in pilot operations, and so is retained
here.
               _______________________________________
               |_________Net__________Telex____Prefix_|
               | International X.25 |007 28722 01     |
               | Janet              |007 28722 02     |
               | Darpa/NSF Internet |007 28722 03     |
               |_IXI________________|007_28722_06_____|

The international X.25 allocation is only used where a CUDF or PID is
needed.  In other cases, an X.121 form Network Address with no DSP
should be used.


A.2  Delegation

The values assigned in this document are now in widespread use.  As
the number is arbitrary, it would be undesirable to change the numbers
without a sound technical reason.  However, it is important to
guarantee that the numbers are stable.

This Internet Draft commits UCL not to reassign the portions of the
number space allocated here.
The DARPA/NSF Internet space (Prefix 03) is delegated to the IANA.














Hardcastle-Kille                                               Page 12