1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
|
Network Working Group S.E. Hardcastle-Kille
Requests for Comments 1277 University College London
November 1991
Encoding Network Addresses
to support operation over non-OSI lower layers
Status 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 using RFC 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).
^L
RFC 1277 Encoding Network Addresses November 1991
1 Introduction
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 RFCdefines mechanisms to encode addressing information
within Network Addresses, in order to support this type of working.
In particular, support is defined for RFC 1006 mapping of COTS onto
TCP/IP and COTS mapped onto X.25(1980) [RC87, CCI80].
Where an OSI application is run over CLNS on the internet, the NSAP
Guidelines of RFC 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 Note
This document was originally published as UCL Research Note RN/89/13
and as a project THORN internal document [Kil89]. It was devised in
response to two projects which faced this requirement, and was agreed
as 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 solution
demonstrated.
Hardcastle-Kille Page 1
^L
RFC 1277 Encoding Network Addresses November 1991
2 Problem Statement
When utilising the OSI Directory, the OSI location of an End System
will be determined by a Network Address, which is taken from a
Presentation Address, looked up in the OSI Directory.
OSI applications are currently operated over the following lower
layers.
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, utilising RFC 1006 to support the OSI
Transport Service[RC87].
o The DARPA/NSF Internet, using RFC 1006.
In general, these systems need to be interconnected by the use of
transport bridging or application relaying. Operation of transport
bridges causes a number of problems which it is desirable to avoid.
Only some applications can support relaying, and this is not always
satisfactory.
2.1 The ``Right Solution''
It is worth noting briefly what the intended (OSI) solution is. There
is a single global network service. Network Addresses are globally
allocated, and do not imply anything about routing or location. An
Hardcastle-Kille Page 2
^L
RFC 1277 Encoding Network Addresses November 1991
End System is attached to one or more subnetworks at Subnetwork Points
of Attachment (SNPAs). Intermediate Systems join subnetworks, again
being attached at SNPAs. Routing is achieved by repeated binding of
Network Address to SNPA (initially at the Originating End System, and
then at each Intermediate System). This binding is achieved by
network level routing mechanisms.
This can only work in a pure OSI environment with a single ubiquitous
network service (either connectionless or connection-oriented), and so
is not sufficient for the problem being addressed by this note.
2.2 General Approach
This section describes the use of network addresses, and gives a
functional overview of the problem being takceled. The means of
connecting 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 have
implications on the third. There is currently no directory service to
provide step 2, and so this (interim) approach must be algorithmic.
All addressing information required for the network must be extracted
from the network address.
This note describes the use of Network Addresses for networks which do
not provide the OSI Network Service (CLNS or CONS), and places
constraints on the use of X.121 form network addresses when used for
an OSI Network Service. The following types of Network Address are
discussed in this note:
----------------------------
1. Strictly an Application Entity should have only one
Presentation Address. In practice it may have several, and the
network addresses of each Presentation Address should be considered.
Hardcastle-Kille Page 3
^L
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 AFI
This note defines an approach for use of network addresses with the
X.121 AFI.
The IDP of network addresses is used to allow worldwide administration
of the NSAP address space. As such, not all values of the IDP will in
practice have topological significance (which implies that in some
cases the IDP will not be sufficient for network layer routing).
However, it is recommended that any End System using the Connection
Oriented Network Service and with access to the international X.25
service uses the X.121 form of NSAP address relative to its access
point. This allows routing across the worldwide X.25 based public
data 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 (end
system) cannot in principle assume any implied routing. However, due
to the lack of a network directory service, it is recommended that any
End System with Connection Oriented Network Service and access to the
international X.25 service uses X.121 form relative to its access
point. Allocation of DSP (Domain Specific Part) is a private issue.
Conversely it is recommended that if an X.121 IDP (Initial Domain
Part) form Network Address is interpreted, then the X.121 address will
provide a route (by defining an SNPA on the international X.25
network). There may be additional and perhaps preferable routes which
can be determined by private means.
If the DSP is absent, the form should be interpreted as implying a
mapping of Transport onto X.25(80).
4 New Network Address Format
This section defines a new network address format. The scope of this
format is currently:
1. Any TCP/IP network supporting COTS using RFC 1006.
Hardcastle-Kille Page 4
^L
RFC 1277 Encoding Network Addresses November 1991
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), 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 of
providing COTS (or CLTS). It is not appropriate for use where CONS or
CLNS is used to provide COTS (or CLTS).
4.1 Requirements
The requirements for use of OSI over existing networks not supporting
CONS 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) or RFC 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 Address
6. All network specific addressing information (including the SNPA)
must be deducible from the Network Address
Hardcastle-Kille Page 5
^L
RFC 1277 Encoding Network Addresses November 1991
4.2 IDP Choice
The 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
Addresses
The following AFIs might have been chosen, but are not used for the
reasons 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 the
encoding. For example, for operation on a private network within an
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
^L
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
^L
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
^L
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
^L
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
^L
RFC 1277 Encoding Network Addresses November 1991
Gower Street
WC1E 6BT
England
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK
Hardcastle-Kille Page 11
^L
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
|