File: rfc1209.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (619 lines) | stat: -rw-r--r-- 24,662 bytes parent folder | download | duplicates (8)
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






Network Working Group                                      D. Piscitello
Request for Comments: 1209                                   J. Lawrence
                                            Bell Communications Research
                                                              March 1991


         The Transmission of IP Datagrams over the SMDS Service

Status of this Memo

   This memo defines a protocol for the transmission of IP and ARP
   packets over a Switched Multi-megabit Data Service Network configured
   as a logical IP subnetwork.  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

   This memo describes an initial use of IP and ARP in an SMDS service
   environment configured as a logical IP subnetwork, LIS (described
   below).  The encapsulation method used is described, as well as
   various service-specific issues.  This memo does not preclude
   subsequent treatment of the SMDS Service in configurations other than
   LIS; specifically, public or inter-company, inter-enterprise
   configurations may be treated differently and will be described in
   future documents.  This document considers only directly connected IP
   end-stations or routers; issues raised by MAC level bridging are
   beyond the scope of this paper.

Acknowledgment

   This memo draws heavily in both concept and text from [4], written by
   Jon Postel and Joyce K. Reynolds of ISI and [5], written by David
   Katz of Merit, Inc.  The authors would also like to acknowledge the
   contributions of the IP Over SMDS Service working group of the
   Internet Engineering Task Force.

Conventions

   The following language conventions are used in the items of
   specification in this document:

      o MUST, SHALL, or MANDATORY -- the item is an absolute
        requirement of the specification.




IP over SMDS Working Group                                      [Page 1]

RFC 1209            IP and ARP over the SMDS Service          March 1991


      o SHOULD or RECOMMENDED -- the item should generally be followed
        for all but exceptional circumstances.

      o MAY or OPTIONAL -- the item is truly optional and may be
        followed or ignored according to the needs of the implementor.

Introduction

   The goal of this specification is to allow compatible and
   interoperable implementations for transmitting IP datagrams and ARP
   requests and replies.

   The characteristics of the SMDS Service and the SMDS Interface
   Protocol (SIP) are presented in [3], [6], and in [7].  Briefly, the
   SMDS Service is a connectionless, public, packet-switched data
   service.  The operation and features of the SMDS Service are similar
   to those found in high-speed data networks such as LANs:

      o The SMDS Service provides a datagram packet transfer, where each
        data unit is handled and switched separately without the prior
        establishment of a network connection.

      o The SMDS Service exhibits high throughput and low delay, and
        provides the transparent transport and delivery of up to 9188
        octets of user information in a single transmission.

      o No explicit flow control mechanisms are provided; instead, the
        rate of information transfer on the access paths is controlled
        both in the subscriber-to-network direction and in the network-
        to-subscriber direction through the use of an access class
        enforcement mechanism.

      o Both individually and group-addressed (multicast) packets can
        be transferred.

      o In addition to these LAN-like features, a set of addressing-
        related service features (source address validation, source and
        destination address screening) are provided to enable a
        subscriber or set of subscribers to create a logical private
        network, or closed user group, over the SMDS Service.  The
        access control provided by the closed user group mechanism is
        supplied by the SMDS provider according to the specifications
        stated in [3].

      o SMDS addresses are 60 bits plus a 4 bit Address Type.  The
        Address Type subfield occupies the 4 most significant bits of
        the destination and source address fields of the SIP Level 3
        Protocol Data Unit (PDU).  It contains the value 1100 to



IP over SMDS Working Group                                      [Page 2]

RFC 1209            IP and ARP over the SMDS Service          March 1991


        indicate an individual address and the value 1110 for a 60-bit
        group address.

   The SMDS Interface Protocol is based on the IEEE Standard 802.6,
   Distributed Queue Dual Bus (DQDB) Connectionless MAC protocol [8].
   The SMDS service layer corresponds to the IEEE 802 MAC sublayer.  The
   remainder of the Data Link Service is provided by the IEEE 802.2
   Logical Link Control (LLC) service [9].  The resulting stack of
   services is illustrated in Figure 1:

                           +--------------------+
                           |      IP/ARP        |
                           +--------------------+
                           |IEEE 802.2 LLC/SNAP |
                           +--------------------+
                           | SIP LEVEL 3 (MAC)  |
                           +--------------------+
                           | SIP LEVELS 1 & 2   |
                           +--------------------+

            Figure 1.  Protocol stack for IP over SMDS Service

   This memo describes an initial use of IP and ARP in an SMDS Service
   environment configured as a logical IP subnetwork (described below).
   It does not preclude subsequent treatment of SMDS Service in
   configurations other than logical IP subnetworks; specifically,
   public or inter-company, inter-enterprise configurations may be
   treated differently and will be described in future documents.  This
   document does not address issues related to transparent data link
   layer interoperability.

