File: rfc1377.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 (563 lines) | stat: -rw-r--r-- 22,109 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






Network Working Group                                            D. Katz
Request for Comments: 1377                                         cisco
                                                           November 1992


          The PPP OSI Network Layer Control Protocol (OSINLCP)

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 Point-to-Point Protocol (PPP) [1] provides a standard method of
   encapsulating Network Layer protocol information over point-to-point
   links.  PPP also defines an extensible Link Control Protocol, and
   proposes a family of Network Control Protocols (NCPs) for
   establishing and configuring different network-layer protocols.

   This document defines the NCP for establishing and configuring OSI
   Network Layer Protocols.

   This memo is the product of the Point-to-Point Protocol Working Group
   of the Internet Engineering Task Force (IETF).  Comments on this memo
   should be submitted to the ietf-ppp@ucdavis.edu mailing list.

Table of Contents

   1.     Introduction ..........................................    2
   1.1    OSI Network Layer Protocols over PPP ..................    2
   2.     A PPP Network Control Protocol (NCP) for OSI ..........    5
   2.1    Sending OSI NPDUs .....................................    6
   2.2    NPDU Alignment ........................................    6
   2.3    Network Layer Addressing Information ..................    6
   3.     OSINLCP Configuration Options .........................    7
   3.1    Align-NPDU ............................................    7
   REFERENCES ...................................................    9
   ACKNOWLEDGEMENTS .............................................    9
   SECURITY CONSIDERATIONS ......................................   10
   CHAIR'S ADDRESS ..............................................   10
   AUTHOR'S ADDRESS .............................................   10






Katz                                                            [Page 1]

RFC 1377                      PPP OSINLCP                  November 1992


1.  Introduction

   PPP has three main components:

      1. A method for encapsulating datagrams over serial links.

      2. A Link Control Protocol (LCP) for establishing, configuring,
         and testing the data-link connection.

      3. A family of Network Control Protocols (NCPs) for establishing
         and configuring different network-layer protocols.

   In order to establish communications over a point-to-point link, each
   end of the PPP link must first send LCP packets to configure and test
   the data link.  After the link has been established and optional
   facilities have been negotiated as needed by the LCP, PPP must send
   NCP packets to choose and configure one or more network-layer
   protocols.  Once each of the chosen network-layer protocols has been
   configured, datagrams from each network-layer protocol can be sent
   over the link.

   The link will remain configured for communications until explicit LCP
   or NCP packets close the link down, or until some external event
   occurs (an inactivity timer expires or network administrator
   intervention).

1.1.  OSI Network Layer Protocols over PPP

   A number of protocols have been defined for the Network Layer of OSI,
   including the Connectionless Network Layer Protocol (CLNP, ISO 8473)
   [3], the End System to Intermediate System routing protocol (ES-IS,
   ISO 9542) [4], the Intermediate System to Intermediate System routing
   protocol (IS-IS, ISO 10589) [5], and the Inter-Domain Routeing
   Protocol (IDRP, CD 10747) [6].  Generally, these protocols were
   designed to run over non-reliable data link protocols such as PPP.

   Network Layer Protocol Identifier (NLPID)

      OSI Network Layer protocols can be discriminated according to the
      first octet in each Network Protocol Data Unit (NPDU, that is,
      packet), known as the Network Layer Protocol Identifier (NLPID),
      which is defined in ISO/TR 9577 [7].  This allows the various
      protocols to be run over a common data link without any
      discriminator below the network layer.







Katz                                                            [Page 2]

