Internet Draft Gerard G. PASSERA Expiration: November 1998 File: draft-passera-lcp-misc-00.txt PPP LCP extensions for Initial Program load, Discard received, Link Bandwidth and Link Delay measurement May 26, 1998 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document presents five extensions to the PPP/LCP Protocol : * Assistance from a router to another router (or a host) looking for its Operating System file. * Assistance from a router to another router (or a host) looking for its configuration file. * Request from an equipment to receive Discard frame when no Data frame can be sent. When no Discard or Data frames are received the link will be brought down. * Interface Bandwidth and Delay measurements. These informations can be used by OSPF or any other IGP protocol. Table of Contents 1 Introduction 2 1. 1 Specification of Requirements 2 1.2 Terminology 3 2 LCP extensions 4 2.1 Request for Operating System file 4 2.2 Request for Configuration file 5 2.3 Request for Discard frame to be sent 6 2.4 Link Bandwidth Measurement 8 2.5 Link Delay Measurement 10 3 Security Considerations 12 4 References 12 5 Authors' Information 12 1 Introduction There is a need for a router to help another router or a host which is looking for its operating system and/or its configuration. Such mechanisms are already offer on proprietary protocol. Most of the equipment which test the PPP link do it by sending periodically an echo request message. Their hold time is three times the frequency of the hello. It will be faster to detect a broken end to end link if both devices send Discard frame when they have no data to send. OSPF and some other proprietary routing protocol base their routing decision on the value of the bandwidth. The most important factor is in fact the delay. This information is not easy to find. PPP/LCP could help the administrator. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 1.2. Terminology This document frequently uses the following terms: datagram The unit of transmission in the network layer (such as IP). A datagram may be encapsulated in one or more packets passed to the data link layer. frame The unit of transmission at the data link layer. A frame may include a header and/or a trailer, along with some number of units of data. packet The basic unit of encapsulation, which is passed across the interface between the network layer and the data link layer. A packet is usually mapped to a frame; the exceptions are when data link layer fragmentation is being performed, or when multiple packets are incorporated into a single frame. peer The other end of the point-to-point link. silently discard The implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. master The peer offering its assistance slave The peer requesting its operating system and/or its configuration files. 2 LCP Extensions 2.1 Request for Operating System file This operation MUST take place before any other LCP operation. The slave send a LCP Configure-Request [1] for the type of IP protocol it wish to use. The master MUST reply with a Configure-Ack if the requested protocol is supported, a Configure-Nak if the protocol is not supported or a Terminate-Request if the operation is not possible. Any other message will be ignored. Once the protocol has been negociated, the file transfer can start. The slave MUST remain in charge of the protocol. A specific value is used by the Request for Operating System file protocol (0xC321) for each datagram of the file transfer. The destination address of the IP packet sent by the slave MUST be 255.255.255.255. The source address of the IP packet sent by the slave MUST be 127.x.x.x. The master MUST replace destination and source addresses with the address of the file server and its own source address. The name of the requested file MUST be provided by the slave. Any other ® user ¯ information relevant to the file transfer protocol MUST be provided by the master. Once the file transfer is completed, the slave MUST send a Terminate-Request [1]. The master will respond with a Terminate-Ack. The master SHOULD terminated the link when no data have been received from the slave or the file server for 60 seconds A summary of the Request for Operating System file Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Protocol | +-+-+-+-+-+-+-+-+ Type 24 Length 5 Port Number The port number specifies the protocol port number which will be used for the file transfer of the Operating System (e.g tftp=69). IP Protocol The IP protocol field specifies the transport protocol for the file transfer (e.g. UDP=17). 2.2 Request for Configuration file This operation MUST take place before any other LCP operation. The slave send a LCP Configure-Request [1] for the type of IP protocol it wish to use. The master MUST reply with a Configure-Ack if the requested protocol is supported, a Configure-Nak if the protocol is not supported or a Terminate-Request if the operation is not possible. Any other message will be ignored. Once the protocol has been agreed, the file transfer can start. The slave MUST remain in charge of the protocol. A specific value is used by the LCP protocol (0xC323) for each datagram of the file transfer. The destination address of the packet sent by the slave MUST be 255.255.255.255. The source address of the packet sent by the slave MUST be 127.x.x.x. The master MUST replace destination and source addresses with the address of the file server and its own source address. The name of the file MUST be provided by the master as well as any other ® user ¯ information relevant to the file transfer protocol. Once the file transfer is completed, the slave MUST send a Terminate-Request[1]. The master will respond with a Terminate- Ack. The master SHOULD terminated the link when no data have been received from the slave or the file server for 60 seconds A summary of the Request for Configuration file Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Protocol | +-+-+-+-+-+-+-+-+ Type 25 Length 5 Port Number The port number specifies the protocol port number which will be used for the file transfer of the configuration (e.g tftp=69). IP Protocol The IP protocol field specifies the transport protocol for the file transfer (e.g. UDP=17). 2.3 Request for Discard frame to be sent The device which need a fast detection of a broken ppp link will send a Configure-Request [1] to its peer requesting to receive Discard frames [1] when no data have to be forwarded. The destination will answer with a Configure-Ack, a Configure- Nak if the timeout is too small or a Configure-Reject if this Option is not possible. Request for Discard frame MUST only be sent in the LCP Opened state. Request for Discard frame received in any state other than the LCP Opened state SHOULD be silently discarded. A summary of the Request for Discard frame Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Timeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 26 Length 6 Timeout The timeout specifies the time in second after which the link is brought down when no Discard or Data frames are received. The recommended value 5 secondes Frame Size The Frame Size specifies the minimum size of the Discard frame. The recommended value is 64. A summary of the Discard-Request packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic-Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code 11 for Discard-Request. Identifier The Identifier field is a sequence number which is incremented for each Discard frame. Length The Length field is two octets, and indicates the length of the LCP packet, including the Code, Identifier, Length and Data fields. The Length MUST NOT exceed the MRU of the link. The recommended value is 64. Magic-Number The Magic-Number field is four octets, and aids in detecting links which are in the looped-back condition. Until the Magic- Number Configuration Option has been successfully negotiated, the Magic-Number MUST be transmitted as zero. See the Magic- Number Configuration Option [1] for further explanation. Data The Data field contains uninterpreted data for use by the sender. The data may consist of any binary value. The end of the field is indicated by the Length. 2.4 Link Bandwidth Measurement When the Link Bandwidth cannot be learn by a router, this one use a static value which may or may not be accurated. Routing protocols can used the bandwidth value measured by PPP for their metric. The proposed method is inspired by Novell IPXWAN [2]. The device which need to measure the bandwidth of the link will send a Configure-Request to its peer requesting to receive some Discard frames. The destination will answer with a Configure-Ack and then the Discard frames, a Configure-Nak if the frame size is too large or a Configure-Reject is this Option is not possible. The device will be able to measure the bandwidth of the link by calculating the time necessary to receive the requested number of bytes. A summary of the Link Bandwidth Measurement Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Frame Number | Frame Size +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Frame Size | +-+-+-+-+-+-+-+-+ Type 27 Length 5 Frame Number The Frame Number specifies the number of frame the destination must send in a row. The recommended number is 2. Frame Size The Frame Size specifies the total size of the PPP frame use for the Link Bandwidth Measurement. The recommended value is the MRU of the link (e.g. default = 1500). A summary of the Discard-Request packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic-Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code 11 for Discard-Request. Identifier The Identifier field is a sequence number which is incremented for each Discard frame. The first discard frame sent upon reception of the Link Bandwidth Measurement request has an identifier set to 1. Length The Length field is two octets, and indicates the length of the LCP packet, including the Code, Identifier, Length and Data fields. The Length MUST NOT exceed the MRU of the link. Magic-Number The Magic-Number field is four octets, and aids in detecting links which are in the looped-back condition. Until the Magic- Number Configuration Option has been successfully negotiated, the Magic-Number MUST be transmitted as zero. See the Magic- Number Configuration Option [1] for further explanation. Data The Data field contains uninterpreted data for use by the sender. The data may consist of any binary value. The end of the field is indicated by the Length. 2.5 Link Delay measurement The Link Delay is a significant criteria for routing decision. Routing protocols can used the value measured by PPP for their metric. The proposed method is inspired by Novell IPXWAN [2]. Before NCP negotiation takes place, the link will first measure the bandwidth. The device will then send several consecutive Echo-Request. The destination will reply with Echo-Reply frames. The recommended number of Echo-Request is 2. The device will be able to measure the delay of the link by calculating the round trip time of individual frame and dividing the result by 2. The recommended value for the frame size is the MRU of the link (e.g. default = 1500). A summary of the Echo-Request and Echo-Reply packet formats is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic-Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code 9 for Echo-Request; 10 for Echo-Reply. Identifier On transmission, the Identifier field MUST be changed whenever the content of the Data field changes, and whenever a valid reply has been received for a previous request. For retransmission, the Identifier MAY remain unchanged. On reception, the Identifier field of the Echo-Request is copied into the Identifier field of the Echo-Reply packet. Length The Length field is two octets, and indicates the length of the LCP packet, including the Code, Identifier, Length and Data fields. The Length MUST NOT exceed the MRU of the link. Magic-Number The Magic-Number field is four octets, and aids in detecting links which are in the looped-back condition. Until the Magic- Number Configuration Option has been successfully negotiated, the Magic-Number MUST be transmitted as zero. See the Magic- Number Configuration Option [1] for further explanation. Data The Data field contains uninterpreted data for use by the sender. The data may consist of any binary value. The end of the field is indicated by the Length. 3 Security Considerations Security issues are not discussed in this document. 4 References [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [2] Michael Allen, Novell, Inc. Novell IPX Over Various WAN Media (IPXWAN), RFC 1634, May 1994 [3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. [4] Simpson, W., PPP Vendor Extensions, RFC 2153, May 1997. 5 Author Information Gerard G. PASSERA Caleje Conseil 5, rue Charles LECOCQ 75015 PARIS FRANCE Phone: +33 1 48423024 EMail: GerardPassera@compuserve.com