RFC 1377

The PPP OSI Network Layer Control Protocol (OSINLCP)

📅 published November 1992, from ietf

RFC 1377: The PPP OSI Network Layer Control Protocol (OSINLCP) 🎀

Okay bestie, this one is all about how PPP (Point-to-Point Protocol) carries OSI network layer stuff over a point-to-point link. Here's the title block tea ☕:

  • Series: Network Working Group, Request for Comments 1377
  • Author: D. Katz, cisco 💅
  • Category: IAB standards track protocol
  • Date: November 1992
  • Obsoletes / Updates: Nothing listed in the title block, so it doesn't obsolete or update any other RFCs ✨

Status of This Memo 📜

This RFC is an IAB standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 💖 For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards." And distribution of this memo is unlimited, so share it with everyone 🌈

Abstract 🦋

PPP gives us a standard way to encapsulate Network Layer protocol information over point-to-point links. It also has an extensible Link Control Protocol, and it proposes a family of Network Control Protocols (NCPs) for setting up and configuring different network-layer protocols. Iconic architecture, honestly 👑

This document defines the NCP for establishing and configuring OSI Network Layer Protocols. So this is the one for OSI 🫶

This memo came out of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be sent to the ietf-ppp@ucdavis.edu mailing list 📬

Table of Contents 🗂️

   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

1. Introduction ✨

Okay so PPP has three main parts, and they all work together 🧚

  1. A way to encapsulate datagrams over serial links.
  2. A Link Control Protocol (LCP) that sets up, configures, and tests the data-link connection.
  3. A family of Network Control Protocols (NCPs) that set up and configure different network-layer protocols.

To get communication going over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. Once the link is up and any optional facilities the LCP negotiated are sorted, PPP must send NCP packets to pick and configure one or more network-layer protocols. After each chosen network-layer protocol is configured, its datagrams can start flowing over the link 🌸

The link stays configured until explicit LCP or NCP packets close it down, or until some outside event happens (an inactivity timer expires, or a network administrator steps in) ⏳

1.1. OSI Network Layer Protocols over PPP 🌈

A bunch of protocols have been defined for the OSI Network Layer, like 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 routing protocol (IS-IS, ISO 10589) [5], and the Inter-Domain Routeing Protocol (IDRP, CD 10747) [6]. Generally, these protocols were designed to run over non-reliable data link protocols such as PPP, so they're built for that kind of messy link 💅

Network Layer Protocol Identifier (NLPID)

OSI Network Layer protocols can be told apart by the first octet in each Network Protocol Data Unit (NPDU, which is just a fancy word for packet). That first octet is the Network Layer Protocol Identifier (NLPID), and it's defined in ISO/TR 9577 [7]. This lets the different protocols share one common data link without needing any discriminator below the network layer. Main character energy 🎀

Inactive Network Layer Protocol

ISO/TR 9577 reserves the NLPID value zero to represent the "Inactive Network Layer Protocol," as defined in ISO 8473. The inactive network layer protocol MUST NOT be used over PPP. This makes sure that whichever OSI network layer protocol is in use will have a non-zero NLPID value 🙈

Connection-Oriented Network Protocol

The OSI Connection-Oriented Network Protocol (ISO 8208) [8] is basically the Packet Layer of CCITT X.25. It's meant to run over a reliable data link, like IEEE 802.2 type II or LAPB. So the unreliable data link service PPP gives is not appropriate for use with ISO 8208. Not for this one, bestie 🙅‍♀️

ConnectionLess Network Protocol (CLNP)

The ConnectionLess Network Protocol is a simple non-reliable datagram service that's very similar to IP. It's designed to run over a non-reliable data link service, like the one PPP provides 🦋

End-System to Intermediate-System Protocol (ES-IS)

ES Hellos and IS Hellos get retransmitted on a periodic, timer-driven basis (based on expiration of the "Configuration Timer"). The ES and IS configuration info that comes out of this gets invalidated on a timer-driven basis too, based on expiration of the "Holding Timer" for each piece of information. The source of the information sets the value of a Holding Timer, and it's sent in the Holding Time field of the matching ES-IS packet 🍓

ISO 9542 recommends setting the holding time field to about twice the Configuration Timer parameter. That way, even if every other Hello packet gets lost, the configuration info is still kept. (This means the Holding Timer ends up being set to slightly more than twice the Configuration Timer.) Smart, right? 🧠

Generally, the ISO 9542 recommendation is good enough for PPP links. For very unreliable links, you might need to set the Holding Timer to slightly more than three times the Configuration Timer, so that losing configuration info stays an unusual event 😭

Redirect information isn't sent on point-to-point links. It can be sent on general topology subnetworks, though, and those may use PPP. Redirect information goes out on an event-driven basis (when a router forwards a CLNP packet out the incoming interface), but it gets invalidated on a timer-driven basis. If you lose one redirect, a later data packet might get sent to the same incorrect router, and that router will just re-issue the redirect. It works the same way as ICMP redirects for IP packets, and it doesn't cause any problems for operation over PPP links 💜

