< draft-jiang-asymmetric-ipv6-00.txt   draft-jiang-asymmetric-ipv6-01.txt >
Network Working Group S. Jiang Network Working Group S. Jiang
Internet-Draft Huawei Technologies Co., Ltd Internet-Draft Huawei Technologies Co., Ltd
Intended status: Informational G. Li Intended status: Informational G. Li
Expires: December 5, 2019 Huawei Technologies Expires: December 23, 2019 Huawei Technologies
B. Carpenter B. Carpenter
Univ. of Auckland Univ. of Auckland
June 3, 2019 June 21, 2019
Asymmetric IPv6 for IoT Networks Asymmetric IPv6 for IoT Networks
draft-jiang-asymmetric-ipv6-00 draft-jiang-asymmetric-ipv6-01
Abstract Abstract
This document describes a new approach to IPv6 header compression for This document describes a new approach to IPv6 header compression for
use in scenarios where minimizing packet size is crucial but routing use in scenarios where minimizing packet size is crucial but routing
performance must be maximised. performance must be maximised.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 December 5, 2019. This Internet-Draft will expire on December 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 29 skipping to change at page 2, line 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The large address space of IPv6 is essential for the massive The large address space of IPv6 is essential for the massive
expansion of the network edge that will be caused by "Internet of expansion of the network edge that will be caused by "Internet of
Things (IoT)" technology over low-power or 5G links. However, the Things (IoT)" technology over low-power or 5G links. However, the
size of a raw IPv6 packet header causes difficulty due to the small size of a raw IPv6 packet header causes difficulty due to the small
maximum transmission units (MTU) allowed by typical low-power, low- maximum transmission units (MTU) allowed by typical low-power, low-
cost link layers. For 5G, this aspect is discussed in cost link layers. For 5G, this aspect is discussed in
[I-D.hmm-dmm-5g-uplane-analysis]. Thus header compression, including [I-D.ietf-dmm-5g-uplane-analysis]. Thus header compression,
address compression, is an important issue. This decreases the size including address compression, is an important issue. This decreases
of raw packets, but compressed IP addresses are not routeable except the size of raw packets, but compressed IP addresses are not
by decompressing them completely in every forwarding node. There are routeable except by decompressing them completely in every forwarding
two issues here. The first is the extra computation resource needed node. There are two issues here. The first is the extra computation
for compressing or decompressing in constrained IoT nodes. The resource needed for compressing or decompressing in constrained IoT
second is that full-length IPv6 routing will consume more memory to nodes. The second is that full-length IPv6 routing will consume more
store routing tables and packet queues. Such resource consumption is memory to store routing tables and packet queues. Such resource
very undesirable in constrained nodes with limited storage, CPU consumption is very undesirable in constrained nodes with limited
power, and battery capacity. storage, CPU power, and battery capacity.
To mitigate these issues, here we propose a solution enabling the To mitigate these issues, here we propose a solution enabling the
shortening of IPv6 addresses inside packets, and the routing of shortening of IPv6 addresses inside packets, and the routing of
packets according to short addresses, without needing a decompression packets according to short addresses, without needing a decompression
step. Considering that the scale and size of edge networks may vary step. Considering that the scale and size of edge networks may vary
widely, different lengths of short address can be used in different widely, different lengths of short address can be used in different
domains. domains.
This work is distinct from previous 6LoWPAN work on address This work is distinct from previous 6LoWPAN work on address
compression [RFC6282] [RFC7400]. Although those solutions tackle the compression [RFC6282] [RFC7400]. Although those solutions tackle the
skipping to change at page 7, line 5 skipping to change at page 7, line 5
NOTE IN DRAFT: If the solution of a 6LoWPAN dispatch type is adopted, NOTE IN DRAFT: If the solution of a 6LoWPAN dispatch type is adopted,
a suitable assignment request will be added. a suitable assignment request will be added.
9. References 9. References
[crowcroft] [crowcroft]
Crowcroft, J. and M. Bagnulo, "SNA: Sourceless Network Crowcroft, J. and M. Bagnulo, "SNA: Sourceless Network
Architecture", University of Cambridge Computer Laboratory Architecture", University of Cambridge Computer Laboratory
Technical Report UCAM-CL-TR-849, 2014. Technical Report UCAM-CL-TR-849, 2014.
[I-D.hmm-dmm-5g-uplane-analysis] [I-D.ietf-dmm-5g-uplane-analysis]
Homma, S., Miyasaka, T., Matsushima, S., and d. Homma, S., Miyasaka, T., Matsushima, S., and d.
daniel.voyer@bell.ca, "User Plane Protocol and daniel.voyer@bell.ca, "User Plane Protocol and
Architectural Analysis on 3GPP 5G System", draft-hmm-dmm- Architectural Analysis on 3GPP 5G System", draft-ietf-dmm-
5g-uplane-analysis-02 (work in progress), October 2018. 5g-uplane-analysis-01 (work in progress), March 2019.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
skipping to change at page 8, line 11 skipping to change at page 8, line 11
[talwar] Talwar, M., "ROUTING TECHNIQUES AND PROTOCOLS FOR INTERNET [talwar] Talwar, M., "ROUTING TECHNIQUES AND PROTOCOLS FOR INTERNET
OF THINGS: A SURVEY", Indian J.Sci.Res. 12(1):417-423, OF THINGS: A SURVEY", Indian J.Sci.Res. 12(1):417-423,
2015. 2015.
Appendix A. Change log [RFC Editor: Please remove] Appendix A. Change log [RFC Editor: Please remove]
draft-jiang-asymmetric-ipv6-00, 2019-06-03: draft-jiang-asymmetric-ipv6-00, 2019-06-03:
Initial version Initial version
draft-jiang-asymmetric-ipv6-01, 2019-06-21:
Fixed reference error
Authors' Addresses Authors' Addresses
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095 Hai-Dian District, Beijing, 100095
P.R. China P.R. China
Email: jiangsheng@huawei.com Email: jiangsheng@huawei.com
 End of changes. 8 change blocks. 
17 lines changed or deleted 21 lines changed or added

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