Logical IP Subnetwork Configuration

   This section describes the scenario for an SMDS Service that is
   configured with multiple logical IP subnetworks, LIS (described
   below).  The scenario considers only directly connected IP end-
   stations or routers; issues raised by MAC level bridging are beyond
   the scope of this paper.

   In the LIS scenario, each separate administrative entity configures
   its hosts within a closed logical IP subnetwork.  Each LIS operates
   and communicates independently of other LISs over the same network
   providing SMDS.  Hosts connected to SMDS communicate directly to
   other hosts within the same LIS.  Communication to hosts outside of
   an individual LIS is provided via an IP router.  This router would
   simply be a station attached to the SMDS Service that has been
   configured to be a member of both logical IP subnetworks.  This
   configuration results in a number of disjoint LISs operating over the



IP over SMDS Working Group                                      [Page 3]

RFC 1209            IP and ARP over the SMDS Service          March 1991


   same network supporting the SMDS Service.  It is recognized that with
   this configuration, hosts of differing IP networks would communicate
   via an intermediate router even though a direct path over the SMDS
   Service may be possible.

   It is envisioned that the service will evolve to provide a more
   public interconnection, allowing machines directly connected to the
   SMDS Service to communicate without an intermediate router.  However,
   the issues raised by such a large public interconnection, such as
   scalability of address resolution or propagation of routing updates,
   are beyond the scope of this paper.  We anticipate that future RFCs
    will address these issues.

   The following is a list of the requirements for a LIS configuration:

      o All members have the same IP network/subnet number.

      o All stations within a LIS are accessed directly over SMDS.

      o All stations outside of the LIS are accessed via a router.

      o For each LIS a single SMDS group address has been configured
        that identifies all members of the LIS.  Any packet transmitted
        with this address is delivered by SMDS Service to all members
        of the LIS.

   The following list identifies a set of SMDS Service specific
   parameters that MUST be implemented in each IP station which would
   connect to the SMDS Service.  The parameter values will be determined
   at SMDS subscription time and will be different for each LIS.  Thus
   these parameters MUST be user configurable.

      o SMDS Hardware Address (smds$ha).  The SMDS Individual address
        of the IP station as determined at subscription time.  Each
        host MUST be configured to accept datagrams destined for this
        address.

      o SMDS LIS Group Address(smds$lis-ga).  The SMDS Group address
        that has been configured at subscription time to identify the
        SMDS Subscriber Network Interfaces (SNI) of all members of the
        LIS connected to the SMDS Service.  All members of the LIS MUST
        be prepared to accept datagrams addressed to smds$lis-ga.

      o SMDS Arp Request Address (smds$arp-req).  The SMDS address
        (individual or group) to which arp requests are to be sent.  In
        the initial LIS configuration this value is set to smds$lis-ga.
        It is conceivable that in other configurations this value would
        be set to some address other than that of smds$lis-ga (see



IP over SMDS Working Group                                      [Page 4]

RFC 1209            IP and ARP over the SMDS Service          March 1991


        section on Address Resolution).

   It is RECOMMENDED that routers providing LIS functionality over the
   SMDS service also support the ability to interconnect differing LISs.
   Routers that wish to provide interconnection of differing LISs MUST
   be able to support multiple sets of these parameters (one set for
   each connected LIS) and be able to associate each set of parameters
   with a specific IP network/subnet number.  In addition, it is
   RECOMMENDED that a router be able to provide this multiple LIS
   support with a single physical SMDS interface that may have one or
   more individual SMDS addresses.

   The following list identifies LIS specific parameters that MUST be
   configured in the network supporting the SMDS Service.  For each LIS,
   the IP network administrator MUST request the configuration of these
   parameters at subscription time.  The administrator of each LIS MUST
   update these parameters as each new station is added to the LIS.

      o SMDS LIS Group Address(smds$lis-ga).  An SMDS Group address MUST
        be configured at subscription time to identify the SMDS
        Subscriber Network Interfaces (SNI) of all members of the LIS
        connected to the SMDS Service.

      o SMDS Address Screening Tables (Source and Destination).  The use
        of SMDS screening tables is not necessary for the operation of
        IP over SMDS Service.  If the SMDS screening tables are to be
        used, both source and destination tables for each SNI MUST be
        configured to allow, at minimum, both the direct communication
        between all hosts in the same LIS and the use of the SMDS LIS
        Group Address.