Intermediate-System to Intermediate-System Protocol (IS-IS)

IS-IS works over broadcast links (usually LANs), point-to-point links (like PPP), and general topology links (like X.25 networks). Those last ones are modelled as a collection of point-to-point links 🌐

There are four types of IS-IS packets: IS-IS Hello Packets, Link State Packets (LSPs), Complete Sequence Number Packets (CSNPs), and Partial Sequence Number Packets (PSNPs) 🫶

IS-IS Hello messages get sent periodically on point-to-point links (based on expiration of the ISISHello timer), and routers expect to receive them regularly. The IS-IS Hello packet specifies a "Holding Time." If no new IS-IS Hello comes in over the link for that period, the neighboring router is assumed to be disconnected or down. Links flapping up and down for no reason is highly undesirable 🙃 So the holding time needs to be big enough that a link is very unlikely to get declared down just because an IS-IS Hello didn't show up.

That means running IS-IS over unreliable data links requires the Holding Time to be greater than "k" times the ISISHello timer, where k is chosen so that losing k consecutive IS-IS Hellos is rare. If the link quality is poor, you'll need to increase the Holding Time or decrease the ISISHello time 🔧

LSPs get acknowledged by the IS-IS protocol (through partial sequence number packets). A lost LSP gets recovered from with no problem, as long as PPP links are treated the same way as other point-to-point links. Every once in a while a partial sequence number packet gets lost, and that might cause a link state packet to be retransmitted over a single link. It won't mess up the correct operation of the routing algorithm though 🌸

CSNPs are sent when a point-to-point link starts up. This doesn't need to change for PPP. If a CSNP fragment gets lost at startup, it's just a lost optimization, since LSPs that didn't need to go over the link will get sent anyway. If a periodic CSNP fragment is lost, detecting low-probability database corruption will just take longer 🕵️‍♀️

PSNPs work as ACKs. If one gets lost, you might get an unnecessary retransmission of an LSP, but the routing protocol still works correctly 💖

Inter-Domain Routeing Protocol (IDRP)

IDRP expects to run over datagram links, but it needs reliable exchange of IDRP information. Because of that, IDRP has built-in reliability mechanisms that make sure packets get received correctly 👑

2. A PPP Network Control Protocol (NCP) for OSI 🎀

The OSI Network Layer Control Protocol (OSINLCP) handles configuring, enabling, and disabling the OSI protocol modules on both ends of the point-to-point link. OSINLCP uses the same packet exchange mechanism as the Link Control Protocol (LCP). OSINLCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. Any OSINLCP packets received before that phase is reached should be silently discarded 🙈

The OSI Network Layer Control Protocol is exactly the same as the Link Control Protocol [1], with the following exceptions:

Frame Modifications

The packet may use any modifications to the basic frame format that were negotiated during the Link Establishment phase ✨

Exactly one OSINLCP packet is encapsulated in the Information field of a PPP Data Link Layer frame where the Protocol field indicates type hex 8023 (OSI Network Layer Control Protocol) 📦

Code field

Only Codes 1 through 7 are used: Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, and Code-Reject. Any other Codes should be treated as unrecognized and should result in Code-Rejects 🙅‍♀️

Timeouts

OSINLCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be ready to wait for Authentication and Link Quality Determination to finish before it times out waiting for a Configure-Ack or other response. It's suggested that an implementation give up only after user intervention or after a configurable amount of time. Patience is a virtue, babe 🌷

Configuration Option Types

OSINLCP has one Configuration Option, which is defined below 💜

Part 1 wraps here, bestie! 🎀 Part 2 picks up with Section 3 and the Align-NPDU option, plus the REFERENCES, ACKNOWLEDGEMENTS, SECURITY CONSIDERATIONS, and the addresses. The good stuff is coming 👀

2.1. Sending OSI NPDUs 💌

okay so before any Network Protocol Data Units (NPDUs) can get sent 🫶, PPP has to reach the Network-Layer Protocol phase, and the OSI Network Layer Control Protocol has to hit the Opened state. no skipping the line, bestie 💅

