idnits 2.17.1 draft-passera-lcp-misc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 13) being 615 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 87: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 91: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 94: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 100: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 102: '...hich does not include this option MUST...' (29 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1998) is 9293 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 560, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 562, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1634 (ref. '2') ** Obsolete normative reference: RFC 1700 (ref. '3') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 2153 (ref. '4') Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Gerard G. PASSERA 2 Expiration: November 1998 3 File: draft-passera-lcp-misc-01.txt 5 PPP LCP extensions for Initial Program load, 6 Discard received, Link Bandwidth and Link Delay measurements 8 June 25, 1998 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as ``work 21 in progress.'' 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Abstract 32 This document presents five extensions to the PPP/LCP Protocol : 34 * Assistance from a router to another router (or a host) looking 35 for its Operating System file. 36 * Assistance from a router to another router (or a host) looking 37 for its configuration file. 38 * Request from an equipment to receive Discard frame when no Data 39 frame can be sent. When no Discard or Data frames are received 40 the link will be brought down. This method is more efficient 41 than using a timeout and/or a keepalive mecanism. 42 * Interface Bandwidth and Delay measurements. These informations 43 can be used by OSPF or any other IGP protocol. 45 Table of Contents 47 1 Introduction 2 48 1. 1 Specification of Requirements 2 49 1.2 Terminology 3 50 2 LCP extensions 4 51 2.1 Request for Operating System file 4 52 2.2 Request for Configuration file 5 53 2.3 Request for Discard frame to be sent 6 54 2.4 Link Bandwidth Measurement 8 55 2.5 Link Delay Measurement 10 56 3 Security Considerations 12 57 4 References 12 58 5 Acknowledgment 12 59 6 Authors' Information 13 61 1 Introduction 63 There is a need for a router to help another router or a host 64 which is looking for its operating system and/or its 65 configuration. Such mechanisms are already offered on proprietary 66 link protocol with TFTP. More performing protocols should be 67 allowed on PPP which will then be able to replace all point-to- 68 point protocols. 70 Most of the equipment which test the PPP link do it by sending 71 periodically an echo request message. Their hold time is three 72 times the frequency of the hello. It will be faster to detect a 73 broken end to end link if both devices send Discard frame when 74 they have no data to send. 76 OSPF and some other proprietary routing protocol base their 77 routing decision on the value of the bandwidth. The most 78 important factor is in fact the delay. This information is not 79 easy to find. PPP/LCP could help the administrator. 81 1.1. Specification of Requirements 83 In this document, several words are used to signify the 84 requirements of the specification. These words are often 85 capitalized. 87 MUST This word, or the adjective "required", means that the 88 definition is an absolute requirement of the 89 specification. 91 MUST NOT This phrase means that the definition is an absolute 92 prohibition of the specification. 94 SHOULD This word, or the adjective "recommended", means that 95 there may exist valid reasons in particular 96 circumstances to ignore this item, but the full 97 implications must be understood and carefully weighed 98 before choosing a different course. 100 MAY This word, or the adjective "optional", means that this 101 item is one of an allowed set of alternatives. An 102 implementation which does not include this option MUST 103 be prepared to interoperate with another implementation 104 which does include the option. 106 1.2. Terminology 108 This document frequently uses the following terms: 110 datagram The unit of transmission in the network layer (such as 111 IP). A datagram may be encapsulated in one or more 112 packets passed to the data link layer. 114 frame The unit of transmission at the data link layer. A 115 frame may include a header and/or a trailer, along with 116 some number of units of data. 118 packet The basic unit of encapsulation, which is passed across 119 the interface between the network layer and the data 120 link layer. A packet is usually mapped to a frame; the 121 exceptions are when data link layer fragmentation is 122 being performed, or when multiple packets are 123 incorporated into a single frame. 125 peer The other end of the point-to-point link. 127 silently discard 128 The implementation discards the packet without further 129 processing. The implementation SHOULD provide the 130 capability of logging the error, including the contents 131 of the silently discarded packet, and SHOULD record the 132 event in a statistics counter. 134 master 135 The peer offering its assistance 137 slave 138 The peer requesting its operating system and/or its 139 configuration files. 141 2 LCP Extensions 143 2.1 Request for Operating System file 145 This operation MUST take place before any other LCP operation. 147 The slave send a LCP Configure-Request [1] for the type of IP 148 protocol it wish to use. 150 The master MUST reply with a Configure-Ack if the requested 151 protocol is supported, a Configure-Nak if the protocol is not 152 supported or a Terminate-Request if the operation is not 153 possible. Any other message will be ignored. 155 Once the protocol has been negotiated, the file transfer can 156 start. The slave MUST remain in charge of the protocol. A 157 specific value is used by the Request for Operating System file 158 protocol (0xC321) for each datagram of the file transfer. 160 The destination address of the IP packet sent by the slave MUST 161 be 255.255.255.255. The source address of the IP packet sent by 162 the slave MUST be 127.x.x.x. The master MUST replace 163 destination and source addresses with the address of the file 164 server and its own source address. 166 The name of the requested file MUST be provided by the slave. 167 Any other � user � information relevant to the file transfer 168 protocol MUST be provided by the master. 170 Once the file transfer is completed, the slave MUST send a 171 Terminate-Request [1]. The master will respond with a 172 Terminate-Ack. 174 The master SHOULD terminated the link when no data have been 175 received from the slave or the file server for 60 seconds 177 A summary of the Request for Operating System file 178 Configuration Option format is shown below. The fields are 179 transmitted from left to right. 181 0 1 2 3 182 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Type | Length | Port Number | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | IP Protocol | 187 +-+-+-+-+-+-+-+-+ 189 Type 191 24 193 Length 195 5 197 Port Number 199 The port number specifies the protocol port number which will 200 be used for the file transfer of the Operating System (e.g 201 tftp=69). 203 IP Protocol 205 The IP protocol field specifies the transport protocol for the 206 file transfer (e.g. UDP=17). 208 2.2 Request for Configuration file 210 This operation MUST take place before any other LCP operation. 212 The slave send a LCP Configure-Request [1] for the type of IP 213 protocol it wish to use. 215 The master MUST reply with a Configure-Ack if the requested 216 protocol is supported, a Configure-Nak if the protocol is not 217 supported or a Terminate-Request if the operation is not 218 possible. Any other message will be ignored. 220 Once the protocol has been agreed, the file transfer can start. 221 The slave MUST remain in charge of the protocol. A specific 222 value is used by the LCP protocol (0xC323) for each datagram of 223 the file transfer. 225 The destination address of the packet sent by the slave MUST be 226 255.255.255.255. The source address of the packet sent by the 227 slave MUST be 127.x.x.x. The master MUST replace destination 228 and source addresses with the address of the file server and 229 its own source address. 231 The name of the file MUST be provided by the master as well as 232 any other � user � information relevant to the file transfer 233 protocol. 235 Once the file transfer is completed, the slave MUST send a 236 Terminate-Request[1]. The master will respond with a Terminate- 237 Ack. 239 The master SHOULD terminated the link when no data have been 240 received from the slave or the file server for 60 seconds 242 A summary of the Request for Configuration file Configuration 243 Option format is shown below. The fields are transmitted from 244 left to right. 246 0 1 2 3 247 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Type | Length | Port Number | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | IP Protocol | 252 +-+-+-+-+-+-+-+-+ 254 Type 256 25 258 Length 260 5 262 Port Number 264 The port number specifies the protocol port number which will 265 be used for the file transfer of the configuration (e.g 266 tftp=69). 268 IP Protocol 270 The IP protocol field specifies the transport protocol for the 271 file transfer (e.g. UDP=17). 273 2.3 Request for Discard frame to be sent 275 The device which need a fast detection of a broken ppp link 276 will send a Configure-Request [1] to its peer requesting to 277 receive Discard frames [1] when no data have to be forwarded. 279 The destination will answer with a Configure-Ack, a Configure- 280 Nak if the timeout is too small or a Configure-Reject if this 281 Option is not possible. 283 Request for Discard frame MUST only be sent in the LCP Opened 284 state. Request for Discard frame received in any state other 285 than the LCP Opened state SHOULD be silently discarded. 287 A summary of the Request for Discard frame Configuration Option 288 format is shown below. The fields are transmitted from left to 289 right. 291 0 1 2 3 292 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type | Length | Timeout | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Frame Size | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Type 301 26 303 Length 305 6 307 Timeout 309 The timeout specifies the time in second after which the link 310 is brought down when no Discard or Data frames are received. 311 The recommended value 2 secondes 313 Frame Size 315 The Frame Size specifies the minimum size of the Discard 316 frame. The recommended value is 64. 318 A summary of the Discard-Request packet format is shown below. 319 The fields are transmitted from left to right. 321 0 1 2 3 322 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Code | S-Identifier | Length | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Magic-Number | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | R-Identifier | Data ... 329 +-+-+-+-+-+-+-+-+-+-+-+ 331 Code 333 11 for Discard-Request. 335 S-Identifier 337 The S-Identifier field is a sequence number which is 338 incremented for each transmitted Discard frame . 340 Length 342 The Length field is two octets, and indicates the length of the 343 LCP packet, including the Code, Identifier, Length and Data 344 fields. The Length MUST NOT exceed the MTU/MRU of the link. The 345 recommended value is 64. 347 Magic-Number 349 The Magic-Number field is four octets, and aids in detecting 350 links which are in the looped-back condition. Until the Magic- 351 Number Configuration Option has been successfully negotiated, 352 the Magic-Number MUST be transmitted as zero. See the Magic- 353 Number Configuration Option [1] for further explanation. 355 R-Identifier 357 The R-Identifier field is a sequence number which is copied 358 from the S-Identifier of incoming Discard frame. 360 Data 362 The Data field contains uninterpreted data for use by the 363 sender. The data may consist of any binary value. The end of 364 the field is indicated by the Length. 366 2.4 Link Bandwidth Measurement 368 When the Input or Output Link Bandwidth cannot be learn by a 369 router, this one use a static value which may or may not be 370 accurate. Routing protocols can used the bandwidth value 371 measured by PPP for their metric. The proposed method is 372 inspired by Novell IPXWAN [2]. 374 To measure the Output bandwidth the device will send several 375 Discard-Request frames and calculate the time between the first 376 and the last bytes of each frame. The device will use the 377 average value converted in bits per second for the Output 378 bandwidth of the link. 380 The device which need to measure the Input bandwidth of the 381 link will send a Configure-Request to its peer requesting to 382 receive several consecutive Discard-Request frames. 384 The destination will answer with a Configure-Ack and then the 385 Discard frames, a Configure-Nak if the frame size is too large 386 or a Configure-Reject is this Option is not possible. 388 The device will be able to measure the Input bandwidth of the 389 link by calculating the time between the first byte and the 390 last byte of each receive frame. The device will use the 391 average value converted in bits per second for the Input 392 bandwidth of the link. 394 A summary of the Link Bandwidth Measurement Configuration 395 Option format is shown below. The fields are transmitted from 396 left to right. 398 0 1 2 3 399 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type | Length | Frame Number | Frame Size 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Frame Size | 404 +-+-+-+-+-+-+-+-+ 406 Type 408 27 410 Length 412 5 414 Frame Number 416 The Frame Number specifies the number of frame the destination 417 must send in a row. The recommended number is 10. 419 Frame Size 421 The Frame Size specifies the total size of the PPP frame use 422 for the Link Bandwidth Measurement. The recommended value is 423 the MTU/MRU of the link (e.g. default = 1500). 425 A summary of the Discard-Request packet format is shown below. 426 The fields are transmitted from left to right. 428 0 1 2 3 429 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Code | Identifier | Length | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Magic-Number | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Data ... 436 +-+-+-+-+ 438 Code 440 11 for Discard-Request. 442 Identifier 444 The Identifier field is a sequence number which is incremented 445 for each Discard frame. The first discard frame sent upon 446 reception of the Link Bandwidth Measurement request has an 447 identifier set to 1. 449 Length 451 The Length field is two octets, and indicates the length of the 452 LCP packet, including the Code, Identifier, Length and Data 453 fields. The Length MUST NOT exceed the MTU/MRU of the link. 455 Magic-Number 457 The Magic-Number field is four octets, and aids in detecting 458 links which are in the looped-back condition. Until the Magic- 459 Number Configuration Option has been successfully negotiated, 460 the Magic-Number MUST be transmitted as zero. See the Magic- 461 Number Configuration Option [1] for further explanation. 463 Data 465 The Data field contains uninterpreted data for use by the 466 sender. The data may consist of any binary value. The end of 467 the field is indicated by the Length. 469 2.5 Link Delay measurement 471 The Link Delay is a significant criteria for routing decision. 472 Routing protocols can used the value measured by PPP for their 473 metric. The proposed method is inspired by Novell IPXWAN [2]. 475 Before NCP negotiation takes place, the link will first measure 476 the bandwidth. The device will then send several consecutive 477 Echo-Request. The destination will reply with Echo-Reply 478 frames. The minimum recommended number of Echo-Request is 10 to 479 have a realistic delay measurement. 481 The recommended value for the frame size is the MTU/MRU of the 482 link (e.g. default = 1500). 484 The device will be able to measure the delay of the link by 485 calculating the round trip time of each individual frame and 486 dividing the result by 2. The device will use the average value 487 as a delay of the link. 489 The calculate result must be readjusted if the link is not a 490 standard point-to-point link (i.e. : link with compression 491 device, ppp multilink, Internet tunnel). Compression can be 492 detected using uninterpreted data and then compressible data. 494 A possible formula is : 496 D = d + (8*MTU/B)((1/n)-1) 498 d = calculated delay 499 B = Bandwidth in bits 500 MTU = Maximum Transmit Unit 501 n = Compression ratio or number of ppp multilink. 503 A summary of the Echo-Request and Echo-Reply packet formats is 504 shown below. The fields are transmitted from left to right. 506 0 1 2 3 507 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Code | Identifier | Length | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Magic-Number | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Data ... 514 +-+-+-+-+ 516 Code 518 9 for Echo-Request; 519 10 for Echo-Reply. 521 Identifier 523 On transmission, the Identifier field MUST be changed whenever 524 the content of the Data field changes, and whenever a valid 525 reply has been received for a previous request. For 526 retransmission, the Identifier MAY remain unchanged. 527 On reception, the Identifier field of the Echo-Request is 528 copied into the Identifier field of the Echo-Reply packet. 530 Length 532 The Length field is two octets, and indicates the length of the 533 LCP packet, including the Code, Identifier, Length and Data 534 fields. The Length MUST NOT exceed the MTU/MRU of the link. 536 Magic-Number 538 The Magic-Number field is four octets, and aids in detecting 539 links which are in the looped-back condition. Until the Magic- 540 Number Configuration Option has been successfully negotiated, 541 the Magic-Number MUST be transmitted as zero. See the Magic- 542 Number Configuration Option [1] for further explanation. 544 Data 546 The Data field contains uninterpreted data for use by the 547 sender. The data may consist of any binary value. The end of 548 the field is indicated by the Length. 550 3 Security Considerations 552 Security issues are not discussed in this document. 554 4 References 556 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 557 RFC 1661, July 1994. 558 [2] Michael Allen, Novell, Inc. Novell IPX Over Various WAN 559 Media (IPXWAN), RFC 1634, May 1994 560 [3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, 561 RFC 1700, October 1994. 562 [4] Simpson, W., PPP Vendor Extensions, RFC 2153, May 1997. 564 5. Acknowledgment 566 The author wish to thank Daniel Senie of Amaranth Networks for 567 his review of the draft. 569 6 Author Information 571 Gerard G. PASSERA 572 Caleje Conseil 573 5, rue Charles LECOCQ 574 75015 PARIS FRANCE 575 Phone: +33 1 48423024 576 EMail: GerardPassera@compuserve.com