Packet Format

      Service SHALL be encapsulated within the IEEE 802.2 LLC and IEEE
      802.1A Sub-Network Access Protocol (SNAP) [10] Data Link layers
      and the 3-level SIP.  The SNAP MUST be used with an
      Organizationally Unique Identifier Code indicating that the SNAP
      header contains the EtherType code as listed in Assigned Numbers
      [11] (see Figure 2).  Note that values specified in this document
      follow Internet conventions: multi-byte fields are described in
      big-endian order and bits within bytes are described as most
      significant first [11].









IP over SMDS Working Group                                      [Page 5]

RFC 1209            IP and ARP over the SMDS Service          March 1991


                                                       +-------+
                                                       |IP/ARP | IP/ARP
                              +----+----+----+----+----+-------+
                              |   Org Code   |Ethertype|       | SNAP
               +----+----+----+----+----+----+----+----+-------+
               |DSAP|SSAP|Ctrl|                                | LLC
+-----+----+-+-+----+----+----+----+----+----+----+----+-------+
|SIP..|HLPI|...|                                               | SIP L3
+-----+----+-+-+----+----+----+----+----+----+----+----+-------+

                    Figure 2.  Data Link Encapsulation

      o The value of HLPI in the SIP L3 Header is 1.

      o The total length of the LLC Header and the SNAP header is 8
        octets.

      o The value of DSAP and SSAP in the LLC header is 170 (decimal),
        AA (Internet hexadecimal).

      o The Ctrl (Control) value in the LLC header is 3 (Indicates Type
        One Unnumbered Information).

      o The Org Code in the SNAP header is zero (000000 Internet
        hexadecimal).

      o The EtherType for IP is 2048 (decimal), 0800 (Internet
        hexadecimal).  The EtherType for ARP is 2054 (decimal), 0806
        (Internet hexadecimal).

   IEEE 802.2 LLC Type One Unnumbered Information (UI) communication
   (which must be implemented by all conforming IEEE 802.2 stations) is
   used exclusively.  The Higher Layer Protocol Id (HLPI) field in the
   SIP L3_PDU header MUST be set to the IEEE 802.6 assigned Protocol Id
   value for LLC (decimal 1) [8].  All frames MUST be transmitted in
   standard IEEE 802.2 LLC Type 1 Unnumbered Information format, with
   the DSAP and the SSAP fields of the IEEE 802.2 header set to the
   assigned global SAP value for SNAP (decimal 170) [10].  The 24-bit
   Org Code (Organizationally Unique Identifier Code) in the SNAP MUST
   be set to a value of zero, and the remaining 16 bits are set to the
   EtherType value from Assigned Numbers [11] (2048 for IP, 2054 for
   ARP).

   The data link encapsulation for IP packets is shown in Figure 3 and
   for ARP in Figure 4.  All values shown are in Internet hexadecimal
   format.





IP over SMDS Working Group                                      [Page 6]

RFC 1209            IP and ARP over the SMDS Service          March 1991


     +--------------+---------------------------------------+-------+
     |      SIP     |             LLC / SNAP                |  IP   |
     |              |                                       |       |
     |SIP..|HLPI|...|DSAP|SSAP|Ctrl|   Org Code   |Ethertype|       |
     +-----+----+-+-+----+----+----+----+----+----+----+----+-------+
     |SIP..| 01 |...| AA | AA | 03 |    000000    |  0800   | IP... |
     +-----+----+-+-+----+----+----+----+----+----+----+----+-------+

             Figure 3.  IP Data Link Encapsulation and Values



     +--------------+---------------------------------------+-------+
     |      SIP     |             LLC / SNAP                |  ARP  |
     |              |                                       |       |
     |SIP..|HLPI|...|DSAP|SSAP|Ctrl|   Org Code   |Ethertype|       |
     +-----+----+-+-+----+----+----+----+----+----+----+----+-------+
     |SIP..| 01 |...| AA | AA | 03 |    000000    |  0806   | ARP...|
     +-----+----+-+-+----+----+----+----+----+----+----+----+-------+

             Figure 4.  ARP Data Link Encapsulation and Values

