As per Relevance of the word information, we have this rfc below:
Network Working Group D.
Request for Comments: 1377
November 1992
The PPP OSI Network Layer Control Protocol (OSINLCP
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
The Point-to-Point Protocol (PPP) [1] provides a standard method
encapsulating Network Layer protocol information over point-to-
links. PPP also defines an extensible Link Control Protocol,
proposes a family of Network Control Protocols (NCPs)
establishing and configuring different network-layer protocols
This document defines the NCP for establishing and configuring
Network Layer Protocols
This memo is the product of the Point-to-Point Protocol Working
of the Internet Engineering Task Force (IETF). Comments on this
should be submitted to the ietf-ppp@ucdavis.edu mailing list
Table of
1. Introduction .......................................... 2
1.1 OSI Network Layer Protocols over PPP .................. 2
2. A PPP Network Control Protocol (NCP) for OSI .......... 5
2.1 Sending OSI NPDUs ..................................... 6
2.2 NPDU Alignment ........................................ 6
2.3 Network Layer Addressing Information .................. 6
3. OSINLCP Configuration Options ......................... 7
3.1 Align-NPDU ............................................ 7
REFERENCES ................................................... 9
ACKNOWLEDGEMENTS ............................................. 9
SECURITY CONSIDERATIONS ...................................... 10
CHAIR'S ADDRESS .............................................. 10
AUTHOR'S ADDRESS ............................................. 10
Katz [Page 1]
RFC 1377 PPP OSINLCP November 1992
1.
PPP has three main components
1. A method for encapsulating datagrams over serial links
2. A Link Control Protocol (LCP) for establishing, configuring
and testing the data-link connection
3. A family of Network Control Protocols (NCPs) for
and configuring different network-layer protocols
In order to establish communications over a point-to-point link,
end of the PPP link must first send LCP packets to configure and
the data link. After the link has been established and
facilities have been negotiated as needed by the LCP, PPP must
NCP packets to choose and configure one or more network-
protocols. Once each of the chosen network-layer protocols has
configured, datagrams from each network-layer protocol can be
over the link
The link will remain configured for communications until explicit
or NCP packets close the link down, or until some external
occurs (an inactivity timer expires or network
intervention).
1.1. OSI Network Layer Protocols over
A number of protocols have been defined for the Network Layer of OSI
including the Connectionless Network Layer Protocol (CLNP, ISO 8473)
[3], the End System to Intermediate System routing protocol (ES-IS
ISO 9542) [4], the Intermediate System to Intermediate System
protocol (IS-IS, ISO 10589) [5], and the Inter-Domain
Protocol (IDRP, CD 10747) [6]. Generally, these protocols
designed to run over non-reliable data link protocols such as PPP
Network Layer Protocol Identifier (NLPID
OSI Network Layer protocols can be discriminated according to
first octet in each Network Protocol Data Unit (NPDU, that is
packet), known as the Network Layer Protocol Identifier (NLPID),
which is defined in ISO/TR 9577 [7]. This allows the
protocols to be run over a common data link without
discriminator below the network layer
Katz [Page 2]
RFC 1377 PPP OSINLCP November 1992
Inactive Network Layer
ISO/TR 9577 reserves a NLPID value of zero to represent
"Inactive Network Layer Protocol", as defined in ISO 8473.
inactive network layer protocol MUST NOT be used over PPP.
assures that whichever OSI network layer protocol is used
have a non-zero NLPID value
Connection-Oriented Network
The OSI Connection-Oriented Network Protocol (ISO 8208) [8],
effectively the Packet Layer of CCITT X.25, is intended to be
over a reliable data link, such as IEEE 802.2 type II or LAPB
Therefore, the unreliable data link service provided by PPP is
appropriate for use with ISO 8208.
ConnectionLess Network Protocol (CLNP
The ConnectionLess Network Protocol offers a simple non-
datagram service very similar to IP, and is designed to run over
non-reliable data link service, such as provided by PPP
End-System to Intermediate-System Protocol (ES-IS
ES Hellos and IS Hellos are retransmitted on a periodic timer
driven basis (based on expiration of the "Configuration Timer").
The resulting ES and IS configuration information is
on a timer driven basis, based on expiration of the "
Timer" for each piece of information. The value of a
Timer is set by the source of the information, and transmitted
the Holding Time field of the appropriate ES-IS packet. ISO 9542
recommends that the holding time field is set to
twice the Configuration Timer parameter, such that even if
other Hello packet is lost the configuration information will
retained (implying that the Holding Timer is actually set
slightly more than twice the Configuration Timer).
Generally, the recommendation in ISO 9542 is sufficient for
links. For very unreliable links, it may be necessary to set
Holding Timer to be slightly more than three times
Configuration Timer to ensure that loss of
information is an unusual event
Redirect information is not transmitted on point-to-point links
but may be transmitted on general topology subnetworks, which
turn may make use of PPP. Redirect information is sent on
event-driven basis (based on a CLNP packet being forwarded by
router out the incoming interface), but redirect information
Katz [Page 3]
RFC 1377 PPP OSINLCP November 1992
invalidated on a timer-driven basis. Loss of a single
may result in a subsequent data packet being sent to the
incorrect router, which will re-issue the redirect. This
in the same manner as ICMP redirects for IP packets, and does
pose any problem for operation over PPP links
Intermediate-System to Intermediate-System Protocol (IS-IS
IS-IS allows for broadcast links (typically LANs), point-to-
links (such as PPP), and general topology links (such as X.25
networks) which are modelled as a collection of point-to-
links
There are four types of IS-IS packets: IS-IS Hello Packets,
State Packets (LSPs), Complete Sequence Number Packets (CSNPs),
and Partial Sequence Number Packets (PSNPs).
IS-IS Hello messages are transmitted periodically on point-to
point links (based on expiration of the "ISISHello" timer).
Routers expect to receive IS-IS Hello packets periodically
Specifically, the IS-IS Hello packet specifies a "Holding Time".
If no subsequent IS-IS Hello is received over the
link for the specified time period, then the neighboring router
assumed to have been disconnected or to be down. It is
undesireable for links to "flap" up and down unnecessarily,
implies that the holding time needs to be large enough that a
is very unlikely to be declared down due to a failure to
an IS-IS Hello. This implies that running IS-IS over
data links requires the Holding time to be greater than "k"
the ISISHello timer, where k is chosen such that the loss of
consecutive IS-IS Hello's is rare. If the quality of the link
poor, then the Holding Time will need to be increased or
"ISISHello" time decreased
LSPs are acknowledged by the IS-IS protocol (via use of
sequence number packets). A lost LSP will be recovered from
no problem provided that PPP links are treated the same way
other point-to-point links. On those rare occasions where
partial sequence number packet is lost, this might result in
retransmission of a link state packet over a single link, but
not impact the correct operation of the routing algorithm
CSNPs are sent upon link startup on a point-to-point link.
does not need to be changed for PPP. If a CSNP fragment is
upon startup it is merely loss of an optimization -- LSPs that
not need to be transmitted over the link will be transmitted.
a periodic CSNP fragment is lost it merely means that detection
low probability database corruption will take longer
Katz [Page 4]
RFC 1377 PPP OSINLCP November 1992
PSNPs function as ACKs. Loss of a PSNP may result in
unnecessary retransmission of an LSP, but does not prevent
operation of the routing protocol
Inter-Domain Routeing Protocol (IDRP
IDRP expects to run over datagram links, but requires
exchange of IDRP information. For this reason, IDRP
built-in reliability mechanisms which ensure that packets will
received correctly
2. A PPP Network Control Protocol (NCP) for
The OSI Network Layer Control Protocol (OSINLCP) is responsible
configuring, enabling, and disabling the OSI protocol modules on
ends of the point-to-point link. OSINLCP uses the same
exchange machanism as the Link Control Protocol (LCP).
packets may not be exchanged until PPP has reached the Network-
Protocol phase. OSINLCP packets received before this phase
reached should be silently discarded
The OSI Network Layer Control Protocol is exactly the same as
Link Control Protocol [1] with the following exceptions
Frame
The packet may utilize any modifications to the basic frame
which have been negotiated during the Link Establishment phase
Data Link Layer Protocol
Exactly one OSINLCP packet is encapsulated in the
field of a PPP Data Link Layer frame where the Protocol
indicates type hex 8023 (OSI Network Layer Control Protocol).
Code
Only Codes 1 through 7 (Configure-Request, Configure-Ack
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-
and Code-Reject) are used. Other Codes should be treated
unrecognized and should result in Code-Rejects
OSINLCP packets may not be exchanged until PPP has reached
Network-Layer Protocol phase. An implementation should
prepared to wait for Authentication and Link Quality
to finish before timing out waiting for a Configure-Ack or
Katz [Page 5]
RFC 1377 PPP OSINLCP November 1992
response. It is suggested that an implementation give up
after user intervention or a configurable amount of time
Configuration Option
OSINLCP has one Configuration Option, which is defined below
2.1. Sending OSI
Before any Network Protocol Data Units (NPDUs) may be communicated
PPP must reach the Network-Layer Protocol phase, and the OSI
Layer Control Protocol must reach the Opened state
Exactly one OSI NPDU is encapsulated in the Information field of
PPP Data Link Layer frame where the Protocol field indicates type
0023 (OSI Network Layer).
The maximum length of an OSI NPDU transmitted over a PPP link is
same as the maximum length of the Information field of a PPP
link layer frame. Larger NPDUs must be segmented as necessary. If
system wishes to avoid segmentation and reassembly, it should
transport layer mechanisms to discourage others from sending
PDUs
2.2. NPDU
OSI protocols have peculiar alignment problems due to the fact
they are often encapsulated in data link protocols with odd-
headers, while PPP defaults to even-length headers. A
switching an OSI packet may find that the beginning of the
falls on an inconvenient memory boundary when the hardware used
transmit the packet to its next hop requires a particular alignment
This situation can be addressed by the use of leading zero padding
When sending, an implementation MAY insert one to three octets
zero between the PPP header and the OSI NPDU. These zero
correspondingly reduce the maximum length of the NPDU that may
transmitted
On reception, any such leading zero octets (if present) MUST
removed. Regardless of whether leading zero padding is used,
implementation MUST also be able to receive a PPP packet with
arbitrary alignment of the NPDU
2.3. Network Layer Addressing
OSINLCP does not define a separate configuration option for
exchange of OSI Network Layer address information. Instead, the ES
Katz [Page 6]
RFC 1377 PPP OSINLCP November 1992
IS protocol, ISO 9542, should be used. This protocol provides
mechanism for determining the Network Layer address(es) of
neighbor on the link, as well as determining if the neighbor is
End System or an Intermediate System
A draft addendum to ES-IS [9] is being defined in ISO to add
for dynamic address assignment. This addendum has currently
the formal "Committee Draft" (CD) letter ballot
3. OSINLCP Configuration
OSINLCP Configuration Options allow negotiatiation of
Internet Protocol parameters. OSINLCP uses the same
Option format defined for LCP [1], with a separate set of Options
The most up-to-date values of the OSINLCP Option Type field
specified in the most recent "Assigned Numbers" RFC [2].
values are assigned as follows
1 Align-
3.1. Align-
This Configuration Option provides a way for the receiver
negotiate a particular alignment of the OSI NPDU.
evidence suggests that the greatest time deficit for re-
exists at the receiver
The alignment is accomplished through combination of PPP
compression with leading zero padding (see above). It
recommended that alignment be entirely through header
combinations whenever possible. For example, an alignment of 3
could be achieved by combining uncompressed PPP Address
Control fields (2 octets) with a compressed PPP Protocol field (1
octet).
This option is negotiated separately in each direction.
receiver which does not need alignment MUST NOT request
option. A sender which desires alignment prior to sending
Configure-Nak with an appropriate value
Implementation Note: In a complex environment, there might
several conflicting needs for alignment. It is
that the receiver request alignment based on the needs of
highest speed next hop link. Also, greater efficiency might
obtained by negotiating upstream the values requested
Katz [Page 7]
RFC 1377 PPP OSINLCP November 1992
downstream PPP links, since those packets will not need
change in alignment on transit
The alignment request is advisory, and failure to agree on
alignment MUST NOT prevent the OSINLCP from reaching the
state. By default, the alignment is done according to the
of the sender, and all receivers MUST be capable of
packets with any alignment
Vernacular: If you don't like this option, you can refuse
negotiate it, and you can send whatever alignment you want
However, if you accept the peer's alignment option, then
MUST transmit packets with the agreed alignment
A summary of the Align-NPDU Configuration Option format is
below. The fields are transmitted from left to right
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Alignment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
3
This field specifies the offset of the beginning of the OSI
relative to the beginning of the PPP packet header (not
any leading Flag Sequences).
A value of 1 through 4 requires an offset of that specific length
modulo 4. For example, a value of 1 would require no padding
the PPP Address, Control, and Protocol fields are compressed.
octet of leading zero padding would be necessary when the
header is full sized
A value of 255 requests an offset of an odd length (1 or 3).
value of 254 requests an offset of an even length (2 or 4).
the sender is not capable of dynamically varying the amount
padding, it MUST NAK with one of the two specific values
Katz [Page 8]
RFC 1377 PPP OSINLCP November 1992
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
Daydreamer, May 1992.
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[3] ISO, "Information processing systems -- Data communications --
Protocol for providing the connectionless-mode
service", ISO 8473, 1988.
[4] ISO, "Information processing systems -- Telecommunications
information exchange between systems -- End system
Intermediate system Routeing exchange protocol for use
conjunction with the protocol for providing the connectionless
mode network service (ISO 8473)", ISO 9542, 1988.
[5] ISO, "Information processing systems -- Telecommunications
information exchange between systems -- Intermediate system
Intermediate system Intra-Domain routeing exchange protocol
use in conjunction with the protocol for providing
connectionless-mode network service (ISO 8473)", ISO 10589,
1990.
[6] ISO, "Protocol for Exchange of Inter-domain
Information among Intermediate Systems to Support Forwarding
ISO 8473 PDUs", ISO CD 10747, 1991.
[7] ISO, "Information technology -- Telecommunications
information exchange between systems -- Protocol
in the network layer", ISO/IEC TR9577:1990.
[8] ISO, "Information processing systems -- Data communications --
X.25 packet level protocol for Data terminal equipment",
8208, 1984.
[9] Taylor, E., "Addendum to ISO 9542 (PDAM 1 - Dynamic
of OSI NSAP Addresses by End Systems)", SC6/N7248.
Some of the text in this document is taken from previous
produced by the Point-to-Point Protocol Working Group of the
Engineering Task Force (IETF).
Special thanks to Ross Callon (DEC), and Cyndi Jung (3Com),
contributions of text and design suggestions based on
Katz [Page 9]
RFC 1377 PPP OSINLCP November 1992
experience
Thanks also to Bill Simpson for his editing and formatting efforts
both for this document and for PPP in general
Security
Security issues are not discussed in this memo
Chair's
The working group can be contacted via the current chair
Brian
Lloyd &
3420 Sudbury
Cameron Park, California 95682
Phone: (916) 676-1147
EMail: brian@lloyd.
Author's
Questions about this memo can also be directed to
Dave
cisco Systems, Inc
1525 O'Brien Dr
Menlo Park, CA 94025
Phone: (415) 688-8284
EMail: dkatz@cisco.
Katz [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
