idnits 2.17.1 draft-passera-lcp-misc-00.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-26) 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 1) being 588 lines 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 7 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 88: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 92: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 95: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 101: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 103: '...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 9294 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 534, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 537, 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 (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Gerard G. PASSERA 3 Expiration: November 1998 4 File: draft-passera-lcp-misc-00.txt 6 PPP LCP extensions for Initial Program load, 7 Discard received, Link Bandwidth and Link Delay measurement 9 May 26, 1998 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as ``work 22 in progress.'' 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West Coast). 31 Abstract 33 This document presents five extensions to the PPP/LCP Protocol : 35 * Assistance from a router to another router (or a host) looking 36 for its Operating System file. 37 * Assistance from a router to another router (or a host) looking 38 for its configuration file. 39 * Request from an equipment to receive Discard frame when no Data 40 frame can be sent. When no Discard or Data frames are received 41 the link will be brought down. 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 51 2 LCP extensions 4 52 2.1 Request for Operating System file 4 53 2.2 Request for Configuration file 5 54 2.3 Request for Discard frame to be sent 6 55 2.4 Link Bandwidth Measurement 8 56 2.5 Link Delay Measurement 10 58 3 Security Considerations 12 60 4 References 12 62 5 Authors' Information 12 64 1 Introduction 66 There is a need for a router to help another router or a host 67 which is looking for its operating system and/or its 68 configuration. Such mechanisms are already offer on proprietary 69 protocol. 71 Most of the equipment which test the PPP link do it by sending 72 periodically an echo request message. Their hold time is three 73 times the frequency of the hello. It will be faster to detect a 74 broken end to end link if both devices send Discard frame when 75 they have no data to send. 77 OSPF and some other proprietary routing protocol base their 78 routing decision on the value of the bandwidth. The most 79 important factor is in fact the delay. This information is not 80 easy to find. PPP/LCP could help the administrator. 82 1.1. Specification of Requirements 84 In this document, several words are used to signify the 85 requirements of the specification. These words are often 86 capitalized. 88 MUST This word, or the adjective "required", means that the 89 definition is an absolute requirement of the 90 specification. 92 MUST NOT This phrase means that the definition is an absolute 93 prohibition of the specification. 95 SHOULD This word, or the adjective "recommended", means that 96 there may exist valid reasons in particular 97 circumstances to ignore this item, but the full 98 implications must be understood and carefully weighed 99 before choosing a different course. 101 MAY This word, or the adjective "optional", means that this 102 item is one of an allowed set of alternatives. An 103 implementation which does not include this option MUST 104 be prepared to interoperate with another implementation 105 which does include the option. 107 1.2. Terminology 109 This document frequently uses the following terms: 111 datagram The unit of transmission in the network layer (such as 112 IP). A datagram may be encapsulated in one or more 113 packets passed to the data link layer. 115 frame The unit of transmission at the data link layer. A 116 frame may include a header and/or a trailer, along with 117 some number of units of data. 119 packet The basic unit of encapsulation, which is passed across 120 the interface between the network layer and the data 121 link layer. A packet is usually mapped to a frame; the 122 exceptions are when data link layer fragmentation is 123 being performed, or when multiple packets are 124 incorporated into a single frame. 126 peer The other end of the point-to-point link. 128 silently discard 129 The implementation discards the packet without further 130 processing. The implementation SHOULD provide the 131 capability of logging the error, including the contents 132 of the silently discarded packet, and SHOULD record the 133 event in a statistics counter. 135 master 136 The peer offering its assistance 138 slave 139 The peer requesting its operating system and/or its 140 configuration files. 142 2 LCP Extensions 144 2.1 Request for Operating System file 146 This operation MUST take place before any other LCP operation. 148 The slave send a LCP Configure-Request [1] for the type of IP 149 protocol it wish to use. 151 The master MUST reply with a Configure-Ack if the requested 152 protocol is supported, a Configure-Nak if the protocol is not 153 supported or a Terminate-Request if the operation is not 154 possible. Any other message will be ignored. 156 Once the protocol has been negociated, the file transfer can 157 start. The slave MUST remain in charge of the protocol. A 158 specific value is used by the Request for Operating System file 159 protocol (0xC321) for each datagram of the file transfer. 161 The destination address of the IP packet sent by the slave MUST 162 be 255.255.255.255. The source address of the IP packet sent by 163 the slave MUST be 127.x.x.x. The master MUST replace 164 destination and source addresses with the address of the file 165 server and its own source address. 167 The name of the requested file MUST be provided by the slave. 168 Any other � user � information relevant to the file transfer 169 protocol MUST be provided by the master. 171 Once the file transfer is completed, the slave MUST send a 172 Terminate-Request [1]. The master will respond with a 173 Terminate-Ack. 175 The master SHOULD terminated the link when no data have been 176 received from the slave or the file server for 60 seconds 178 A summary of the Request for Operating System file 179 Configuration Option format is shown below. The fields are 180 transmitted from left to right. 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type | Length | Port Number | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | IP Protocol | 188 +-+-+-+-+-+-+-+-+ 190 Type 192 24 194 Length 196 5 198 Port Number 200 The port number specifies the protocol port number which will 201 be used for the file transfer of the Operating System (e.g 202 tftp=69). 204 IP Protocol 206 The IP protocol field specifies the transport protocol for the 207 file transfer (e.g. UDP=17). 209 2.2 Request for Configuration file 211 This operation MUST take place before any other LCP operation. 213 The slave send a LCP Configure-Request [1] for the type of IP 214 protocol it wish to use. 216 The master MUST reply with a Configure-Ack if the requested 217 protocol is supported, a Configure-Nak if the protocol is not 218 supported or a Terminate-Request if the operation is not 219 possible. Any other message will be ignored. 221 Once the protocol has been agreed, the file transfer can start. 222 The slave MUST remain in charge of the protocol. A specific 223 value is used by the LCP protocol (0xC323) for each datagram of 224 the file transfer. 226 The destination address of the packet sent by the slave MUST be 227 255.255.255.255. The source address of the packet sent by the 228 slave MUST be 127.x.x.x. The master MUST replace destination 229 and source addresses with the address of the file server and 230 its own source address. 232 The name of the file MUST be provided by the master as well as 233 any other � user � information relevant to the file transfer 234 protocol. 236 Once the file transfer is completed, the slave MUST send a 237 Terminate-Request[1]. The master will respond with a Terminate- 238 Ack. 240 The master SHOULD terminated the link when no data have been 241 received from the slave or the file server for 60 seconds 243 A summary of the Request for Configuration file Configuration 244 Option format is shown below. The fields are transmitted from 245 left to right. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type | Length | Port Number | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | IP Protocol | 253 +-+-+-+-+-+-+-+-+ 255 Type 257 25 259 Length 261 5 263 Port Number 265 The port number specifies the protocol port number which will 266 be used for the file transfer of the configuration (e.g 267 tftp=69). 269 IP Protocol 271 The IP protocol field specifies the transport protocol for the 272 file transfer (e.g. UDP=17). 274 2.3 Request for Discard frame to be sent 276 The device which need a fast detection of a broken ppp link 277 will send a Configure-Request [1] to its peer requesting to 278 receive Discard frames [1] when no data have to be forwarded. 280 The destination will answer with a Configure-Ack, a Configure- 281 Nak if the timeout is too small or a Configure-Reject if this 282 Option is not possible. 284 Request for Discard frame MUST only be sent in the LCP Opened 285 state. Request for Discard frame received in any state other 286 than the LCP Opened state SHOULD be silently discarded. 288 A summary of the Request for Discard frame Configuration Option 289 format is shown below. The fields are transmitted from left to 290 right. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | Timeout | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Frame Size | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Type 302 26 304 Length 306 6 308 Timeout 310 The timeout specifies the time in second after which the link 311 is brought down when no Discard or Data frames are received. 312 The recommended value 5 secondes 314 Frame Size 316 The Frame Size specifies the minimum size of the Discard 317 frame. The recommended value is 64. 319 A summary of the Discard-Request packet format is shown below. 320 The fields are transmitted from left to right. 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Code | Identifier | Length | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Magic-Number | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Data ... 330 +-+-+-+-+ 332 Code 334 11 for Discard-Request. 336 Identifier 338 The Identifier field is a sequence number which is incremented 339 for each Discard frame. 341 Length 343 The Length field is two octets, and indicates the length of the 344 LCP packet, including the Code, Identifier, Length and Data 345 fields. The Length MUST NOT exceed the MRU of the link. The 346 recommended value is 64. 348 Magic-Number 350 The Magic-Number field is four octets, and aids in detecting 351 links which are in the looped-back condition. Until the Magic- 352 Number Configuration Option has been successfully negotiated, 353 the Magic-Number MUST be transmitted as zero. See the Magic- 354 Number Configuration Option [1] for further explanation. 356 Data 358 The Data field contains uninterpreted data for use by the 359 sender. The data may consist of any binary value. The end of 360 the field is indicated by the Length. 362 2.4 Link Bandwidth Measurement 364 When the Link Bandwidth cannot be learn by a router, this one 365 use a static value which may or may not be accurated. Routing 366 protocols can used the bandwidth value measured by PPP for 367 their metric. The proposed method is inspired by Novell IPXWAN 368 [2]. 370 The device which need to measure the bandwidth of the link will 371 send a Configure-Request to its peer requesting to receive some 372 Discard frames. 374 The destination will answer with a Configure-Ack and then the 375 Discard frames, a Configure-Nak if the frame size is too large 376 or a Configure-Reject is this Option is not possible. 378 The device will be able to measure the bandwidth of the link by 379 calculating the time necessary to receive the requested number 380 of bytes. 382 A summary of the Link Bandwidth Measurement Configuration 383 Option format is shown below. The fields are transmitted from 384 left to right. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type | Length | Frame Number | Frame Size 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Frame Size | 392 +-+-+-+-+-+-+-+-+ 394 Type 396 27 398 Length 400 5 402 Frame Number 404 The Frame Number specifies the number of frame the destination 405 must send in a row. The recommended number is 2. 407 Frame Size 409 The Frame Size specifies the total size of the PPP frame use 410 for the Link Bandwidth Measurement. The recommended value is 411 the MRU of the link (e.g. default = 1500). 413 A summary of the Discard-Request packet format is shown below. The 414 fields are transmitted from left to right. 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Code | Identifier | Length | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Magic-Number | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Data ... 424 +-+-+-+-+ 426 Code 428 11 for Discard-Request. 430 Identifier 432 The Identifier field is a sequence number which is incremented 433 for each Discard frame. The first discard frame sent upon 434 reception of the Link Bandwidth Measurement request has an 435 identifier set to 1. 437 Length 439 The Length field is two octets, and indicates the length of the 440 LCP packet, including the Code, Identifier, Length and Data 441 fields. The Length MUST NOT exceed the MRU of the link. 443 Magic-Number 445 The Magic-Number field is four octets, and aids in detecting 446 links which are in the looped-back condition. Until the Magic- 447 Number Configuration Option has been successfully negotiated, 448 the Magic-Number MUST be transmitted as zero. See the Magic- 449 Number Configuration Option [1] for further explanation. 451 Data 453 The Data field contains uninterpreted data for use by the 454 sender. The data may consist of any binary value. The end of 455 the field is indicated by the Length. 457 2.5 Link Delay measurement 459 The Link Delay is a significant criteria for routing decision. 460 Routing protocols can used the value measured by PPP for their 461 metric. The proposed method is inspired by Novell IPXWAN [2]. 463 Before NCP negotiation takes place, the link will first measure 464 the bandwidth. The device will then send several consecutive 465 Echo-Request. The destination will reply with Echo-Reply 466 frames. The recommended number of Echo-Request is 2. 468 The device will be able to measure the delay of the link by 469 calculating the round trip time of individual frame and 470 dividing the result by 2. 472 The recommended value for the frame size is the MRU of the link 473 (e.g. default = 1500). 475 A summary of the Echo-Request and Echo-Reply packet formats is 476 shown below. The fields are transmitted from left to right. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Code | Identifier | Length | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Magic-Number | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Data ... 486 +-+-+-+-+ 488 Code 490 9 for Echo-Request; 491 10 for Echo-Reply. 493 Identifier 495 On transmission, the Identifier field MUST be changed whenever 496 the content of the Data field changes, and whenever a valid 497 reply has been received for a previous request. For 498 retransmission, the Identifier MAY remain unchanged. 499 On reception, the Identifier field of the Echo-Request is 500 copied into the Identifier field of the Echo-Reply packet. 502 Length 504 The Length field is two octets, and indicates the length of the 505 LCP packet, including the Code, Identifier, Length and Data 506 fields. The Length MUST NOT exceed the MRU of the link. 508 Magic-Number 510 The Magic-Number field is four octets, and aids in detecting 511 links which are in the looped-back condition. Until the Magic- 512 Number Configuration Option has been successfully negotiated, 513 the Magic-Number MUST be transmitted as zero. See the Magic- 514 Number Configuration Option [1] for further explanation. 516 Data 518 The Data field contains uninterpreted data for use by the 519 sender. The data may consist of any binary value. The end of 520 the field is indicated by the Length. 522 3 Security Considerations 524 Security issues are not discussed in this document. 526 4 References 528 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 529 RFC 1661, July 1994. 531 [2] Michael Allen, Novell, Inc. Novell IPX Over Various WAN 532 Media (IPXWAN), RFC 1634, May 1994 534 [3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, 535 RFC 1700, October 1994. 537 [4] Simpson, W., PPP Vendor Extensions, RFC 2153, May 1997. 539 5 Author Information 541 Gerard G. PASSERA 542 Caleje Conseil 543 5, rue Charles LECOCQ 544 75015 PARIS FRANCE 545 Phone: +33 1 48423024 546 EMail: GerardPassera@compuserve.com