Address Resolution

   The dynamic mapping of 32-bit Internet addresses to SMDS addresses
   SHALL be done via the dynamic discovery procedure of the Address
   Resolution Protocol (ARP) [2].

   Internet addresses are assigned independent of SMDS addresses.  Each
   host implementation MUST know its own Internet address and SMDS
   address and respond to Address Resolution requests appropriately.
   Hosts MUST also use ARP to map Internet addresses to SMDS addresses
   when needed.

   The ARP protocol has several fields that parameterize its use in any
   specific context [2].  These fields are:

           ar$hrd   16 - bits     The Hardware Type Code
           ar$pro   16 - bits     The Protocol Type Code
           ar$hln    8 - bits     Octets in each hardware address
           ar$pln    8 - bits     Octets in each protocol address
           ar$op    16 - bits     Operation Code

      o The hardware type code assigned to SMDS addresses is 14
        (decimal), 0E (Internet hexadecimal) [11].

      o The protocol type code for IP is 2048 (decimal), 0800
        (Internet hexadecimal) [11].



IP over SMDS Working Group                                      [Page 7]

RFC 1209            IP and ARP over the SMDS Service          March 1991


      o The hardware address length for SMDS is 8.

      o The protocol address length for IP is 4.

      o The operation code is 1 for request and 2 for reply.

   The SMDS hardware addresses in ARP packets (ar$sha, ar$tha) MUST be
   carried in SMDS native address format, with the most significant bit
   of the Address Type sub-field as the high order bit of the first
   octet.  Although outside the scope of this document, it is
   RECOMMENDED that SMDS addresses be represented in this format in all
   higher layer Internet protocols (e.g., SNMP).

   Traditionally, ARP requests are broadcast to all directly connected
   stations.  For the SMDS Service, the ARP request packet is
   transmitted to the smds$arp-req hardware address.  In the LIS
   configuration, the smds$arp-req address is set to smds$lis-ga, (the
   SMDS group address that identifies all members of the LIS).  It is
   conceivable that in a larger scale, public configuration, the
   smds$arp-req address would be configured to the address of some ARP-
   server(s) instead of the group address that identifies the entire
   LIS.

IP Broadcast Address

   There is no facility for complete hardware broadcast addressing over
   the SMDS Service.  As discussed in the "LIS Configuration" section,
   an SMDS group address (smds$lis-ga) SHALL be configured to include
   all stations in the same LIS.  The broadcast Internet address (the
   address on that network with a host part of all binary ones) MUST be
   mapped to smds$lis-ga (see also [12]).

IP Multicast Support

   A method of supporting IP multicasting is specified in [13].  It
   would be desirable to fully utilize the SMDS group address
   capabilities to support IP multicasting.  However, the method in [13]
   requires a Network Service Interface which provides multicast-like
   ability to provide dynamic access to the local network service
   interface operations:

      o JoinLocalGroup (group-address)

      o LeaveLocalGroup (group-address)

   The SMDS group address ability does not currently support dynamic
   subscription and removal from group address lists.  Therefore, it is
   RECOMMENDED that in the LIS configuration, if IP multicasting is to



IP over SMDS Working Group                                      [Page 8]

RFC 1209            IP and ARP over the SMDS Service          March 1991


   be supported, the method of IP multicasting described for pure
   broadcast media, such as the Experimental Ethernet, be used.  For
   this method, all Multicast IP addresses are mapped to the same SMDS
   address which the broadcast Internet address is mapped for a given
   LIS.  Thus all Multicast IP addresses are mapped to smds$lis-ga.
   Filtering of multicast packets MUST be performed in the destination
   host.

Trailer Formats

   Some versions of Unix 4.x BSD use a different encapsulation method in
   order to get better network performance with the VAX virtual memory
   architecture.  Trailers SHALL not be used over the SMDS Service.

