One document matched: draft-passera-lcp-misc-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-24 04:15:27 |