< draft-ietf-6lo-ghc-03.txt   draft-ietf-6lo-ghc-04.txt >
6Lo Working Group C. Bormann 6Lo Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track July 21, 2014 Intended status: Standards Track September 08, 2014
Expires: January 22, 2015 Expires: March 12, 2015
6LoWPAN Generic Compression of Headers and Header-like Payloads 6LoWPAN Generic Compression of Headers and Header-like Payloads
draft-ietf-6lo-ghc-03 draft-ietf-6lo-ghc-04
Abstract Abstract
This short specification provides a simple addition to 6LoWPAN Header This short specification provides a simple addition to 6LoWPAN Header
Compression that enables the compression of generic headers and Compression that enables the compression of generic headers and
header-like payloads, without a need to define a new header header-like payloads, without a need to define a new header
compression scheme for each new such header or header-like payload. compression scheme for each new such header or header-like payload.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 22, 2015. This Internet-Draft will expire on March 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 8 skipping to change at page 4, line 8
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
The term "byte" is used in its now customary sense as a synonym for The term "byte" is used in its now customary sense as a synonym for
"octet". "octet".
1.4. Notation 1.4. Notation
This specification uses a trivial notation for code bytes and the This specification uses a trivial notation for code bytes and the
bitfields in them the meaning of which should be mostly obvious. bitfields in them, the meaning of which should be mostly obvious.
More formally speaking, the meaning of the notation is: More formally, the meaning of the notation is:
Potential values for the code bytes themselves are expressed by Potential values for the code bytes themselves are expressed by
templates that represent 8-bit most-significant-bit-first binary templates that represent 8-bit most-significant-bit-first binary
numbers (without any special prefix), where 0 stands for 0, 1 for 1, numbers (without any special prefix), where 0 stands for 0, 1 for 1,
and variable segments in these code byte templates are indicated by and variable segments in these code byte templates are indicated by
sequences of the same letter such as kkkkkkk or ssss, the length of sequences of the same letter such as kkkkkkk or ssss, the length of
which indicates the length of the variable segment in bits. which indicates the length of the variable segment in bits.
In the notation of values derived from the code bytes, 0b is used as In the notation of values derived from the code bytes, 0b is used as
a prefix for expressing binary numbers in most-significant-bit first a prefix for expressing binary numbers in most-significant-bit first
skipping to change at page 9, line 32 skipping to change at page 9, line 32
In the IANA registry for the "LOWPAN_NHC Header Type" (in the "IPv6 In the IANA registry for the "LOWPAN_NHC Header Type" (in the "IPv6
Low Power Personal Area Network Parameters"), IANA is requested to Low Power Personal Area Network Parameters"), IANA is requested to
add the assignments in Figure 6. add the assignments in Figure 6.
10110IIN: Extension header GHC [RFCthis] 10110IIN: Extension header GHC [RFCthis]
11010CPP: UDP GHC [RFCthis] 11010CPP: UDP GHC [RFCthis]
11011111: ICMPv6 GHC [RFCthis] 11011111: ICMPv6 GHC [RFCthis]
Figure 6: IANA assignments for the NHC byte Figure 6: IANA assignments for the NHC byte
IANA is requested to allocate an ND option number for the 6CIO ND IANA is requested to allocate an ND option number for the "6LoWPAN
option format in the Registry "IPv6 Neighbor Discovery Option Capability Indication Option (6CIO)" ND option format in the Registry
Formats" [RFC4861]. "IPv6 Neighbor Discovery Option Formats" [RFC4861].
IANA is requested to create a subregistry for "6LoWPAN capability IANA is requested to create a subregistry for "6LoWPAN capability
bits" within the "Internet Control Message Protocol version 6 bits" within the "Internet Control Message Protocol version 6
(ICMPv6) Parameters". The bits are assigned by giving their numbers (ICMPv6) Parameters". The bits are assigned by giving their numbers
as small non-negative integers as defined in section Section 3.4, as small non-negative integers as defined in section Section 3.4,
preferably in the range 0..47. The policy is "IETF Review" or "IESG preferably in the range 0..47. The policy is "IETF Review" or "IESG
Approval" [RFC5226]. The initial content of the registry is as in Approval" [RFC5226]. The initial content of the registry is as in
Figure 7: Figure 7:
0..7: reserved for experiments [RFCthis] 0..7: reserved for experiments [RFCthis]
 End of changes. 5 change blocks. 
9 lines changed or deleted 9 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/