SCHC over PPPCisco Systems, IncBuilding D45 Allee des Ormes - BP1200 Mougins - Sophia Antipolis06254France+33 497 23 26 34pthubert@cisco.com
Internet
LPWAN
This document extends RFC 5172 to signal the use of SCHC as the compression
method between a pair of nodes over PPP. Combined with RFC 2516, this
enables the use of SCHC over Ethernet and Wi-Fi.
Introduction
The Point-to-Point Protocol (PPP) provides a
standard method of encapsulating network-layer protocol information over
point-to-point links. "A Method for Transmitting PPP
Over Ethernet (PPPoE)" transports PPP over Ethernet between a pair of
nodes. It is compatible with a translating bridge to Wi-Fi, and therefore
enables PPP over Wi-Fi as well.
PPP also defines an extensible Link Control Protocol, and proposes a family
of Network Control Protocols (NCPs) for establishing and configuring
different network-layer protocols. "IP Version 6 over
PPP" defines the IPv6 Control Protocol (IPV6CP) , which is an NCP
for a PPP link, and allows for the negotiation of desirable parameters for an
IPv6 interface over PPP.
"Negotiation for IPv6 Datagram Compression Using
IPv6 Control Protocol" defines the IPv6 datagram compression option
that can be negotiated by a node on the link through the IPV6CP. The
"Static Context Header
Compression (SCHC) and fragmentation for LPWAN, application to UDP/IPv6"
is a compression and fragmentation technique that was defined after
the publication of . In order to enable SCHC over PPP
and therefore Ethernet and Wi-Fi, must be extended
to signal SCHC as an additional compression method for use over PPP.
BCP 14
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and only when, they
appear in all capitals, as shown here.
Extending RFC 5172
With this specification, a PPP session defines a vitual link where a SCHC context is established with a particular set of Rules, which is indicated at the set up of the PPP session as follows:
defines an IPV6CP option called the
IPv6-Compression-Protocol Configuration option with a type of 2. The option
contains an IPv6-Compression-Protocol field value that indicates a
compression protocol and an optional data field as shown in
:
This specification indicates a new IPv6-Compression-Protocol field value
for
(see ), and enables to transport a Uniform
Resource Identifier (URI) of the set of rules in the
optional data. The default format for the set of rules is YANG using the
"Data Model for SCHC"
encoded in JSON as specified in . The size
of the URL is computed based on the Length of the option as Length-4.
If the encoding is asymetrical, the initiator of the session is considered
downstream, playing the role of the device in an LPWAN network.
Profiling SCHC for high speed links
Appendix D of specifies the profile information that
technology specifications such as this must provide. The following section
address this requirement.
Mapping the SCHC Architecture
This specification leverages SCHC between an end point that is an IP Host
and possibly a serial DTE (Data Terminal Equipment), and another that is an
IP Node (either another IP Host or a Router) and possibly a serial DCE (Data
Control Equipment), or a more modern physical or emulated endpoint, e.g.,
Ethernet devices that echange IP packets over PPPoE.
Both endpoints MUST support the function of SCHC Compressor/Decompressor (C/D)
as shown in .
The assumption for this document is that the SCHC Fragmenter/Reassembler
(F/R) is generally not needed, because the maximum transmission unit (MTU)
is expected to be large enough and SCHC only reduces the frame size vs.
native IP.
An example use case for SCHC over PPP over Ethernet (PPPoE) would be
to apply SCHC to streamline traffic by reducing the size of the frames and maintain them to a constant size and constant rate, e.g., to simplify the scheduling of DetNet packets over TSN or one of the RAW Technologies. Scheduling on DetNet links introduces a form of duty cycle, but that does not affect the SCHC operation, since fragmentation is not provided.
A context may be generated for a particular upper layer application, such as a control loop using an industrial automation protocol, to protect the particular flow with a DetNet service. The context can be asymetric, e.g., when connecting a master and a slave, a client and a server, or a programmable logic controller with a sensor or an actuator.
SCHC Parameters
Compared to typical LPWANs, most serial links and emulations such as PPPoE
are very fast and most of the constraints can be alleviated. For this
reason, the SCHC profile for PPP is defined as follows:
RuleID numbering scheme:
Rules are of a fixed size of two bytes, which allows for more than 65000 different Rules within one session.
Since this specification does not leverage the SCHC fragmentation, a SCHC
packet is always in the form:
Maximum packet size:
MAX_PACKET_SIZE is aligned to the PPP Link MTU.
Padding:
The L2 word is one byte, so padding is up to the next byte boundary.
The padding bit is a 0.
Resulting Packet Format
In the case of PPPoE, the sequence of compression and encapsulation
is as follows:
In the case of PPPoE, a frame that transports an IPv6 packet compressed with SCHC shows as follows:
Security ConsiderationsThis draft enables to use the SCHC compression and fragmentation over
PPP and therefore Ethernet and Wi-Fi with PPPoE. It inherits the possible
threats against SCHC listed in the "Security considerations" section of
.
IANA ConsiderationsThis document requests the allocation of a new value in the registry
"IPv6-Compression-Protocol Types" for "SCHC". A suggested value is
proposed in :
IP Header Compression Configuration Option Suboption Types