Movatterモバイル変換

[RFC Home] [TEXT|PDF|PDF|PS] [Tracker] [IPR] [Info page]

PROPOSED STANDARD

Network Working Group S.E. Hardcastle-KilleRequests for Comments 1277 University College London November 1991Encoding Network Addressesto support operation over non-OSI lower layersStatus of this Memo This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the ``IAB Official Protocol Standards'' for the standardization state and status of this protocol. Distribution of this memo is unlimited.Abstract The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards [CCI88] [ISO87a]. The OSI Directory, and any OSI application utilising the OSI Directory must be able use these Network Addresses to identify end systems. Currently, OSI applications are often run over lower layers other than the OSI Network Service. It is neither reasonable nor desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to be dependent on a global OSI Network Service. This document defines a new network address format, and rules for using some existing network address formats. The scope of this document is:1. Any TCP/IP network supporting COTS usingRFC 1006.2. Any mapping of COTS onto X.25 (usually X.25(80)), where X.25 is not used to provide CONS (i.e., only DTE and not Network address is carried). The approach could also be extended to use with other means of providing COTS (or CLTS). It is not appropriate for use where CONS or CLNS is used to provide COTS (or CLTS).

RFC 1277           Encoding Network Addresses            November 19911  IntroductionThe OSI Directory specifies an encoding of Presentation Address, whichutilises OSI Network Addresses as defined in the OSI Network Layerstandards [CCI88] [ISO87a].  The OSI Directory, and any OSIapplication utilising the OSI Directory must be able use these NetworkAddresses to identify end systems.Currently, OSI applications are often run over lower layers other thanthe OSI Network Service.  It is neither reasonable nor desirable forgroups wishing to investigate and use OSI Applications in conjunctionwith the OSI Directory to be dependent on a global OSI NetworkService.  This RFCdefines mechanisms to encode addressing informationwithin Network Addresses, in order to support this type of working.In particular, support is defined forRFC 1006 mapping of COTS ontoTCP/IP and COTS mapped onto X.25(1980) [RC87,CCI80].Where an OSI application is run over CLNS on the internet, the NSAPGuidelines ofRFC 1237 should be followed [CGC91].This document must be read in the context of ISO 8348 Addendum 2[ISO87b].  It will not be meaningful on its own.1.1  Historical NoteThis document was originally published as UCL Research Note RN/89/13and as a project THORN internal document [Kil89].  It was devised inresponse to two projects which faced this requirement, and was agreedas a common approach.  The projects were: o  The THORN project, which is an Esprit Project building an OSI    Directory [SA88]. o  The ISODE project [Ros90], and in particular the QUIPU directory    being developed at UCL [Kil88].The proposal has been implemented, and the viability of the solutiondemonstrated.Hardcastle-Kille                                                Page 1

RFC 1277 Encoding Network Addresses November 19912 Problem StatementWhen utilising the OSI Directory, the OSI location of an End Systemwill be determined by a Network Address, which is taken from aPresentation Address, looked up in the OSI Directory.OSI applications are currently operated over the following lowerlayers. o An international X.25 network, which routes on the basis of X.121 addresses. By and large this is X.25(80), but some parts are now X.25(84) and will carry Network Addresses as user data. OSI Transport is mapped onto the variant of X.25 which is available. o Large private X.25 networks, which do not have DNICs, but are otherwise similar to the previous (in particular Janet). o Isolated networks running Connection Oriented Network Service (e.g., Pink Book Ethernets). o Isolated networks running Connectionless Network Service (e.g., MAP LANs). o The Connectionless Network Service Protocol (CLNP) pilot, currently taking place in the NSFNet and NORDUNet communities. o Isolated TCP/IP LANs, utilisingRFC 1006 to support the OSI Transport Service[RC87]. o The DARPA/NSF Internet, usingRFC 1006.In general, these systems need to be interconnected by the use oftransport bridging or application relaying. Operation of transportbridges causes a number of problems which it is desirable to avoid.Only some applications can support relaying, and this is not alwayssatisfactory.2.1 The ``Right Solution''It is worth noting briefly what the intended (OSI) solution is. Thereis a single global network service. Network Addresses are globallyallocated, and do not imply anything about routing or location. AnHardcastle-Kille Page 2

