SCHC over PPP
draft-thubert-intarea-schc-over-ppp-01

LPWAN                                                    P. Thubert, Ed.
Internet-Draft                                             Cisco Systems
Updates: 5172 (if approved)                             1 September 2020
Intended status: Standards Track                                        
Expires: 5 March 2021

                             SCHC over PPP
                 draft-thubert-intarea-schc-over-ppp-01

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 5 March 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 5 March 2021                  [Page 1]
Internet-Draft                  SCHCoPPP                  September 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  BCP 14  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Extending RFC 5172  . . . . . . . . . . . . . . . . . . . . .   3
   4.  Profiling SCHC for high speed links . . . . . . . . . . . . .   4
     4.1.  Mapping the SCHC Architecture . . . . . . . . . . . . . .   4
     4.2.  SCHC Parameters . . . . . . . . . . . . . . . . . . . . .   5
       4.2.1.  Resulting Packet Format . . . . . . . . . . . . . . .   6
     4.3.  Security Considerations . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The Point-to-Point Protocol (PPP) [RFC5172] provides a standard
   method of encapsulating network-layer protocol information over
   serial (point-to-point and bus) 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 proposes an extensible Link Control Protocol and a family of
   Network Control Protocols (NCPs) for establishing and configuring
   different network-layer protocols.  "IP Version 6 over PPP" [RFC5072]
   specifies 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 new technology that can
   provide an extreme compression performance but requires a same state
   to be provisionned on both ends before it can be operated.  To enable
   SCHC over PPP and therefore Ethernet and Wi-Fi, this specification
   extends [RFC5172] to signal SCHC as an additional compression method
   for use over PPP.

Thubert                   Expires 5 March 2021                  [Page 2]
Internet-Draft                  SCHCoPPP                  September 2020

   An example use case for SCHC over PPP over Ethernet (SCHCoPPPoE) is
   to apply SCHC to periodic flows and maintain them at a protocol-
   independant size and rate.  The constant size may be too small for a
   particular flow or protocol.  The SCHC fragmentation can then be used
   to transport a protocol data unit (PDU) as N compressed SCHC
   fragments, in which case the effective PDU rate is the TSN frame rate
   divided by N.

   This can be useful to streamline the frames and simplifies the
   scheduling of Deterministic Networking [DetNet] and Operational
   Technology (OT) control flows over IEEE Std 802.1 Time-Sensitive
   Networking (TSN) [IEEE802.1TSNTG] or one of the [RAW Technologies].

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

Thubert                   Expires 5 March 2021                  [Page 3]
Internet-Draft                  SCHCoPPP                  September 2020

   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.

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 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.  But it
   may be used to obtain a small protocol-independant frame size for the
   compressed packets, possibly way smaller than MTU.

   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 primary and a secondary
   endpoints, a client and a server, or a programmable logic controller
   with a sensor or an actuator.

Thubert                   Expires 5 March 2021                  [Page 4]
Internet-Draft                  SCHCoPPP                  September 2020

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:

   RuleID numbering scheme:  The RuleID for a compression rule is
      expressed as 2 bytes.  The first (leftmost) 2 bits of that RuleId
      MUST be set to 0 This leaves 14 bits to index the rule.  A SCHC
      compressed packet is always in the form:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------...--------+~~~~~~~~~~
      |0 0         RuleID             | Compression Residue | Payload
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------...--------+~~~~~~~~~~
      |------- Compressed Header (byte aligned) ------------|

                       Figure 3: SCHC Compressed Packet

      This specification only supports the No-ACK Mode of SCHC
      fragmentation as specified in section 8.4.1 of [SCHC].  The SCHC
      Fragment Header is 2 bytes long.

      The RuleID for a fragmenation rule is expressed as 4 bits.  The
      bits MUST all set to 1 for a fragmentation rule in No-ACK Mode.
      The DTag field is 11 bits long (T=11) and the FCN field is one bit
      (N=1), which is set to 1 on the last fragment as illustrated in
      Appendix B of [SCHC] and to 0 otherwise.  There is no W field
      (M=0).

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------...-------+~~~~~~~~~~~
       |1 1 1 1|        DTag         |F| Fragment Payload |  padding
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------...-------+~~~~~~~~~~~
               |--------- T ---------|N|
       |---- SCHC Fragment Header  ----|

                           Figure 4: SCHC Fragment

      The No-ACK mode has been designed under the assumption that data
      unit out-of-sequence delivery does not occur between the entity
      performing fragmentation and the entity performing reassembly and
      a DetNet PREOF function might be needed to reorder the fragments.

Thubert                   Expires 5 March 2021                  [Page 5]
Internet-Draft                  SCHCoPPP                  September 2020

   Maximum packet size:  MAX_PACKET_SIZE is aligned to the PPP Link MTU.

   Padding:  The Compression Residue MUST be aligned to the L2 word.
      For Ethernet, the L2 word is one byte, so padding is needed up to
      the next byte boundary.  If a compression rule produces a residue
      that is not byte aligned, then it is implicitly terminated with a
      statement that indicates padding till the next byte boundary.  The
      padding bit is 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                   |   |                   |
    +--------------------+       |   |         +-------------------+
    | SCHC Fragmentation |       |   |         |  SCHC Reassembly  |
    +--------------------+       |   |         +-------------------+
             |                   |   |                   ^
             +<------------------+   |         No        |
             |                       +-- fragmentation  -+
             v                                           |
    +--------------------+                    +--------------------+
    | PPP Session encaps |                    | PPP Session decaps |
    +--------------------+                    +--------------------+
             |                                           ^
             |                                           |
             v                                           |
     +------------------+                      +------------------+
     | PPPoE(oE) encaps |                      | PPPoE(oE) encaps |
     +------------------+                      +------------------+
             |                                           ^
             |                                           |
             +-------------------------------------------+
           Sender                                    Receiver

                  Figure 5: Stack Operation (no fragment)

Thubert                   Expires 5 March 2021                  [Page 6]
Internet-Draft                  SCHCoPPP                  September 2020

   In the case of PPPoE, a frame that transports an IPv6 packet
   compressed with SCHC with no fragmentation 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 (IPv6) = 0x0057  |0|0|       SCHC RuleID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
    ...                        Compression                          ...
     |                           Residue                       +-+-+-+
     |                                                         | Pad |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                                                               |
     |                         Uncompressed                          |
    ...                          Original                           ...
     |                           Payload                             |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 6: 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 5 March 2021                  [Page 7]
Internet-Draft                  SCHCoPPP                  September 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 5 March 2021                  [Page 8]
Internet-Draft                  SCHCoPPP                  September 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-03,
              10 July 2020, <https://tools.ietf.org/html/draft-ietf-
              lpwan-schc-yang-data-model-03>.

   [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>.

   [IEEE802.1TSNTG]
              IEEE, "Time-Sensitive Networking (TSN) Task Group",
              <https://1.ieee802.org/tsn/>.

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 5 March 2021                  [Page 9]