exactly one OSI NPDU rides in the Information field of a PPP Data Link Layer frame, and the Protocol field says 0023 (that's OSI Network Layer) ✨

the max length of an OSI NPDU sent over a PPP link is the same as the max length of the Information field of a PPP data link layer frame. anything bigger has to get segmented as needed 🧩. and if a system really wants to dodge segmentation and reassembly, it should use transport layer mechanisms to discourage others from sending big PDUs 🙈

2.2. NPDU Alignment 📏

OSI protocols are lowkey chaotic with alignment 😭. they often get wrapped in data link protocols with odd-length headers, but PPP loves even-length headers. so a router switching an OSI packet might find the start of the packet landing on an inconvenient memory boundary when the hardware for the next hop wants a particular alignment 💀. the fix is leading zero padding 🎀

When sending, an implementation MAY insert one to three octets of zero between the PPP header and the OSI NPDU. those zero octets shrink the max NPDU length that can be sent, so it's a trade-off 🌸

On reception, any such leading zero octets (if present) MUST be removed. Regardless of whether leading zero padding is used, an implementation MUST also be able to receive a PPP packet with any arbitrary alignment of the NPDU 🫧

2.3. Network Layer Addressing Information 🗺️

OSINLCP doesn't have its own configuration option for swapping OSI Network Layer address info 🙅. instead, ES-IS, which is ISO 9542, is the one you should use ✨. it figures out the Network Layer address(es) of the neighbor on the link AND whether that neighbor is an End System or an Intermediate System 👀

A draft addendum to ES-IS [9] is being defined in ISO to add support for dynamic address assignment 🌷. it has passed the formal "Committee Draft" (CD) letter ballot 🎉

3. OSINLCP Configuration Options 🎀

OSINLCP Configuration Options let peers negotiate desirable Internet Protocol parameters 🤝. OSINLCP uses the same Configuration Option format defined for LCP [1], just with its own separate set of Options 💜.

The most up-to-date values of the OSINLCP Option Type field live in the most recent "Assigned Numbers" RFC [2] 📚. right now they're assigned like this:

      1       Align-NPDU

3.1. Align-NPDU 🦋

Description

This Configuration Option lets the receiver negotiate a particular alignment of the OSI NPDU. Empirical evidence suggests the greatest time deficit for re-alignment exists at the receiver 😤.

The alignment is done through a combo of PPP header compression and leading zero padding (see above). It is recommended that alignment come entirely from header compression combinations whenever possible ✨. for example, an alignment of 3 could be achieved by combining uncompressed PPP Address and Control fields (2 octets) with a compressed PPP Protocol field (1 octet) 💅.

This option is negotiated separately in each direction. A receiver which does not need alignment MUST NOT request the option. A sender which wants alignment before sending SHOULD Configure-Nak with an appropriate value 💖.

Implementation Note: In a complex environment, there might be several conflicting needs for alignment. It is recommended that the receiver request alignment based on the needs of the highest speed next hop link. Also, greater efficiency might be obtained by negotiating upstream the values requested by downstream PPP links, since those packets won't need a change in alignment on transit 🚀.

The alignment request is advisory, and failure to agree on an alignment MUST NOT prevent the OSINLCP from reaching the Opened state. By default, the alignment is done according to the needs of the sender, and all receivers MUST be capable of accepting packets with any alignment 🧚.

Vernacular: If you don't like this option, you can refuse to negotiate it, and you can send whatever alignment you want 🙃. However, if you accept the peer's alignment option, then you MUST transmit packets with the agreed alignment ‼️.

A summary of the Align-NPDU Configuration Option format is shown 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   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 1

Length: 3

Alignment: this field is the offset of the beginning of the OSI NPDU relative to the beginning of the PPP packet header (not including 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 when the PPP Address, Control, and Protocol fields are compressed. One octet of leading zero padding would be necessary when the PPP header is full sized 🌈.

A value of 255 requests an offset of an odd length (1 or 3). A value of 254 requests an offset of an even length (2 or 4). If the sender is not capable of dynamically varying the amount of padding, it MUST NAK with one of the two specific values 🫠.

References 📚

[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 network service", ISO 8473, 1988.

[4] ISO, "Information processing systems -- Telecommunications and information exchange between systems -- End system to Intermediate system Routeing exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO 9542, 1988.

[5] ISO, "Information processing systems -- Telecommunications and information exchange between systems -- Intermediate system to Intermediate system Intra-Domain routeing exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO 10589, 1990.

[6] ISO, "Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs", ISO CD 10747, 1991.

[7] ISO, "Information technology -- Telecommunications and information exchange between systems -- Protocol identification in the network layer", ISO/IEC TR9577:1990.

[8] ISO, "Information processing systems -- Data communications -- X.25 packet level protocol for Data terminal equipment", ISO 8208, 1984.

[9] Taylor, E., "Addendum to ISO 9542 (PDAM 1 - Dynamic Discovery of OSI NSAP Addresses by End Systems)", SC6/N7248.

Acknowledgments 🫶

Some of the text in this document is taken from previous documents produced by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). 🌸

Special thanks to Ross Callon (DEC), and Cyndi Jung (3Com), for contributions of text and design suggestions based on implementation experience 👑.

Thanks also to Bill Simpson for his editing and formatting efforts, both for this document and for PPP in general 💖.

Security Considerations 🔐

Security issues are not discussed in this memo. 💀 Security issues are not discussed in this memo.

Chair's Address 📮

The working group can be contacted via the current chair:

Brian Lloyd
Lloyd & Associates
3420 Sudbury Road
Cameron Park, California 95682

Phone: (916) 676-1147
EMail: brian@lloyd.com

Author's Address ✍️

Questions about this memo can also be directed to:

Dave Katz
cisco Systems, Inc.
1525 O'Brien Dr.
Menlo Park, CA  94025

Phone: (415) 688-8284
EMail: dkatz@cisco.com

That's the whole RFC, bestie 🌈✨

📦 where this page comes from