RFC 1277 Encoding Network Addresses November 1991End System is attached to one or more subnetworks at Subnetwork Pointsof Attachment (SNPAs). Intermediate Systems join subnetworks, againbeing attached at SNPAs. Routing is achieved by repeated binding ofNetwork Address to SNPA (initially at the Originating End System, andthen at each Intermediate System). This binding is achieved bynetwork level routing mechanisms.This can only work in a pure OSI environment with a single ubiquitousnetwork service (either connectionless or connection-oriented), and sois not sufficient for the problem being addressed by this note.2.2 General ApproachThis section describes the use of network addresses, and gives afunctional overview of the problem being takceled. The means ofconnecting to a remote Application Entity is broadly as follows.1. Look up the Application Entity in the OSI Directory to obtain the Presentation Address 1.2. Extract each Network Address from the Presentation Address, and determine if it can be used (and how).3. Determine an order of preference for the Network Addresses.4. Attempt to connect to one or more of the Network Addresses.This note is concerned with the second step, and will probably haveimplications on the third. There is currently no directory service toprovide step 2, and so this (interim) approach must be algorithmic.All addressing information required for the network must be extractedfrom the network address.This note describes the use of Network Addresses for networks which donot provide the OSI Network Service (CLNS or CONS), and placesconstraints on the use of X.121 form network addresses when used foran OSI Network Service. The following types of Network Address arediscussed in this note:---------------------------- 1. Strictly an Application Entity should have only onePresentation Address. In practice it may have several, and thenetwork addresses of each Presentation Address should be considered.Hardcastle-Kille Page 3

RFC 1277           Encoding Network Addresses            November 1991 o  Use of X.121 form Network Addresses. o  A special encoding of Telex form Network Addresses.3  Network addresses with X.121 AFIThis note defines an approach for use of network addresses with theX.121 AFI.The IDP of network addresses is used to allow worldwide administrationof the NSAP address space.  As such, not all values of the IDP will inpractice have topological significance (which implies that in somecases the IDP will not be sufficient for network layer routing).However, it is recommended that any End System using the ConnectionOriented Network Service and with access to the international X.25service uses the X.121 form of NSAP address relative to its accesspoint.  This allows routing across the worldwide X.25 based publicdata networks to be based on the X.121 addresses.  Allocation of DSP(Domain Specific Part) within this form of address is a private issue.The IDP is primarily an allocation mechanism, and the user (endsystem) cannot in principle assume any implied routing.  However, dueto the lack of a network directory service, it is recommended that anyEnd System with Connection Oriented Network Service and access to theinternational X.25 service uses X.121 form relative to its accesspoint.  Allocation of DSP (Domain Specific Part) is a private issue.Conversely it is recommended that if an X.121 IDP (Initial DomainPart) form Network Address is interpreted, then the X.121 address willprovide a route (by defining an SNPA on the international X.25network).  There may be additional and perhaps preferable routes whichcan be determined by private means.If the DSP is absent, the form should be interpreted as implying amapping of Transport onto X.25(80).4  New Network Address FormatThis section defines a new network address format.  The scope of thisformat is currently:1.  Any TCP/IP network supporting COTS usingRFC 1006.Hardcastle-Kille                                                Page 4

RFC 1277 Encoding Network Addresses November 19912. Any mapping of COTS onto X.25 (usually X.25(80)), where X.25 is not used to provide CONS (i.e., only DTE and not Network address is carried), except where the international X.25 service is used and no PID or CUDF is required. These exceptions are the cases which are handled by use of X.121 AFI (Section 3). The intention is to use the X.121 AFI wherever possible, and the formats defined in this section are for the remaining cases.The approach could also be extended to use with other means ofproviding COTS (or CLTS). It is not appropriate for use where CONS orCLNS is used to provide COTS (or CLTS).4.1 RequirementsThe requirements for use of OSI over existing networks not supportingCONS or CLNS, when using the OSI Directory are:1. The information for the layers below Transport must be obtained from the Network Address. This is essential, because we wish to use the OSI Directory in a standard manner, and the Network Address is the information available.2. The Network Addresses must be globally unique, as they can be looked up by anyone with access to the Directory.3. The Network Address should be allocated so that confusion with a ``real'' Network Address (i.e., one which defines an NSAP using CONS or CLNS as opposed to X.25(80) orRFC 1006) is unlikely.4. Network Addresses must be interpretable on the basis of a well known information, or on information which can be obtained from the (application level) OSI Directory. (This RFConly uses well known information).5. The identity of the network in question must be deducible from the Network Address6. All network specific addressing information (including the SNPA) must be deducible from the Network AddressHardcastle-Kille Page 5