RFC 1377                      PPP OSINLCP                  November 1992


   Inactive Network Layer Protocol

      ISO/TR 9577 reserves a NLPID value of zero to represent the
      "Inactive Network Layer Protocol", as defined in ISO 8473.  The
      inactive network layer protocol MUST NOT be used over PPP.  This
      assures that whichever OSI network layer protocol is used will
      have a non-zero NLPID value.

   Connection-Oriented Network Protocol

      The OSI Connection-Oriented Network Protocol (ISO 8208) [8],
      effectively the Packet Layer of CCITT X.25, is intended to be run
      over a reliable data link, such as IEEE 802.2 type II or LAPB.
      Therefore, the unreliable data link service provided by PPP is not
      appropriate for use with ISO 8208.

   ConnectionLess Network Protocol (CLNP)

      The ConnectionLess Network Protocol offers a simple non-reliable
      datagram service very similar to IP, and is designed to run over a
      non-reliable data link service, such as provided by PPP.

   End-System to Intermediate-System Protocol (ES-IS)

      ES Hellos and IS Hellos are retransmitted on a periodic timer-
      driven basis (based on expiration of the "Configuration Timer").
      The resulting ES and IS configuration information is invalidated
      on a timer driven basis, based on expiration of the "Holding
      Timer" for each piece of information.  The value of a Holding
      Timer is set by the source of the information, and transmitted in
      the Holding Time field of the appropriate ES-IS packet.  ISO 9542
      recommends that the holding time field is set to approximately
      twice the Configuration Timer parameter, such that even if every
      other Hello packet is lost the configuration information will be
      retained (implying that the Holding Timer is actually set to
      slightly more than twice the Configuration Timer).

      Generally, the recommendation in ISO 9542 is sufficient for PPP
      links.  For very unreliable links, it may be necessary to set the
      Holding Timer to be slightly more than three times the
      Configuration Timer to ensure that loss of configuration
      information is an unusual event.

      Redirect information is not transmitted on point-to-point links,
      but may be transmitted on general topology subnetworks, which in
      turn may make use of PPP.  Redirect information is sent on a
      event-driven basis (based on a CLNP packet being forwarded by a
      router out the incoming interface), but redirect information is



Katz                                                            [Page 3]

RFC 1377                      PPP OSINLCP                  November 1992


      invalidated on a timer-driven basis.  Loss of a single redirect
      may result in a subsequent data packet being sent to the same
      incorrect router, which will re-issue the redirect.  This operates
      in the same manner as ICMP redirects for IP packets, and does not
      pose any problem for operation over PPP links.

   Intermediate-System to Intermediate-System Protocol (IS-IS)

      IS-IS allows for broadcast links (typically LANs), point-to-point
      links (such as PPP), and general topology links (such as X.25
      networks) which are modelled as a collection of point-to-point
      links.

      There are four types of IS-IS packets: IS-IS Hello Packets, Link
      State Packets (LSPs), Complete Sequence Number Packets (CSNPs),
      and Partial Sequence Number Packets (PSNPs).

      IS-IS Hello messages are transmitted periodically on point-to-
      point links (based on expiration of the "ISISHello" timer).
      Routers expect to receive IS-IS Hello packets periodically.
      Specifically, the IS-IS Hello packet specifies a "Holding Time".
      If no subsequent IS-IS Hello is received over the corresponding
      link for the specified time period, then the neighboring router is
      assumed to have been disconnected or to be down.  It is highly
      undesireable for links to "flap" up and down unnecessarily, which
      implies that the holding time needs to be large enough that a link
      is very unlikely to be declared down due to a failure to receive
      an IS-IS Hello.  This implies that running IS-IS over unreliable
      data links requires the Holding time to be greater than "k" times
      the ISISHello timer, where k is chosen such that the loss of k
      consecutive IS-IS Hello's is rare.  If the quality of the link is
      poor, then the Holding Time will need to be increased or the
      "ISISHello" time decreased.

      LSPs are acknowledged by the IS-IS protocol (via use of partial
      sequence number packets).  A lost LSP will be recovered from with
      no problem provided that PPP links are treated the same way as
      other point-to-point links.  On those rare occasions where a
      partial sequence number packet is lost, this might result in the
      retransmission of a link state packet over a single link, but will
      not impact the correct operation of the routing algorithm.

      CSNPs are sent upon link startup on a point-to-point link.  This
      does not need to be changed for PPP.  If a CSNP fragment is lost
      upon startup it is merely loss of an optimization -- LSPs that did
      not need to be transmitted over the link will be transmitted.  If
      a periodic CSNP fragment is lost it merely means that detection of
      low probability database corruption will take longer.



Katz                                                            [Page 4]

RFC 1377                      PPP OSINLCP                  November 1992


      PSNPs function as ACKs.  Loss of a PSNP may result in an
      unnecessary retransmission of an LSP, but does not prevent correct
      operation of the routing protocol.

   Inter-Domain Routeing Protocol (IDRP)

      IDRP expects to run over datagram links, but requires reliable
      exchange of IDRP information.  For this reason, IDRP contains
      built-in reliability mechanisms which ensure that packets will be
      received correctly.

