SCHC over PPP
draft-thubert-intarea-schc-over-ppp-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Pascal Thubert | ||
| Last updated | 2020-07-05 (Latest revision 2020-07-01) | ||
| Replaces | draft-thubert-lpwan-schc-over-ppp | ||
| Replaced by | draft-thubert-schc-over-ppp | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Associated None milestone |
|
||
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-thubert-intarea-schc-over-ppp-00
LPWAN P. Thubert, Ed.
Internet-Draft Cisco Systems
Updates: 5172 (if approved) 1 July 2020
Intended status: Standards Track
Expires: 2 January 2021
SCHC over PPP
draft-thubert-intarea-schc-over-ppp-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 2 January 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Thubert Expires 2 January 2021 [Page 1]
Internet-Draft SCHCoPPP July 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extending RFC 5172 . . . . . . . . . . . . . . . . . . . . . 3
4. Profiling SCHC for high speed links . . . . . . . . . . . . . 3
4.1. Mapping the SCHC Architecture . . . . . . . . . . . . . . 4
4.2. SCHC Parameters . . . . . . . . . . . . . . . . . . . . . 4
4.2.1. Resulting Packet Format . . . . . . . . . . . . . . . 5
4.3. Security Considerations . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The Point-to-Point Protocol (PPP) [RFC5172] provides a standard
method of encapsulating network-layer protocol information over
point-to-point links. "A Method for Transmitting PPP Over Ethernet
(PPPoE)" [RFC2516] 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" [RFC5072] 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" [RFC5172] 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" [SCHC] is a compression and
fragmentation technique that was defined after the publication of
[RFC5172]. In order to enable SCHC over PPP and therefore Ethernet
and Wi-Fi, [RFC5172] must be extended to signal SCHC as an additional
compression method for use over PPP.
Thubert Expires 2 January 2021 [Page 2]
Internet-Draft SCHCoPPP July 2020
2. 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 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. 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:
[RFC5172] 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 Figure 1:
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 | IPv6-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Figure 1: The IPv6-Compression-Protocol Configuration Option
This specification indicates a new IPv6-Compression-Protocol field
value for [SCHC] (see Section 5), and enables to transport a Uniform
Resource Identifier (URI) [RFC3986] 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" [SCHC_DATA_MODEL] encoded in JSON as
specified in [RFC7951]. 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.
4. Profiling SCHC for high speed links
Appendix D of [SCHC] specifies the profile information that
technology specifications such as this must provide. The following
section address this requirement.
Thubert Expires 2 January 2021 [Page 3]
Internet-Draft SCHCoPPP July 2020
4.1. 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 Figure 2.
+----------+ Wi-Fi / +----------+ ....
| IP | Ethernet | IP | .. )
| Host +-----/------+ Router +----------( Internet )
| SCHC C/D | Serial | SCHC C/D | ( )
+----------+ +----------+ ...
<-- SCHC -->
over PPP
Figure 2: Typical Deployment
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.
4.2. 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:
Thubert Expires 2 January 2021 [Page 4]
Internet-Draft SCHCoPPP July 2020
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:
|------- Compressed Header -------|
+---------------------------------+--------------------+
| RuleID | Compression Residue | Payload |
+---------------------------------+--------------------+
< 2bytes >
Figure 3: SCHC Packet
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.
4.2.1. Resulting Packet Format
In the case of PPPoE, the sequence of compression and encapsulation
is as follows:
A packet (e.g., an IPv6 packet)
| ^ (padding bits
v | dropped)
+------------------+ +--------------------+
| SCHC Compression | | SCHC Decompression |
+------------------+ +--------------------+
| ^
| (No fragmentation) |
v |
+--------------------+ +--------------------+
| PPP Session encaps | | PPP Session decaps |
+--------------------+ +--------------------+
| ^
| |
v |
+------------------+ +------------------+
| PPPoE(oE) encaps | | PPPoE(oE) encaps |
+------------------+ +------------------+
| ^
| |
+-------------------------------------------+
Sender Receiver
Figure 4: Stack Operation
Thubert Expires 2 January 2021 [Page 5]
Internet-Draft SCHCoPPP July 2020
In the case of PPPoE, a frame that transports an IPv6 packet
compressed with SCHC shows as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination MAC Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Frame Type(0x8864) | Ver=1 | Type=1| Code=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PPP Protocol (IPv6CP) = 0x8057 | SCHC Rule |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Compression ...
| Residue +-+-+-+
| | Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Uncompressed |
... Original ...
| Payload |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SCHC over PPP over Ethernet Format
4.3. Security Considerations
This 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 [SCHC].
5. IANA Considerations
This document requests the allocation of a new value in the registry
"IPv6-Compression-Protocol Types" for "SCHC". A suggested value is
proposed in Table 1:
Thubert Expires 2 January 2021 [Page 6]
Internet-Draft SCHCoPPP July 2020
+=======+==========================================+===============+
| Value | Description | Reference |
+=======+==========================================+===============+
| 4 | Static Context Header Compression (SCHC) | This document |
+-------+------------------------------------------+---------------+
Table 1: IP Header Compression Configuration Option Suboption Types
6. Acknowledgments
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516,
February 1999, <https://www.rfc-editor.org/info/rfc2516>.
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007,
<https://www.rfc-editor.org/info/rfc5072>.
[RFC5172] Varada, S., Ed., "Negotiation for IPv6 Datagram
Compression Using IPv6 Control Protocol", RFC 5172,
DOI 10.17487/RFC5172, March 2008,
<https://www.rfc-editor.org/info/rfc5172>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SCHC] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zúñiga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>.
8. Informative References
Thubert Expires 2 January 2021 [Page 7]
Internet-Draft SCHCoPPP July 2020
[SCHC_DATA_MODEL]
Minaburo, A. and L. Toutain, "Data Model for Static
Context Header Compression (SCHC)", Work in Progress,
Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-02,
28 February 2020, <https://tools.ietf.org/html/draft-ietf-
lpwan-schc-yang-data-model-02>.
[RAW Technologies]
Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C.,
and J. Farkas, "Reliable and Available Wireless
Technologies", Work in Progress, Internet-Draft, draft-
thubert-raw-technologies-05, 18 May 2020,
<https://tools.ietf.org/html/draft-thubert-raw-
technologies-05>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>.
[DetNet] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
Author's Address
Pascal Thubert (editor)
Cisco Systems, Inc
Building D
45 Allee des Ormes - BP1200
06254 Mougins - Sophia Antipolis
France
Phone: +33 497 23 26 34
Email: pthubert@cisco.com
Thubert Expires 2 January 2021 [Page 8]