RFC 1277           Encoding Network Addresses            November 19914.2  IDP ChoiceThe IDP is used with Telex AFI. The Telex AFI is used because: o  It gives the largest DSP o  It is less likely than other forms to be used for ``real'' Network    AddressesThe following AFIs might have been chosen, but are not used for thereasons given: o  Local (the values must be globally unique) o  X.121 (because it may be confused with other uses of OSI network    addresses) o  DCC and ICD (because it may be confused with other uses of OSI    network addresses)The IDI should be assigned in a manner appropriate to the use of theencoding.  For example, for operation on a private network within anorganisation, the telex number of that organisation would be a goodchoice.  Some well known networks are given assignments inAppendix A.4.3  The DSP EncodingThe 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 informationThe DSP format is now defined.  The top level format is independent ofthe means used to provde COTS. Two formats for the remainder of theDSP are then defined, for specific means of providing COTS.A decimal abstract encoding is defined for the DSP. The ECMA 117format might have been used, but it is not suitable.  [TC386].  Use ofa binary encoding, with the DSP structured in ASN.1 would have been aHardcastle-Kille                                                Page 6

RFC 1277           Encoding Network Addresses            November 1991very attractive approach.  However, there is insufficient space in theNetwork 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 ofthe remainder of the DSP (Network Specific Part) is to be interpreted.4.4  X.25(80) Network Specific FormatThe IDP/Prefix identifies an X.25(80) subnetwork.  There is a need torepresent a DTE Number, and optionally an X.25 Protocol ID or CUDF(many implementations require these due to shortage of X.121 addressspace) 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 + PIDHardcastle-Kille                                                Page 7

RFC 1277           Encoding Network Addresses            November 1991    2 DTE + CUDF    3-9 ReservedPID/CUDF Length The length of the PID/CUDF in octetsPID/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'' wouldbe encoded in the following way.  The first lines describe theabstract 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.  Thisis the syntax most likely to be used in practice.  The CUDF isrepresented by two octets 049 and 050 (decimal), which map to sixdigits.4.5  TCP/IP (RFC 1006) Network Specific FormatThe IDP and 2 digit prefix identifies a TCP/IP network whereRFC 1006is applied.  It is necessary to use an IP Address, as there areinsufficient 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 1991For 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 to65535, and needs 5 digits (this is optional, and is defaulted asdefined inRFC 1006).  Finally, there is a third part to the address,which is defined here as ``transport set'' that indicates what kind ofIP-based transport protocols is used.  This is a decimal number from0-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 transportset is not there or no bits are set, it means ``default'' which isTCP. This is encoded in 5 digits.For example, the IP Address 10.0.0.6 with port 9 over UDP is encodedas:____________________________________________________________________________|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  EncodingThis document describes allocation of Network Addresses, with the DSPconsidered in Abstract Decimal.  The encoding of this for use inprotocols (typically as Concrete Binary) is described in ISO 8348Addendum 2 [ISO87a].6  ReferencesReferences[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 ConsiderationsSecurity considerations are not discussed in this memo.8 Author's Address Steve Hardcastle-Kille Department of Computer Science University College LondonHardcastle-Kille Page 10

RFC 1277           Encoding Network Addresses            November 1991    Gower Street    WC1E 6BT    England    Phone:  +44-71-380-7294    EMail:  S.Kille@CS.UCL.AC.UKHardcastle-Kille                                               Page 11

RFC 1277           Encoding Network Addresses            November 1991A  Allocations for well known networksA.1  ValuesThis appendix gives an allocation for three well known networks.  Allare allocated on the basis of the supposed Telex number 00728722.This number is being used in pilot operations, and so is retainedhere.               _______________________________________               |_________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 isneeded.  In other cases, an X.121 form Network Address with no DSPshould be used.A.2  DelegationThe values assigned in this document are now in widespread use.  Asthe number is arbitrary, it would be undesirable to change the numberswithout a sound technical reason.  However, it is important toguarantee that the numbers are stable.This Internet Draft commits UCL not to reassign the portions of thenumber space allocated here.The DARPA/NSF Internet space (Prefix 03) is delegated to the IANA.Hardcastle-Kille                                               Page 12

[8]ページ先頭