< draft-jiang-intarea-nmp-edge-00.txt   draft-jiang-intarea-nmp-edge-01.txt >
Internet Area Working Group S. Jiang Internet Area Working Group Z. Chen
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Experimental 25 October 2021 Intended status: Experimental S. Jiang
Expires: 28 April 2022 Expires: October 16, 2022 April 14, 2022
Native Minimal Protocols with Flexibility at Edge Networks Native Minimal Protocols with Flexibility at Edge Networks
draft-jiang-intarea-nmp-edge-00 draft-jiang-intarea-nmp-edge-01
Abstract Abstract
This document introduces a flexible native minimal protocol for fast This document introduces a flexible native minimal protocol for fast
short packet transmission in edge networks, and can communicate with short packet transmission in edge networks, and can communicate with
IPv6 nodes through gateways. IPv6 nodes through gateways.
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 32 skipping to change at page 1, line 32
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 28 April 2022. This Internet-Draft will expire on October 16, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Packet Header Format . . . . . . . . . . . . . . . . . . 4 4.1. Packet Header Format . . . . . . . . . . . . . . . . . . 4
4.1.1. Data Packet Header Format . . . . . . . . . . . . . . 5 4.1.1. Data Packet Header Format . . . . . . . . . . . . . . 5
4.1.2. Control Packet Header Format . . . . . . . . . . . . 6 4.1.2. Control Packet Format . . . . . . . . . . . . . . . . 6
4.2. Control Messages . . . . . . . . . . . . . . . . . . . . 6 4.2. Control Messages . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Address Request and Assignment Messages . . . . . . . 6 4.2.1. Address Request and Assignment Messages . . . . . . . 6
4.2.2. Address Lease Extension Messages . . . . . . . . . . 7 4.2.2. Address Lease Extension Messages . . . . . . . . . . 7
4.3. DNS Delegation Messages . . . . . . . . . . . . . . . . . 8 4.3. DNS Delegation Messages . . . . . . . . . . . . . . . . . 8
4.4. Functionalities of Gateway . . . . . . . . . . . . . . . 9 4.4. Functionalities of Gateway . . . . . . . . . . . . . . . 9
4.4.1. Address Management . . . . . . . . . . . . . . . . . 9 4.4.1. Address Management . . . . . . . . . . . . . . . . . 9
4.4.2. Address Translation . . . . . . . . . . . . . . . . . 9 4.4.2. Address Translation . . . . . . . . . . . . . . . . . 10
5. Renumber Considerations . . . . . . . . . . . . . . . . . . . 10 5. Renumber Considerations . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
TCP/IP protocol suites are adopted widely in different areas. TCP/IP protocol suites are adopted widely in different areas.
However, there are still numerous edge networks uses non-IP However, there are still numerous edge networks uses non-IP
technologies like ZigBee, BLE, CAN-bus, and Modbus for different technologies like ZigBee, BLE, CAN-bus, and Modbus for different
reasons (e.g., power-constrained devices, low transport rate media). reasons (e.g., power-constrained devices, low transport rate media).
For such networks, application-layer gateways (or protocol For such networks, application-layer gateways (or protocol
tranlators) are usually deployed to connect them with the Internet, tranlators) are usually deployed to connect them with the Internet,
as shown in Figure 1. as shown in Figure 1.
skipping to change at page 2, line 52 skipping to change at page 3, line 5
| |<-------------->| |<--------------->| | | |<-------------->| |<--------------->| |
+--+ +--+ +--+ +--+ +--+ +--+
Non-IP Gateway TCP/IP Non-IP Gateway TCP/IP
Terminal Terminal Terminal Terminal
Figure 1: Communication Architecture with Application Gateway Figure 1: Communication Architecture with Application Gateway
The application-layer translation mechanism MAY bring three main The application-layer translation mechanism MAY bring three main
drawbacks: 1. End-to-end security channel like IPSec or TLS is not drawbacks: 1. End-to-end security channel like IPSec or TLS is not
supported, a malicious gateway may manipulate data that is transmited supported, a malicious gateway may manipulate data that is transmited
between two terminals. 2. Non-IP terminals are invisible to the TCP/ between two terminals. 2. Non-IP terminals are invisible to the
IP network, which makes it hard to conduct QoS or OAM operations, TCP/IP network, which makes it hard to conduct QoS or OAM operations,
e.g., guaranteeing SLA of a specific non-IP terminal's traffic, or e.g., guaranteeing SLA of a specific non-IP terminal's traffic, or
"ping" a non-IP terminal. 3. When a non-IP terminal joins or one "ping" a non-IP terminal. 3. When a non-IP terminal joins or one
leaves the network, corresponding rules SHOULD be configured on the leaves the network, corresponding rules SHOULD be configured on the
gateway, thus increasing operation costs (i.e., OPEX). gateway, thus increasing operation costs (i.e., OPEX).
Therefore, it would be beneficial to make those non-IP terminals Therefore, it would be beneficial to make those non-IP terminals
adopt TCP/IP protocol suites, thus eliminating aforementioned adopt TCP/IP protocol suites, thus eliminating aforementioned
drawbacks. The Internet Protocol Version 6 (IPv6) is expected to drawbacks. The Internet Protocol Version 6 (IPv6) is expected to
achieve the goal, however, it is challenging in some cases due to its achieve the goal, however, it is challenging in some cases due to its
long address and header length (40 bytes in total). For instance, it long address and header length (40 bytes in total). For instance, it
would consume more energy for power constrained terminals like IoT would consume more energy for power constrained terminals like IoT
devices, and would amplify flow completion time on low-rate transport devices, and would amplify flow completion time on low-rate transport
skipping to change at page 4, line 36 skipping to change at page 4, line 36
Only Support Extreme Simplified Control Messages within NMP Domain Only Support Extreme Simplified Control Messages within NMP Domain
Figure 2: Overview of Native Minimal Protocol Figure 2: Overview of Native Minimal Protocol
4. Protocol Design 4. Protocol Design
4.1. Packet Header Format 4.1. Packet Header Format
The first bit at the beginning of the packet header indicates whether The first bit at the beginning of the packet header indicates whether
the packet is a control message or a data packet. The basic format the packet is encapsulated with extreme concise format or not. If
is specified as follows Figure 3. the first bit is 0, packet format is specified as follows Figure 3.
+----------------+---------------------+---------------------+ +----------------+---------------------+---------------------+
|Indicator(1 bit)|Data/Control Headers | Payload/MessageBody | |Indicator(1 bit)| NMP Headers | Payload |
+----------------+---------------------+---------------------+ +----------------+---------------------+---------------------+
Figure 3: Basic Format of Native Minimal Protocol Packet Figure 3: Basic Format of Native Minimal Protocol Packet
* Indicator one-bit indicator to indicate Data or Control packet o Indicator one-bit indicator to indicate whether extreme concise
follows. 1 - control packet; 0 - data packet. format is used. 0 - NMP headers follows; 1 - undefined.
* Data/Control Headers Record the fileds of data packet header in o NMP Headers Record the fileds of packet header in Section 4.1.1 .
Section 4.1.1 or the control packet header in Section 4.1.2
* Payload/MessageBody The payload of the data packet or message body o Payload The payload of the packet. For control plane packets, the
of a control packet control plane messages defined in Section 4.1.2 are carried in
this part.
4.1.1. Data Packet Header Format 4.1.1. Data Packet Header Format
For data packet header, NMP uses bitmap with variable length to For data packet header, NMP uses bitmap with variable length to
indicate which in-line headers appear in the packet. The indicate which in-line headers appear in the packet. The
specification is in Figure 4. specification is in Figure 4.
+----------------------+-------------------+ +----------------------+-------------------+
| Bitmap | In-line Headers | | Bitmap | In-line Headers |
| (7 bits, extensible) | (variable length) | | (7 bits) | (variable length) |
+----------------------+-------------------+ +----------------------+-------------------+
Figure 4: Data Packet Header Format Figure 4: NMP Header Format
* Bitmap A variable-length bitmap with at least 7 bits is used to o Bitmap A variable-length bitmap with at least 7 bits is used to
indicate whether a NMP field is carried in a packet.The value 1 indicate whether a NMP field is carried in a packet.The bit of 1
indicates that the packet carries this field and is located in the indicates that the packet carries this field and is located in the
following in-line headers field. The value 0 indicates that the following in-line headers field. The value 0 indicates that the
packet does not contain this field. The length of bitmap is packet does not contain this field. The length of bitmap is
defined as follows. defined as follows.
+------------------+----------------------------+-----------------+ +------------------+----------------------------+-----------------+
| bitmap format |number of bits for indicator|scope fo headers | | bitmap format |number of bits for indicator|scope fo headers |
+------------------+----------------------------+-----------------+ +------------------+----------------------------+-----------------+
| 1xx xxxx | 6 bits | header 1 ~ 6 | | xxx xxx0 | 6 bits | header 1 ~ 6 |
+------------------+----------------------------+-----------------+
|01x xxxx xxxx xxxx| 13 bits | header 1 ~ 13 |
+------------------+----------------------------+-----------------+ +------------------+----------------------------+-----------------+
* In-line Headers The headers in NMP packet. Each header o In-line Headers The headers in NMP packet. Each header
corresponds to a position in preceding bitmap. corresponds to a position in preceding bitmap.
+--------+----------------+---------------+ +--------+----------------+---------------+
| Bitpos | Header Name | Header Length | | Bitpos | Header Name | Header Length |
+--------+----------------+---------------+ +--------+----------------+---------------+
| 1 | Destination | Variable | | 1 | TTL | 8 bit |
+--------+----------------+---------------+ +--------+----------------+---------------+
| 2 | Source | Variable | | 2 | Total Length | 16 bit |
+--------+----------------+---------------+ +--------+----------------+---------------+
| 3 | Next Header | 8 bit | | 3 | Next Header | 8 bit |
+--------+----------------+---------------+ +--------+----------------+---------------+
| 4 | Payload Length | Variable | | 4 | Reserved | N/A |
+--------+----------------+---------------+ +--------+----------------+---------------+
| 5 | Checksum | 8 bit | | 5 | Destination |Variable Length|
+--------+----------------+---------------+ +--------+----------------+---------------+
| 6 | DNS | 0 bit | | 6 | Source |Variable Length|
+--------+----------------+---------------+ +--------+----------------+---------------+
| 7 ~ 13 | Reserved | / | | 7 |Next Bitmap Byte| N/A |
+--------+----------------+---------------+ +--------+----------------+---------------+
4.1.2. Control Packet Header Format 4.1.2. Control Packet Format
+----------------------+-------------------+ +----------------------+-------------------+
| Type | Checksum | | Message Type | Checksum |
| (7 bits) | (8 bits) | | (8 bits) | (8 bits) |
+----------------------+-------------------+ +----------------------+-------------------+
Figure 5: Control Packet Header Format Figure 5: Control Packet Header Format
* Type This filed carries value to indicate the type of this control o Type This filed carries value to indicate the type of this control
message. message.
* Checksum The checksum is the 8-bit one's complement of the one's o Checksum The checksum is the 8-bit one's complement of the one's
complement sum of the entire control message, starting with the complement sum of the entire control message, starting with the
message type field, and prepended with a "1" of indicator header message type field, and prepended with a "1" of indicator header
fields, as specified in Section 4.1. For computing the checksum, fields, as specified in Section 4.1. For computing the checksum,
the checksum field is first set to zero. the checksum field is first set to zero.
4.2. Control Messages 4.2. Control Messages
4.2.1. Address Request and Assignment Messages 4.2.1. Address Request and Assignment Messages
A NMP host broadcasts an Address Request (AR) message to request an A NMP host broadcasts an Address Request (AR) message to request an
address from the gateway of the NMP domain. The gateway sends an address from the gateway of the NMP domain. The gateway sends an
Address Assignment (AA) message to the host to configure the host's Address Assignment (AA) message to the host to configure the host's
NMP address. #### Format of Address Request The value of the message NMP address. #### Format of Address Request The value of the message
Type is 0b000 0001. The message body is defined as follows. Type is 1. The message body is defined as follows.
+-------------------+-----------+ +-------------------+-----------+
| ID length (8 bits) | Host ID | | ID length (8 bits) | Host ID |
+-------------------+-----------+ +-------------------+-----------+
* ID length Length of this field is 1 octet. This header specifies o ID length Length of this field is 1 octet. This header specifies
the length of the Host ID field, in octets. the length of the Host ID field, in octets.
* Host ID Indicates the identifier of the host that accesses the NMP o Host ID Indicates the identifier of the host that accesses the NMP
network. The identifier can be a MAC address or another globally network. The identifier can be a MAC address or another globally
unique identifier. unique identifier.
4.2.1.1. Format of Address Assignment 4.2.1.1. Format of Address Assignment
The value of the message Type is 0b000 0010. The message body is The value of the message Type is 2. The message body is defined as
defined as follows. follows.
+-------------------+---------+---------+-----------+--------+ +-------------------+---------+---------+-----------+--------+
|NMP Address Length | NMP | Gateway | ID length | Host ID| |NMP Address Length | NMP | Gateway | ID length | Host ID|
| 8 bits | Address | Address | (8 bits) | | | 8 bits | Address | Address | (8 bits) | |
+-------------------+---------+---------+-----------+--------+ +-------------------+---------+---------+-----------+--------+
* NMP Address Length Length of this field is 1 octet. This o NMP Address Length Length of this field is 1 octet. This
parameter specifies the length of the NMP address used in the parameter specifies the length of the NMP address used in the
local NMP domain. local NMP domain.
* NMP Address Network layer address assigned to the host node. The o NMP Address Network layer address assigned to the host node. The
length is specified by the NMP Address Length field. length is specified by the NMP Address Length field.
* Gateway Address Network layer address of the gateway. The length o Gateway Address Network layer address of the gateway. The length
is the same as length of NMP Address is the same as length of NMP Address
* ID length Length of this field is 1 octet. This header specifies o ID length Length of this field is 1 octet. This header specifies
the length of the Host ID field, in octets. the length of the Host ID field, in octets.
* Host ID Indicates the identifier of the host that accesses the NMP o Host ID Indicates the identifier of the host that accesses the NMP
network. The identifier can be a MAC address or another globally network. The identifier can be a MAC address or another globally
unique identifier. unique identifier.
4.2.2. Address Lease Extension Messages 4.2.2. Address Lease Extension Messages
To reduce the complexity of the NMP host, the gateway records the To reduce the complexity of the NMP host, the gateway records the
lease information of each NMP address. When the lease of a host lease information of each NMP address. When the lease of a host
address expires, the gateway sends a Renewal Challenge message to the address expires, the gateway sends a Renewal Challenge message to the
host and waits for an response from the host. If a Renewal Response host and waits for an response from the host. If a Renewal Response
message is received from the host, the lease information is updated message is received from the host, the lease information is updated
based on the preconfigured strategy. Otherwise, the gateway releases based on the preconfigured strategy. Otherwise, the gateway releases
the NMP address. the NMP address.
4.2.2.1. Renewal Challenge Message 4.2.2.1. Renewal Challenge Message
The value of the message Type is 0b000 0011. The message body is The value of the message Type is 3. The message body is defined as
defined as follows. follows.
+-------------------+---------+-----------+--------+ +-------------------+---------+-----------+--------+
|NMP Address Length | NMP | ID length | Host ID| |NMP Address Length | NMP | ID length | Host ID|
| 8 bits | Address | (8 bits) | | | 8 bits | Address | (8 bits) | |
+-------------------+---------+-----------+--------+ +-------------------+---------+-----------+--------+
* NMP Address Length Length of this field is 1 octet. This o NMP Address Length Length of this field is 1 octet. This
parameter specifies the length of the NMP address used in the parameter specifies the length of the NMP address used in the
local NMP domain. local NMP domain.
* NMP Address Network layer address assigned to the host node. The o NMP Address Network layer address assigned to the host node. The
length is specified by the NMP Address Length field. length is specified by the NMP Address Length field.
* ID length Length of this field is 1 octet. This header specifies o ID length Length of this field is 1 octet. This header specifies
the length of the Host ID field, in octets. the length of the Host ID field, in octets.
* Host ID Indicates the identifier of the host that accesses the NMP o Host ID Indicates the identifier of the host that accesses the NMP
network. The identifier can be a MAC address or another globally network. The identifier can be a MAC address or another globally
unique identifier. unique identifier.
4.2.2.2. Renewal Response Message 4.2.2.2. Renewal Response Message
The value of the message Type is 0b000 0100. The message body is The value of the message Type is 4. The message body is defined in
defined in Section 4.2.2.1. Section 4.2.2.1.
4.3. DNS Delegation Messages 4.3. DNS Delegation Messages
Many IoT products are written into the domain name of the IoT service Many IoT products are written into the domain name of the IoT service
platform when they are manufactured. The IP address of the server platform when they are manufactured. The IP address of the server
needs to be obtained through the DNS to establish communication. needs to be obtained through the DNS to establish communication.
Within the NMP domain, some modifications are required to traditional Within the NMP domain, some modifications are required to traditional
DNS messages in [RFC1035]. The NMP host sends a DNS query packet to DNS messages in [RFC1035]. The NMP host sends a DNS query packet to
the gateway. The Indicator field of the packet is set to 0, and the the gateway. It Must set next header indicator to 1, the value of
DNS bit of the bitmap is set to 1. Destination of the packet is set in-line next header is 17. Destination port in UDP header is 53.
to NMP address of gateway. When the gateway receives the packet, it Destination of the packet is set to NMP address of gateway. When the
directly translates the network layer information and sends a regular gateway receives the packet, it directly translates the network layer
DNS packet to the DNS server configured on the gateway. information and sends a regular DNS packet to the DNS server
configured on the gateway.
NMP is replaced by IPv6 protocol after the gateway. The source NMP is replaced by IPv6 protocol after the gateway. The source
address is changed to 'IPv6 address prefix stored in the gateway + address is changed to 'IPv6 address prefix stored in the gateway +
padding bit + NMP address', the destination address is changed to the padding bit + NMP address', the destination address is changed to the
DNS server address configured on the gateway, and the payload DNS server address configured on the gateway, and the payload
information remains unchanged. information remains unchanged.
When the DNS response packet sent by the DNS server reaches the When the DNS response packet sent by the DNS server reaches the
gateway, the gateway resolves the response packet and allocates an gateway, the gateway resolves the response packet and allocates an
available NMP address to the destination IPv6 address. The NMP available NMP address to the destination IPv6 address. The NMP
address is used as an in-network mirror of the IPv6 address and address is used as an in-network mirror of the IPv6 address and
replaces the target address in the DNS response packet. Then, the replaces the target address in the DNS response packet. Then, the
gateway sends the DNS response packet to the NMP host. gateway sends the DNS response packet to the NMP host.
The header format of an DNS delegation message is defined as follows. The header format of an DNS delegation message is defined as follows.
For details about the format of a DNS message body, see [RFC1035]. For details about the format of a DNS message body, see [RFC1035].
+-+---------+---------+---------+---------+------------+-----------+ +-+---------+---------+---------+---------+------------+-----------+
|0| 1111111 | gw addr | NMP src | Nxt Hdr | pld length | hchecksum | |0| 0110110 | Total Length | Nxt Hdr | GW Addr | NMP src |
+-+---------+---------+---------+---------+------------+-----------+ +-+---------+---------+---------+---------+------------+-----------+
| UDP header | | | UDP header(port=53) | |
+---------------------+ + +---------------------+ +
| | | |
| DNS message body defined in RFC 1035 | | DNS message body defined in RFC 1035 |
| | | |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
4.4. Functionalities of Gateway 4.4. Functionalities of Gateway
4.4.1. Address Management 4.4.1. Address Management
The NMP gateway initializes the NMP address pool based on the network The NMP gateway initializes the NMP address pool based on the network
configuration and assigns an address to itself. This address is used configuration and assigns an address to itself. This address is used
as the default gateway by the hosts in the domain. as the default gateway by the hosts in the domain.
Intra-domain address management functionaliteis includes: * intra- Intra-domain address management functionaliteis includes: * intra-
domain host address allocation The gateway listens to the NMP address domain host address allocation The gateway listens to the NMP address
request message, allocates the corresponding NMP address based on the request message, allocates the corresponding NMP address based on the
message content, generates an address assignment message, and returns message content, generates an address assignment message, and returns
the message to the host. The assigned addresses must meet the the message to the host. The assigned addresses must meet the
uniqueness requirements within the NMP domain. * intra-domain host uniqueness requirements within the NMP domain. * intra-domain host
address life cycle management The gateway manages the validity period address life cycle management The gateway manages the validity period
of NMP addresses. The lease renewal challenge mechanism is used to of NMP addresses. The lease renewal challenge mechanism is used to
renew or release host addresses. renew or release host addresses.
4.4.2. Address Translation 4.4.2. Address Translation
The NMP address space can be mapped to specific subspaces of IPv6 The NMP address space can be mapped to specific subspaces of IPv6
address space. When traffic is destinated to a destination outside address space. When traffic is destinated to a destination outside
the domain, the gateway translates the host address (source address) the domain, the gateway translates the host address (source address)
in the domain into an IPv6 address. For details about the in the domain into an IPv6 address. For details about the
skipping to change at page 10, line 34 skipping to change at page 10, line 42
If NMP is running on Ethernet, a new Ethtype is required. In If NMP is running on Ethernet, a new Ethtype is required. In
addition to Ethernet, other link-layer protocols that need to carry addition to Ethernet, other link-layer protocols that need to carry
multiple upper-layer protocols need to assign specific identifiers to multiple upper-layer protocols need to assign specific identifiers to
NMP to instruct devices to process network-layer packets according to NMP to instruct devices to process network-layer packets according to
this document. this document.
This document requires to define new registry for NMP control message This document requires to define new registry for NMP control message
types, six of which are defined in this document. types, six of which are defined in this document.
8. Normative References 8. Acknowledgments
The authors would like to acknowledge the contributions Guangpeng Li
and Zhaochen Shi provided during the development of the solution.
9. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 11, line 14 skipping to change at page 11, line 28
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W.
George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, George, "IPv6 Site Renumbering Gap Analysis", RFC 7010,
DOI 10.17487/RFC7010, September 2013, DOI 10.17487/RFC7010, September 2013,
<https://www.rfc-editor.org/info/rfc7010>. <https://www.rfc-editor.org/info/rfc7010>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Author's Address Authors' Addresses
Sheng Jiang Sheng Jiang
Huawei Technologies Huawei Technologies
Beiqing Road, Haidian District Beiqing Road, Haidian District
Beijing Beijing 100095
100095 P.R. China
China
Email: jiangsheng@huawei.com Email: jiangsheng@huawei.com
Zhe Chen
Huawei Technologies
Beiqing Road, Haidian District
Beijing 100095
China
Email: chenzhe17@huawei.com
 End of changes. 56 change blocks. 
84 lines changed or deleted 89 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/