Congrats to the WG and everyone that has contributed in this monumental
task of building the bridge between Non-IP LPWAN world and the world of the
IP!

And yes, looking forward to the many things that will have SCHC Inside ;)

Cheers,
Alex


On Thu, Apr 16, 2020 at 8:44 AM Carsten Bormann <[email protected]> wrote:

> Congratulations!
>
> After area-context header compression, RFC 6282 in 2011, this is another
> milestone of header compression to bring IP to constrained environments.
> Looking forward towards many things being built on top of this!
>
> Grüße, Carsten
>
>
> > On 2020-04-16, at 04:39, [email protected] wrote:
> >
> > A new Request for Comments is now available in online RFC libraries.
> >
> >
> >        RFC 8724
> >
> >        Title:      SCHC: Generic Framework for Static
> >                    Context Header Compression and Fragmentation
> >        Author:     A. Minaburo,
> >                    L. Toutain,
> >                    C. Gomez,
> >                    D. Barthel,
> >                    JC. Zúñiga
> >        Status:     Standards Track
> >        Stream:     IETF
> >        Date:       April 2020
> >        Mailbox:    [email protected],
> >                    [email protected],
> >                    [email protected],
> >                    [email protected],
> >                    [email protected]
> >        Pages:      71
> >        Updates/Obsoletes/SeeAlso:   None
> >
> >        I-D Tag:    draft-ietf-lpwan-ipv6-static-context-hc-24.txt
> >
> >        URL:        https://www.rfc-editor.org/info/rfc8724
> >
> >        DOI:        10.17487/RFC8724
> >
> > This document defines the Static Context Header Compression and
> > fragmentation (SCHC) framework, which provides both a header
> > compression mechanism and an optional fragmentation mechanism. SCHC
> > has been designed with Low-Power Wide Area Networks (LPWANs) in mind.
> >
> > SCHC compression is based on a common static context stored both in
> > the LPWAN device and in the network infrastructure side. This
> > document defines a generic header compression mechanism and its
> > application to compress IPv6/UDP headers.
> >
> > This document also specifies an optional fragmentation and reassembly
> > mechanism. It can be used to support the IPv6 MTU requirement over
> > the LPWAN technologies. Fragmentation is needed for IPv6 datagrams
> > that, after SCHC compression or when such compression was not
> > possible, still exceed the Layer 2 maximum payload size.
> >
> > The SCHC header compression and fragmentation mechanisms are
> > independent of the specific LPWAN technology over which they are
> > used. This document defines generic functionalities and offers
> > flexibility with regard to parameter settings and mechanism choices.
> > This document standardizes the exchange over the LPWAN between two
> > SCHC entities. Settings and choices specific to a technology or a
> > product are expected to be grouped into profiles, which are specified
> > in other documents. Data models for the context and profiles are out
> > of scope.
> >
> > This document is a product of the IPv6 over Low Power Wide-Area Networks
> Working Group of the IETF.
> >
> > This is now a Proposed Standard.
> >
> > STANDARDS TRACK: This document specifies an Internet Standards Track
> > protocol for the Internet community, and requests discussion and
> suggestions
> > for improvements.  Please refer to the current edition of the Official
> > Internet Protocol Standards (https://www.rfc-editor.org/standards) for
> the
> > standardization state and status of this protocol.  Distribution of this
> > memo is unlimited.
> >
> > This announcement is sent to the IETF-Announce and rfc-dist lists.
> > To subscribe or unsubscribe, see
> >  https://www.ietf.org/mailman/listinfo/ietf-announce
> >  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> >
> > For searching the RFC series, see https://www.rfc-editor.org/search
> > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> >
> > Requests for special distribution should be addressed to either the
> > author of the RFC in question, or to [email protected].  Unless
> > specifically noted otherwise on the RFC itself, all RFCs are for
> > unlimited distribution.
> >
> >
> > The RFC Editor Team
> > Association Management Solutions, LLC
> >
> >
> > _______________________________________________
> > lp-wan mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/lp-wan
>
> _______________________________________________
> lp-wan mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo

Reply via email to