2.  A PPP Network Control Protocol (NCP) for OSI

   The OSI Network Layer Control Protocol (OSINLCP) is responsible for
   configuring, enabling, and disabling the OSI protocol modules on both
   ends of the point-to-point link.  OSINLCP uses the same packet
   exchange machanism as the Link Control Protocol (LCP).  OSINLCP
   packets may not be exchanged until PPP has reached the Network-Layer
   Protocol phase.  OSINLCP packets received before this phase is
   reached should be silently discarded.

   The OSI Network Layer Control Protocol is exactly the same as the
   Link Control Protocol [1] with the following exceptions:

   Frame Modifications

      The packet may utilize any modifications to the basic frame format
      which have been negotiated during the Link Establishment phase.

   Data Link Layer Protocol Field

      Exactly one OSINLCP packet is encapsulated in the Information
      field of a PPP Data Link Layer frame where the Protocol field
      indicates type hex 8023 (OSI Network Layer Control Protocol).

   Code field

      Only Codes 1 through 7 (Configure-Request, Configure-Ack,
      Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
      and Code-Reject) are used.  Other Codes should be treated as
      unrecognized and should result in Code-Rejects.

   Timeouts

      OSINLCP packets may not be exchanged until PPP has reached the
      Network-Layer Protocol phase.  An implementation should be
      prepared to wait for Authentication and Link Quality Determination
      to finish before timing out waiting for a Configure-Ack or other



Katz                                                            [Page 5]

RFC 1377                      PPP OSINLCP                  November 1992


      response.  It is suggested that an implementation give up only
      after user intervention or a configurable amount of time.

   Configuration Option Types

      OSINLCP has one Configuration Option, which is defined below.

2.1.  Sending OSI NPDUs

   Before any Network Protocol Data Units (NPDUs) may be communicated,
   PPP must reach the Network-Layer Protocol phase, and the OSI Network
   Layer Control Protocol must reach the Opened state.

   Exactly one OSI NPDU is encapsulated in the Information field of a
   PPP Data Link Layer frame where the Protocol field indicates type hex
   0023 (OSI Network Layer).

   The maximum length of an OSI NPDU transmitted over a PPP link is the
   same as the maximum length of the Information field of a PPP data
   link layer frame.  Larger NPDUs must be segmented as necessary.  If a
   system wishes to avoid segmentation and reassembly, it should use
   transport layer mechanisms to discourage others from sending large
   PDUs.

2.2.  NPDU Alignment

   OSI protocols have peculiar alignment problems due to the fact that
   they are often encapsulated in data link protocols with odd-length
   headers, while PPP defaults to even-length headers.  A router
   switching an OSI packet may find that the beginning of the packet
   falls on an inconvenient memory boundary when the hardware used to
   transmit the packet to its next hop requires a particular alignment.
   This situation can be addressed by the use of leading zero padding.

   When sending, an implementation MAY insert one to three octets of
   zero between the PPP header and the OSI NPDU.  These zero octets
   correspondingly reduce the maximum length of the NPDU that may be
   transmitted.

   On reception, any such leading zero octets (if present) MUST be
   removed.  Regardless of whether leading zero padding is used, an
   implementation MUST also be able to receive a PPP packet with any
   arbitrary alignment of the NPDU.

2.3.  Network Layer Addressing Information

   OSINLCP does not define a separate configuration option for the
   exchange of OSI Network Layer address information.  Instead, the ES-



Katz                                                            [Page 6]

RFC 1377                      PPP OSINLCP                  November 1992


   IS protocol, ISO 9542, should be used.  This protocol provides a
   mechanism for determining the Network Layer address(es) of the
   neighbor on the link, as well as determining if the neighbor is an
   End System or an Intermediate System.

   A draft addendum to ES-IS [9] is being defined in ISO to add support
   for dynamic address assignment.  This addendum has currently passed
   the formal "Committee Draft" (CD) letter ballot.

3.  OSINLCP Configuration Options

   OSINLCP Configuration Options allow negotiatiation of desirable
   Internet Protocol parameters.  OSINLCP uses the same Configuration
   Option format defined for LCP [1], with a separate set of Options.

   The most up-to-date values of the OSINLCP Option Type field are
   specified in the most recent "Assigned Numbers" RFC [2].  Current
   values are assigned as follows:

      1       Align-NPDU

3.1.  Align-NPDU

   Description

      This Configuration Option provides a way for the receiver to
      negotiate a particular alignment of the OSI NPDU.  Empirical
      evidence suggests that the greatest time deficit for re-alignment
      exists at the receiver.

      The alignment is accomplished through combination of PPP header
      compression with leading zero padding (see above).  It is
      recommended that alignment be entirely through header compression
      combinations whenever possible.  For example, an alignment of 3
      could be achieved by combining uncompressed PPP Address and
      Control fields (2 octets) with a compressed PPP Protocol field (1
      octet).

      This option is negotiated separately in each direction.  A
      receiver which does not need alignment MUST NOT request the
      option.  A sender which desires alignment prior to sending SHOULD
      Configure-Nak with an appropriate value.

         Implementation Note: In a complex environment, there might be
         several conflicting needs for alignment.  It is recommended
         that the receiver request alignment based on the needs of the
         highest speed next hop link.  Also, greater efficiency might be
         obtained by negotiating upstream the values requested by



