Internet Draft Gerard G. PASSERA
Expiration: November 1998
File: draft-passera-lcp-misc-01.txt
PPP LCP extensions for Initial Program load,
Discard received, Link Bandwidth and Link Delay measurements
June 25, 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. This method is more efficient
than using a timeout and/or a keepalive mecanism.
* 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 Acknowledgment 12
6 Authors' Information 13
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 offered on proprietary
link protocol with TFTP. More performing protocols should be
allowed on PPP which will then be able to replace all point-to-
point protocols.
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 negotiated, 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 2 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 | S-Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R-Identifier | Data ...
+-+-+-+-+-+-+-+-+-+-+-+
Code
11 for Discard-Request.
S-Identifier
The S-Identifier field is a sequence number which is
incremented for each transmitted 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 MTU/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.
R-Identifier
The R-Identifier field is a sequence number which is copied
from the S-Identifier of incoming Discard frame.
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 Input or Output Link Bandwidth cannot be learn by a
router, this one use a static value which may or may not be
accurate. Routing protocols can used the bandwidth value
measured by PPP for their metric. The proposed method is
inspired by Novell IPXWAN [2].
To measure the Output bandwidth the device will send several
Discard-Request frames and calculate the time between the first
and the last bytes of each frame. The device will use the
average value converted in bits per second for the Output
bandwidth of the link.
The device which need to measure the Input bandwidth of the
link will send a Configure-Request to its peer requesting to
receive several consecutive Discard-Request 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 Input bandwidth of the
link by calculating the time between the first byte and the
last byte of each receive frame. The device will use the
average value converted in bits per second for the Input
bandwidth of the link.
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 10.
Frame Size
The Frame Size specifies the total size of the PPP frame use
for the Link Bandwidth Measurement. The recommended value is
the MTU/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 MTU/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 minimum recommended number of Echo-Request is 10 to
have a realistic delay measurement.
The recommended value for the frame size is the MTU/MRU of the
link (e.g. default = 1500).
The device will be able to measure the delay of the link by
calculating the round trip time of each individual frame and
dividing the result by 2. The device will use the average value
as a delay of the link.
The calculate result must be readjusted if the link is not a
standard point-to-point link (i.e. : link with compression
device, ppp multilink, Internet tunnel). Compression can be
detected using uninterpreted data and then compressible data.
A possible formula is :
D = d + (8*MTU/B)((1/n)-1)
d = calculated delay
B = Bandwidth in bits
MTU = Maximum Transmit Unit
n = Compression ratio or number of ppp multilink.
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 MTU/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. Acknowledgment
The author wish to thank Daniel Senie of Amaranth Networks for
his review of the draft.
6 Author Information
Gerard G. PASSERA
Caleje Conseil
5, rue Charles LECOCQ
75015 PARIS FRANCE
Phone: +33 1 48423024
EMail: GerardPassera@compuserve.com
Internet Draft PPP LCP Extentions April 25, 1998
PASSERA Expires November, 1998 [Page 13]