Byte Order

   As described in Appendix B of the Internet Protocol specification
   [1], the IP datagram is transmitted over the SMDS Service as a series
   of 8-bit bytes.  The byte order of the IP datagram shall be mapped
   directly onto the native SMDS byte order.

MAC Sublayer Details

Packet Size

   The SMDS Service defines a maximum service data unit size of 9188
   information octets.  This leaves 9180 octets for user data after the
   LLC/SNAP header is taken into account.  Therefore, the MTU for IP
   stations operating over the network supporting the SMDS Service SHALL
   be 9180 octets.

   There is no minimum packet size restriction defined for the SMDS
   Service.

Other MAC Sublayer Issues

   The SMDS Service requires that the publicly administered 60-bit
   address plus 4-bit type field format SHALL be used in both source and
   destination address fields of the SIP L3_PDU [3].

IEEE 802.2 Details

   While not necessary for supporting IP and ARP, all implementations
   MUST support IEEE 802.2 standard Class I service in order to be
   compliant with IEEE 802.2.  Some of the functions are not related
   directly to the support of the SNAP SAP (e.g., responding to XID and
   TEST commands directed to the null or global SAP addresses), but are
   part of a general LLC implementation.  Both [4] and [5] describe the



IP over SMDS Working Group                                      [Page 9]

RFC 1209            IP and ARP over the SMDS Service          March 1991


   minimum functionality necessary for a conformant station.
   Implementors should also consult IEEE Std. 802.2 [14] for details.

REFERENCES

    1. Postel, J., "Internet Protocol", RFC 791, USC/Information
       Sciences Institute, September 1981.

    2. Plummer, D., "An Ethernet Address Resolution Protocol - or -
       Converting Network Protocol Addresses to 48.bit Ethernet Address
       for Transmission on Ethernet Hardware", RFC 826, MIT, November
       1982.

    3. "Generic Systems Requirements in support of Switched Multi-
       megabit Data Service", Technical Advisory TA-TSY-000772, Bellcore
       Technical Advisory, Issue 3, October 1989.

    4. Postel, J., and J. Reynolds, "A Standard for the Transmission of
       IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information
       Sciences Institute, February 1988.

    5. Katz, D., "A Proposed Standard for the Transmission of IP
       Datagrams over FDDI Networks", RFC 1188, Merit/NSFNET, October
       1990.

    6. Dix, F., Kelly, M., and R. Klessig, "Access to a Public Switched
       Multi-Megabit Data Service Offering", ACM SIGCOMM CCR, July 1990.

    7. Hemrick, C. and L. Lang, "Introduction to Switched Multi-megabit
       Data Service (SMDS), an Early Broadband Service", publication
       pending in the Proceedings of the XIII International Switching
       Symposium (ISS 90), May 27, 1990 - June 1, 1990.

    8. Institute of Electrical & Electronic Engineers, Inc. IEEE
       Standard 802.6, "Distributed Queue Dual Bus (DQDB) Subnetwork of
       a Metropolitan Area Network (MAN) Standard", December 1990.

    9. IEEE, "IEEE Standards for Local Area Networks: Logical Link
       Control", IEEE, New York, New York, 1985.

   10. IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.

   11. Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
       USC/Information Sciences Institute, March 1990.

   12. Braden, R., and J. Postel, "Requirements for Internet Gateways",
       RFC 1009, USC/Information Sciences Institute, June 1987.




IP over SMDS Working Group                                     [Page 10]

RFC 1209            IP and ARP over the SMDS Service          March 1991


   13. Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
       Stanford University, August 1989.

   14. IEEE,"ANSI/IEEE Std 802.2-1985, ISO Draft International Standard
       8802/2", IEEE, New York, New York, 1985.

Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Dave Piscitello
   Bell Communications Research
   331 Newman Springs Road
   Red Bank, NJ  07701

   Phone: (908) 758-2286

   EMail: dave@sabre.bellcore.com


   Joseph Lawrence
   Bell Communications Research
   331 Newman Springs Road
   Red Bank, NJ  07701

   Phone: (908) 758-4146

   EMail: jcl@sabre.bellcore.com





















IP over SMDS Working Group                                     [Page 11]