Katz                                                            [Page 7]

RFC 1377                      PPP OSINLCP                  November 1992


         downstream PPP links, since those packets will not need a
         change in alignment on transit.

      The alignment request is advisory, and failure to agree on an
      alignment MUST NOT prevent the OSINLCP from reaching the Opened
      state.  By default, the alignment is done according to the needs
      of the sender, and all receivers MUST be capable of accepting
      packets with any alignment.

         Vernacular: If you don't like this option, you can refuse to
         negotiate it, and you can send whatever alignment you want.
         However, if you accept the peer's alignment option, then you
         MUST transmit packets with the agreed alignment.

   A summary of the Align-NPDU Configuration Option format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |   Alignment   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      1

   Length

      3

   Alignment

      This field specifies the offset of the beginning of the OSI NPDU
      relative to the beginning of the PPP packet header (not including
      any leading Flag Sequences).

      A value of 1 through 4 requires an offset of that specific length,
      modulo 4.  For example, a value of 1 would require no padding when
      the PPP Address, Control, and Protocol fields are compressed.  One
      octet of leading zero padding would be necessary when the PPP
      header is full sized.

      A value of 255 requests an offset of an odd length (1 or 3).  A
      value of 254 requests an offset of an even length (2 or 4).  If
      the sender is not capable of dynamically varying the amount of
      padding, it MUST NAK with one of the two specific values.




Katz                                                            [Page 8]

RFC 1377                      PPP OSINLCP                  November 1992


References

   [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
       Daydreamer, May 1992.

   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.

   [3] ISO, "Information processing systems -- Data communications --
       Protocol for providing the connectionless-mode network
       service", ISO 8473, 1988.

   [4] ISO, "Information processing systems -- Telecommunications and
       information exchange between systems -- End system to
       Intermediate system Routeing exchange protocol for use in
       conjunction with the protocol for providing the connectionless-
       mode network service (ISO 8473)", ISO 9542, 1988.

   [5] ISO, "Information processing systems -- Telecommunications and
       information exchange between systems -- Intermediate system to
       Intermediate system Intra-Domain routeing exchange protocol for
       use in conjunction with the protocol for providing the
       connectionless-mode network service (ISO 8473)", ISO 10589,
       1990.

   [6] ISO, "Protocol for Exchange of Inter-domain Routeing
       Information among Intermediate Systems to Support Forwarding of
       ISO 8473 PDUs", ISO CD 10747, 1991.

   [7] ISO, "Information technology -- Telecommunications and
       information exchange between systems -- Protocol identification
       in the network layer", ISO/IEC TR9577:1990.

   [8] ISO, "Information processing systems -- Data communications --
       X.25 packet level protocol for Data terminal equipment", ISO
       8208, 1984.

   [9] Taylor, E., "Addendum to ISO 9542 (PDAM 1 - Dynamic Discovery
       of OSI NSAP Addresses by End Systems)", SC6/N7248.

Acknowledgments

   Some of the text in this document is taken from previous documents
   produced by the Point-to-Point Protocol Working Group of the Internet
   Engineering Task Force (IETF).

   Special thanks to Ross Callon (DEC), and Cyndi Jung (3Com), for
   contributions of text and design suggestions based on implementation



Katz                                                            [Page 9]

RFC 1377                      PPP OSINLCP                  November 1992


   experience.

   Thanks also to Bill Simpson for his editing and formatting efforts,
   both for this document and for PPP in general.

Security Considerations

   Security issues are not discussed in this memo.

Chair's Address

   The working group can be contacted via the current chair:

   Brian Lloyd
   Lloyd & Associates
   3420 Sudbury Road
   Cameron Park, California 95682

   Phone: (916) 676-1147
   EMail: brian@lloyd.com

Author's Address

   Questions about this memo can also be directed to:

   Dave Katz
   cisco Systems, Inc.
   1525 O'Brien Dr.
   Menlo Park, CA  94025

   Phone: (415) 688-8284
   EMail: dkatz@cisco.com



















Katz                                                           [Page 10]