< draft-han-tsvwg-ip-transport-qos-00.txt   draft-han-tsvwg-ip-transport-qos-01.txt >
TSVWG Working Group L. Han TSVWG Working Group L. Han
Internet-Draft Y. Qu Internet-Draft Y. Qu
Intended status: Informational L. Dong Intended status: Informational L. Dong
Expires: January 3, 2019 Huawei Technologies Expires: April 22, 2019 R. Li
Huawei Technologies
T. Nadeau T. Nadeau
Lucid Vision Lucid Vision
K. Smith K. Smith
Vodafone Vodafone
July 2, 2018 J. Tantsura
Apstra
October 19, 2018
Resource Reservation Protocol for IP Transport QoS Resource Reservation Protocol for IP Transport QoS
draft-han-tsvwg-ip-transport-qos-00 draft-han-tsvwg-ip-transport-qos-01
Abstract Abstract
IP has been known as best-effort data transmission. However there IP is designed for use in Best Effort Networks, which are networks
are new applications requiring IP to provide deterministic services that provide no guarantee that data is delivered, or that delivery
in terms of bandwidth and latency, such as network based AR/VR meets any specified quality of service parameters. However there are
new applications requiring IP to provide deterministic services in
terms of bandwidth and latency, such as network based AR/VR
(Augmented Reality and Virtual Reality), industrial internet. This (Augmented Reality and Virtual Reality), industrial internet. This
document proposes a solution in IPv6 that can be used by transport document proposes a solution in IPv6 that can be used by transport
layer protocols to guarantee certain level of service quality. This layer protocols to guarantee certain level of service quality. This
new service is fined-grained and could apply to individual or new service is fined-grained and could apply to individual or
aggregated TCP/UDP flow(s). aggregated TCP/UDP flow(s).
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 42 skipping to change at page 1, line 47
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 January 3, 2019. This Internet-Draft will expire on April 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Design Targets . . . . . . . . . . . . . . . . . . . . . 6 3.1. Design Targets . . . . . . . . . . . . . . . . . . . . . 6
3.2. Scope and Assumptions . . . . . . . . . . . . . . . . . . 6 3.2. Scope and Assumptions . . . . . . . . . . . . . . . . . . 7
3.3. Sub-layer in IP for Transport Control . . . . . . . . . . 7 3.3. Sub-layer in IP for Transport Control . . . . . . . . . . 7
3.4. IP In-band signaling . . . . . . . . . . . . . . . . . . 8 3.4. IP In-band signaling . . . . . . . . . . . . . . . . . . 8
3.5. IPv6 Approach . . . . . . . . . . . . . . . . . . . . . . 8 3.5. IPv6 Approach . . . . . . . . . . . . . . . . . . . . . . 9
4. Key Messages and Parameters . . . . . . . . . . . . . . . . . 10 4. Key Messages and Parameters . . . . . . . . . . . . . . . . . 10
4.1. Setup and Setup State Report messages . . . . . . . . . . 10 4.1. Setup and Setup State Report messages . . . . . . . . . . 10
4.2. Forwarding State and Forwarding State Report messages . . 11 4.2. Forwarding State and Forwarding State Report messages 11
4.3. Hop Number . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Hop Number . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Flow Identifying Method and Service ID . . . . . . . . . 12 4.4. Flow Identifying Method and Service ID . . . . . . . . . 13
4.5. QoS State and life of Time . . . . . . . . . . . . . . . 13 4.5. QoS State and life of Time . . . . . . . . . . . . . . . 14
4.6. Authentication . . . . . . . . . . . . . . . . . . . . . 13 4.6. Authentication . . . . . . . . . . . . . . . . . . . . . 14
5. Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . 13 5. Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Basic Hardware Capability . . . . . . . . . . . . . . . . 14 5.1. Basic Hardware Capability . . . . . . . . . . . . . . . . 15
5.2. Flow Identification in Packet Forwarding . . . . . . . . 14 5.2. Flow Identification in Packet Forwarding . . . . . . . . 15
5.3. QoS Forwarding State Detection and Failure Handling . . . 15 5.3. QoS Forwarding State Detection and Failure Handling . . . 16
6. Details of Working with Transport Layer . . . . . . . . . . . 16 6. Details of Working with Transport Layer . . . . . . . . . . . 17
6.1. Working with TCP . . . . . . . . . . . . . . . . . . . . 16 6.1. Working with TCP . . . . . . . . . . . . . . . . . . . . 17
6.2. Working with UDP and other Protocols . . . . . . . . . . 18 6.2. Working with UDP and other Protocols . . . . . . . . . . 19
7. Additional Considerations . . . . . . . . . . . . . . . . . . 19 7. Additional Considerations . . . . . . . . . . . . . . . . . . 20
7.1. User and Application driven . . . . . . . . . . . . . . . 19 7.1. User and Application driven . . . . . . . . . . . . . . . 20
7.2. Traffic Management in Host . . . . . . . . . . . . . . . 20 7.2. Traffic Management in Host . . . . . . . . . . . . . . . 21
7.3. Heterogeneous Network . . . . . . . . . . . . . . . . . . 20 7.3. Heterogeneous Network . . . . . . . . . . . . . . . . . . 21
7.4. Proxy Control . . . . . . . . . . . . . . . . . . . . . . 21 7.4. Proxy Control . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Appendix B. Message Objects . . . . . . . . . . . . . . . . . . 26 Appendix B. Message Objects . . . . . . . . . . . . . . . . . . 28
B.1. Setup State Object . . . . . . . . . . . . . . . . . . . 26 B.1. Setup State Object . . . . . . . . . . . . . . . . . . . 28
B.2. Bandwidth Object . . . . . . . . . . . . . . . . . . . . 27 B.2. Bandwidth Object . . . . . . . . . . . . . . . . . . . . 30
B.3. Burst Msg . . . . . . . . . . . . . . . . . . . . . . . . 27 B.3. Burst Msg . . . . . . . . . . . . . . . . . . . . . . . . 30
B.4. Latency Object . . . . . . . . . . . . . . . . . . . . . 27 B.4. Latency Object . . . . . . . . . . . . . . . . . . . . . 31
B.5. Authentication Object . . . . . . . . . . . . . . . . . . 28 B.5. Authentication Object . . . . . . . . . . . . . . . . . . 31
B.6. OAM Object . . . . . . . . . . . . . . . . . . . . . . . 28 B.6. OAM Object . . . . . . . . . . . . . . . . . . . . . . . 32
B.7. Forwarding State Object . . . . . . . . . . . . . . . . . 29 B.7. Forwarding State Object . . . . . . . . . . . . . . . . . 33
B.8. Setup State Report Object . . . . . . . . . . . . . . . . 29 B.8. Setup State Report Object . . . . . . . . . . . . . . . . 33
B.9. Forward State Report Object . . . . . . . . . . . . . . . 30 B.9. Forward State Report Object . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Recently, more and more new applications for The Internet are Recently, more and more new applications for The Internet are
emerging. These applications have a number of key requirements that emerging. These applications have a number of key requirements that
are common to all such as that their required bandwidth is very high are common to all such as that their required bandwidth is very high
and/or latency is very low compared with traditional applications and/or latency is very low compared with traditional applications
like most of web and video applications. like most of web and video applications.
For example, network based AR or VR applications may need a couple of For example, network based Augmented Reality (AR) or Virtual Reality
hundred Mbps bandwidth (throughput) and a low single digit (VR) applications may need hundreds of Mbps bandwidth (throughput)
millisecond latency. Moreover, the difference between mean bit rate and a low single digit millisecond latency. Moreover, the difference
and peak bit rate is significant due to the usage of compression between mean bit rate and peak bit rate may be significant due to the
algorithm [I-D.han-iccrg-arvr-transport-problem], and this may cause choice of compression algorithm
large burst and make traffic management more difficult. [I-D.han-iccrg-arvr-transport-problem]. This may result in large
bursts, and make traffic management more difficult.
Some future applications may expect network to provide a bounded Some future applications may expect networks to provide a bounded
latency service, and one such example is tactile network [Tactile]. latency service. One such example is tactile network [Tactile].
With the technology development in 5G [HU5G][QU2016] and beyond, the With the technology development in 5G [HU5G][QU2016] and beyond, the
wireless access network is also rising the demand for the Ultra- wireless access network is also increasing the demand for the Ultra-
Reliable and Low-Latency Communications (URLLC), this also leads to Reliable and Low-Latency Communications (URLLC). This also leads to
the question if IP can provide such service in Evolved Packet Core the question of whether IP can provide such service in an Evolved
(EPC) network. IP is becoming more and more important in EPC when Packet Core (EPC)[EPC] network. IP is becoming more and more
the Multi-access Edge Computing (MEC) for 5G requires the cloud and important in the EPC when the Multi-access Edge Computing (MEC)[MEC]
data service moving closer to eNodeB. for 5G requires the cloud and data service to move closer to eNodeB
[eNodeB].
Traditional IP network provides an unreliable or best-effort data [I-D.ietf-detnet-use-cases] identifies some use cases from different
gram service over some underlying network (i.e.: ethernet, ATM, industries which have a common need for "deterministic flows". Such
etc...). The transport layer (TCP/UDP) on top of IP is based on this flows require guaranteed bandwidth and bounded latency.
fundamental architecture. The best-effort-only service has
influenced the transport evolution for quite long time, and results Traditionally, an IP network provides an unreliable or best-effort
in some widely accepted assumptions and solutions, such as: datagram service over a collection of underlying networks (i.e.:
ethernet, ATM, etc...). Integrated services(IntServ) [RFC3175]
specifies a fine-grained QoS system, which requires all routers along
the traffic path to support it and maintain the states for resource
reserved IP flow(s), so it is difficult to scale up to keep track of
all the reservations. Differentiated services (DiffServ) [RFC2475]
specifies a simple and scalable mechanism to classify traffic and
provide more coarse QoS, however because it can only specify per-hop
behaviors (PHBs), and how individual routers deal with the DS
[RFC2474] field is configuration specific. It is difficult to
provide consistent resource reservation for specified class of
traffic, thus hard to support the end-to-end bandwidth or latency
guarantee.
The transport layer (TCP/UDP) on top of IP is based on the best-
effort-only service, which has influenced the transport layer
evolution for quite long time, and results in some widely accepted
assumptions and solutions, such as:
1. The IP layer can only provide basic P2P (point to point) or P2MP 1. The IP layer can only provide basic P2P (point to point) or P2MP
(point to multi-point) end-to-end connectivity in the Internet, (point to multi-point) end-to-end connectivity in the Internet,
but the connectivity is not reliable and does not guarantee any but the connectivity is not reliable and does not guarantee any
quality of service to end-user or application, such as bandwidth, quality of service to end-user or application, such as bandwidth,
packet loss, latency etc. Due to this assumption, the transport packet loss, latency etc. Due to this assumption, the transport
layer or application must have its own control mechanism in layer or application must have its own control mechanism in
congestion and flow to obtain the reliable and satisfactory congestion and flow to obtain the reliable and satisfactory
service to cooperate with the under layer network quality. service to cooperate with the under layer network quality.
skipping to change at page 4, line 25 skipping to change at page 4, line 50
This document proposes a new IP transport service that guarantees This document proposes a new IP transport service that guarantees
bandwidth and latency for new applications. The scope and criteria bandwidth and latency for new applications. The scope and criteria
for the new technology will also be discussed. This new IP transport for the new technology will also be discussed. This new IP transport
service is designed to be supplementary to regular IP transport service is designed to be supplementary to regular IP transport
services, only meant to be used for special applications that are services, only meant to be used for special applications that are
bandwidth and/or latency sensitive. bandwidth and/or latency sensitive.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
appear in all capitals, as shown here.
Abbreviations used in this documents: Abbreviations used in this documents:
E2E E2E
End-to-end. End-to-end.
EH EH
IPv6 Extension Header or Extension Option. IPv6 Extension Header or Extension Option.
QoS QoS
skipping to change at page 5, line 41 skipping to change at page 6, line 20
HbH-EH-aware node HbH-EH-aware node
Network nodes that are configured to process the IPv6 Hop-by- Network nodes that are configured to process the IPv6 Hop-by-
Hop Extension Header. Hop Extension Header.
3. Overview 3. Overview
Semiconductor chip technology has advanced significantly in the last Semiconductor chip technology has advanced significantly in the last
decade, and as such the widely used network processing and forwarding decade, and as such the widely used network processing and forwarding
process can now not only forward packets at line speed, but also process can now not only forward packets at line speed, but also
easily support other feature processing such as Qos for DiffServ/ easily support other feature processing such as QoS for DiffServ/
MPLS, Access Control List (ACL), fire wall, and Deep Packet MPLS, Access Control List (ACL), fire wall, and Deep Packet
Inspection (DPI). Inspection (DPI).
This advancement enables network processors to do the general process This advancement enables network processors to do the general process
to handle simple control messages for traffic management, such as to handle simple control messages for traffic management, such as
signaling for hardware programming, congestion state report, OAM, signaling for hardware programming, congestion state report, OAM,
etc. So now it's possible to treat some TCP/IP flows differently etc. So now it's possible to treat some TCP/IP flows differently
from others and give them specified resource are feasible now by from others and give them specified resource are feasible now by
using network processor. using network processor.
skipping to change at page 10, line 47 skipping to change at page 11, line 30
those worst-cast devices to process the HbH-EH. those worst-cast devices to process the HbH-EH.
Setup State Report message is the message sent from the destination Setup State Report message is the message sent from the destination
host to the source host (from the point of view of the Setup host to the source host (from the point of view of the Setup
message). The message is embedded into the Dst-EH in any data message). The message is embedded into the Dst-EH in any data
packet. The Setup State Report in the message is just a copy from packet. The Setup State Report in the message is just a copy from
the Setup message received at the destination host for a typical TCP the Setup message received at the destination host for a typical TCP
session. The message is used at the source host to forward the session. The message is used at the source host to forward the
packet later and to do the congestion control. packet later and to do the congestion control.
<Setup Message> ::= <Setup State Object> [ <Bandwidth Object> ] <Setup Message> ::= <Setup State Object> [ <Bandwidth
[ <Burst Object> ] [ <Latency Object> ] Object> ]
[ <OAM Object> ] [ <Authentication Object> ] [ <Burst Object> ] [ <Latency
<Setup State Report Message> ::= <Setup State Report Object> Object> ]
[ <OAM Object> ] [ <Authentication
Object> ]
<Setup State Report Message> ::= <Setup State Report
Object>
[ <OAM Object> ] [ <OAM Object> ]
4.2. Forwarding State and Forwarding State Report messages 4.2. Forwarding State and Forwarding State Report messages
After the QoS is programmed by the in-band signaling, the specified After the QoS is programmed by the in-band signaling, the specified
IP flows can be processed and forwarded for the QoS requirement. IP flows can be processed and forwarded for the QoS requirement.
There are two ways for host to use the QoS channel for associated TCP There are two ways for host to use the QoS channel for associated TCP
session: session:
1. Host directly send the IP packet without any changes to the 1. Host directly send the IP packet without any changes to the
skipping to change at page 11, line 43 skipping to change at page 12, line 33
Forwarding State message format is shown in the Section 6.7. It is Forwarding State message format is shown in the Section 6.7. It is
used to notify the service ID and also update QoS forwarding state used to notify the service ID and also update QoS forwarding state
for the hops that are HbH-EH-aware nodes. for the hops that are HbH-EH-aware nodes.
After Forwarding State message is reaching the destination host, the After Forwarding State message is reaching the destination host, the
host is supposed to retrieve it and form a Forwarding State Report host is supposed to retrieve it and form a Forwarding State Report
message, and carry it in any data packet as the Dst-EH, then send it message, and carry it in any data packet as the Dst-EH, then send it
to the host in the reverse direction. to the host in the reverse direction.
<Forward State Message> ::= <Forward State Object> [ <Latency Object> ] <Forward State Message> ::= <Forward State Object> [
[ <OAM Object> ] [ <Authentication Object> ] <Latency Object> ]
<Forward State Report Message> ::= <Forward State Report Object> [ <OAM Object> ] [ <Authentication
[ <OAM Object> ] Object> ]
<Forward State Report Message> ::= <Forward State Report
Object>
[ <OAM Object> ]
4.3. Hop Number 4.3. Hop Number
This is the parameter for total number of HbH-EH-aware nodes on the This is the parameter for total number of HbH-EH-aware nodes on the
path. It is the field "Hop_num" in Setup message, and is used to path. It is the field "Hop_num" in Setup message, and is used to
locate the bit position for "Setup State" and the "Service ID" in locate the bit position for "Setup State" and the "Service ID" in
"Service ID List". The value of "Hop_num" must be decremented at "Service ID List". The value of "Hop_num" must be decremented at
each HbH-EH-aware node. At the receiving host of the in-band each HbH-EH-aware node. At the receiving host of the in-band
signaling, the Hop_num must be zero. signaling, the Hop_num must be zero.
The source host must know the exact hop number, and setup the initial The source host must know the exact hop number, and setup the initial
value in the Setup message. The exact hop number can be detected value in the Setup message. The exact hop number can be detected
using OAM message. using OAM message.
4.4. Flow Identifying Method and Service ID 4.4. Flow Identifying Method and Service ID
A QoS channel might be enforced for a group of flows or a delicate A QoS channel might be enforced for a group of flows or a delicate
flow, and flow identifying method means the way of identfying a flow flow, and flow identifying method means the way of identifying a flow
or a group of flows that can use a HW programmed QoS channel. or a group of flows that can use a HW programmed QoS channel.
Different levels of flow granularities to support QoS are defined as Different levels of flow granularities to support QoS are defined as
below: below:
Flow level Flow level
The flow identification could be 5 tuples for non IPSec IPv6 The flow identification could be 5 tuples for non IPSec IPv6
packet: the source, destination IP address, protocol number, packet: the source, destination IP address, protocol number,
source and destination port number, and also could be 3 tuples for source and destination port number, and also could be 3 tuples for
IPSec IPv6 packet: the source, destination IP address and the flow IPSec IPv6 packet: the source, destination IP address and the flow
label. label.
skipping to change at page 14, line 39 skipping to change at page 15, line 39
4. The data forwarding does not need to be done at the controller 4. The data forwarding does not need to be done at the controller
CPU, or so called slow path. It is at the same hardware as the CPU, or so called slow path. It is at the same hardware as the
normal IP forwarding. For any IP packet, the QoS forwarding is normal IP forwarding. For any IP packet, the QoS forwarding is
executed first. Normal forwarding will be executed if there is executed first. Normal forwarding will be executed if there is
no QoS state associated with the identification of the flow. no QoS state associated with the identification of the flow.
5. The QoS forwarding and normal forwarding can be switched on the 5. The QoS forwarding and normal forwarding can be switched on the
fly. fly.
The details of data plane and hardware related implementations, such
as traffic classification, shaping, queuing and scheduling, are out
of scope of this document. The report of [NGP] has given some
experiments and results by using commercial hardwares.
5.2. Flow Identification in Packet Forwarding 5.2. Flow Identification in Packet Forwarding
Flow identification in Packet Forwarding is same as the QoS channel Flow identification in Packet Forwarding is same as the QoS channel
establishment by Setup message. It is to forward a packet with a establishment by Setup message. It is to forward a packet with a
specified QoS process if the packet is identified to be belonging to specified QoS process if the packet is identified to be belonging to
specified flow(s). specified flow(s).
There are two method used in data forwarding to identify flows: There are two method used in data forwarding to identify flows:
1. Hardware was programmed to use tuples in IP header implicitly. 1. Hardware was programmed to use tuples in IP header implicitly.
skipping to change at page 23, line 48 skipping to change at page 25, line 5
[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>.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, DOI 10.17487/RFC2581, April 1999, Control", RFC 2581, DOI 10.17487/RFC2581, April 1999,
<https://www.rfc-editor.org/info/rfc2581>. <https://www.rfc-editor.org/info/rfc2581>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
10.2. Informative References 10.2. Informative References
[eNodeB] wikipedia, "eNodeB", 2018,
<https://en.wikipedia.org/wiki/ENodeB>.
[EPC] 3GPP, "The Evolved Packet Core", 2018,
<http://www.3gpp.org/technologies/keywords-acronyms/ 100-
the-evolved-packet-core>.
[HU5G] Huawei, "5G Vision: 100 Billion connections, 1 ms Latency, [HU5G] Huawei, "5G Vision: 100 Billion connections, 1 ms Latency,
and 10 Gbps Throughput", 2015, and 10 Gbps Throughput", 2015,
<http://www.huawei.com/minisite/5g/en/defining-5g.html>. <http://www.huawei.com/minisite/5g/en/defining-5g.html>.
[I-D.falk-xcp-spec] [I-D.falk-xcp-spec]
Falk, A., "Specification for the Explicit Control Protocol Falk, A., "Specification for the Explicit Control Protocol
(XCP)", draft-falk-xcp-spec-03 (work in progress), July (XCP)", draft-falk-xcp-spec-03 (work in progress), July
2007. 2007.
[I-D.han-iccrg-arvr-transport-problem] [I-D.han-iccrg-arvr-transport-problem]
skipping to change at page 25, line 5 skipping to change at page 26, line 18
FlowQueue-CoDel Packet Scheduler and Active Queue FlowQueue-CoDel Packet Scheduler and Active Queue
Management Algorithm", draft-ietf-aqm-fq-codel-06 (work in Management Algorithm", draft-ietf-aqm-fq-codel-06 (work in
progress), March 2016. progress), March 2016.
[I-D.ietf-aqm-pie] [I-D.ietf-aqm-pie]
Pan, R., Natarajan, P., Baker, F., and G. White, "PIE: A Pan, R., Natarajan, P., Baker, F., and G. White, "PIE: A
Lightweight Control Scheme To Address the Bufferbloat Lightweight Control Scheme To Address the Bufferbloat
Problem", draft-ietf-aqm-pie-10 (work in progress), Problem", draft-ietf-aqm-pie-10 (work in progress),
September 2016. September 2016.
[I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-19 (work in progress), October 2018.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018. in progress), January 2018.
[I-D.ietf-tcpm-dctcp] [I-D.ietf-tcpm-dctcp]
Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P., Bensley, S., Eggert, L., Thaler, D., Balasubramanian, P.,
and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion
Control for Datacenters", draft-ietf-tcpm-dctcp-03 (work Control for Datacenters", draft-ietf-tcpm-dctcp-03 (work
skipping to change at page 25, line 33 skipping to change at page 26, line 50
Sridharan, M., Tan, K., Bansal, D., and D. Thaler, Sridharan, M., Tan, K., Bansal, D., and D. Thaler,
"Compound TCP: A New TCP Congestion Control for High-Speed "Compound TCP: A New TCP Congestion Control for High-Speed
and Long Distance Networks", draft-sridharan-tcpm-ctcp-02 and Long Distance Networks", draft-sridharan-tcpm-ctcp-02
(work in progress), November 2008. (work in progress), November 2008.
[IPv6_Parameters] [IPv6_Parameters]
IANA, "Internet Protocol Version 6 (IPv6) Parameters", IANA, "Internet Protocol Version 6 (IPv6) Parameters",
2015, <https://www.iana.org/assignments/ipv6-parameters/ 2015, <https://www.iana.org/assignments/ipv6-parameters/
ipv6-parameters.xhtml#ipv6-parameters-2>. ipv6-parameters.xhtml#ipv6-parameters-2>.
[MEC] ETSI, "Multi-access Edge Computing", 2018,
<https://www.etsi.org/technologies-clusters/technologies/
multi-access-edge-computing>.
[NGP] ETSI, "Next Generation Protocols (NGP); Recommendation for
New Transport Technologies", 2018,
<https://www.etsi.org/deliver/etsi_gr/
NGP/001_099/010/01.01.01_60/gr_NGP010v010101p.pdf>.
[QU2016] Qualcomm, "Leading the world to 5G", 2016, [QU2016] Qualcomm, "Leading the world to 5G", 2016,
<https://www.qualcomm.com/media/documents/files/ <https://www.qualcomm.com/media/documents/files/
qualcomm-5g-vision-presentation.pdf>. qualcomm-5g-vision-presentation.pdf>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, DOI 10.17487/RFC3175, September 2001,
<https://www.rfc-editor.org/info/rfc3175>.
[Tactile] JDavid Szabo, et al. Proceedings of European Wireless [Tactile] JDavid Szabo, et al. Proceedings of European Wireless
2015; 21th European Wireless Conference, "Towards the 2015; 21th European Wireless Conference, "Towards the
Tactile Internet: Decreasing Communication Latency with Tactile Internet: Decreasing Communication Latency with
Network Coding and Software Defined Networking", 2015, Network Coding and Software Defined Networking", 2015,
<http://fastpass.mit.edu/Fastpass-SIGCOMM14-Perry.pdf>. <http://fastpass.mit.edu/Fastpass-SIGCOMM14-Perry.pdf>.
[TCP-vegas] [TCP-vegas]
Peterson, L., "TCP Vegas: New Techniques for Congestion Peterson, L., "TCP Vegas: New Techniques for Congestion
Detection and Avoidance - CiteSeer page on the 1994 Detection and Avoidance - CiteSeer page on the 1994
SIGCOMM paper", 1994. SIGCOMM paper", 1994.
[TCP_Targets] [TCP_Targets]
Andreas Benthin, Stefan Mischke, University of Paderborn, Andreas Benthin, Stefan Mischke, University of Paderborn,
"Bandwidth Allocation of TCP", 2004. "Bandwidth Allocation of TCP", 2004.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors are very grateful to Fred Baker for his valuable
contributions to this document.
We appreciate the following people who made lots of contributions to We appreciate the following people who made lots of contributions to
this draft: Guoping Li, Boyan Tu, and Xuefei Tan, and thank Huawei this draft: Guoping Li, Boyan Tu, and Xuefei Tan, and thank Huawei
Nanjing research team led by Feng Li to provide the Product on Nanjing research team led by Feng Li to provide the Product on
Concept (POC) development and test, the team members include Fengxin Concept (POC) development and test, the team members include Fengxin
Sun, Xingwang Zhou, and Weiguang Wang. We also like to thank other Sun, Xingwang Zhou, and Weiguang Wang. We also like to thank other
people involved in the discussion of solution: Tao Ma from Future people involved in the discussion of solution: Tao Ma from Future
Network Strategy dept. Network Strategy dept.
Appendix B. Message Objects Appendix B. Message Objects
This section defines detailed objects used in different messages. This section defines detailed objects used in different messages.
B.1. Setup State Object B.1. Setup State Object
0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|ver| FI|R|SIS|P| Time | Hop_num |u| Total_latency | |0 0 0 0|ver| FI|R|SIS|P| Time | Hop_num |u| Total_latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State for each hop index | | State for each hop index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service ID list for hops | | Service ID list for hops |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-. . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-. . . +
Type = 0, Setup state; Type = 0, Setup state;
skipping to change at page 27, line 20 skipping to change at page 30, line 20
The Setup object is embedded into the hop-by-hop EH to setup the QoS The Setup object is embedded into the hop-by-hop EH to setup the QoS
in the device on the IP forwarding path. To keep the whole setup in the device on the IP forwarding path. To keep the whole setup
message size unchanged at each hop, the total hop number must be message size unchanged at each hop, the total hop number must be
known at the source host. The total hop number can be detected by known at the source host. The total hop number can be detected by
OAM. The service ID list is empty before the 1st hop receives the OAM. The service ID list is empty before the 1st hop receives the
in-band signaling. Each hop then fill up the associated service ID in-band signaling. Each hop then fill up the associated service ID
into the correct place determined by the index of the hop. into the correct place determined by the index of the hop.
B.2. Bandwidth Object B.2. Bandwidth Object
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1| reserved | Minimum bandwidth | |0 0 0 1| reserved | Minimum bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum bandwidth | | Maximum bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = 1, Type = 1,
Minimum bandwidth : The minimum bandwidth required, or CIR, unit Mbps
Maximum bandwidth : The maximum bandwidth required, or PIR, unit Mbps Minimum bandwidth : The minimum bandwidth required, or CIR, unit
Mbps
Maximum bandwidth : The maximum bandwidth required, or PIR, unit
Mbps
Figure 6: The Bandwidth Object Figure 6: The Bandwidth Object
B.3. Burst Msg B.3. Burst Msg
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0| Burst size | |0 0 1 0| Burst size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = 2, Type = 2,
Burst size : The burst size, unit M bytes Burst size : The burst size, unit M bytes
Figure 7: The burst message Figure 7: The burst message
B.4. Latency Object B.4. Latency Object
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1|u| Latency | |0 0 1 1|u| Latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type = 3, Type = 3,
u: the unit of the latency u: the unit of the latency
0: ms; 1: us 0: ms; 1: us
Latency: Expected maximum latency for each hop Latency: Expected maximum latency for each hop
Figure 8: The Latency Object Figure 8: The Latency Object
B.5. Authentication Object B.5. Authentication Object
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0| MAC_ALG | res | MAC data (variable length) | |0 1 0 0| MAC_ALG | res | MAC data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. . .+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. . .+
Type = 4, Type = 4,
MAC_ALG: Message Authentication Algorithm MAC_ALG: Message Authentication Algorithm
0: MD5; 1:SHA-0; 2: SHA-1; 3: SHA-256; 4: SHA-512 0: MD5; 1:SHA-0; 2: SHA-1; 3: SHA-256; 4: SHA-512
MAC data: Message Authentication Data; MAC data: Message Authentication Data;
Res: Reserved bits Res: Reserved bits
Size of signaling data (opt_len): Size of MAC data + 2 Size of signaling data (opt_len): Size of MAC data + 2
MD5: 18; SHA-0: 22; SHA-1: 22; SHA-256: 34; SHA-512: 66 MD5: 18; SHA-0: 22; SHA-1: 22; SHA-256: 34; SHA-512: 66
Figure 9: The Authentication Object Figure 9: The Authentication Object
B.6. OAM Object B.6. OAM Object
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1| OAM_t | OAM_len | OAM data (variable length) | |0 1 0 1| OAM_t | OAM_len | OAM data (variable length) |
skipping to change at page 28, line 44 skipping to change at page 32, line 35
B.6. OAM Object B.6. OAM Object
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1| OAM_t | OAM_len | OAM data (variable length) | |0 1 0 1| OAM_t | OAM_len | OAM data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. . .+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. . .+
Type = 5, Type = 5,
OAM_t : OAM type OAM_t : OAM type
OAM_len : 8-bit unsigned integer. Length of the OAM data, in octets; OAM_len : 8-bit unsigned integer. Length of the OAM data, in octets;
OAM data: OAM data, details of OAM data are TBD. OAM data: OAM data, details of OAM data are TBD.
Figure 10: The OAM Object Figure 10: The OAM Object
B.7. Forwarding State Object B.7. Forwarding State Object
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0|ver| FI|R|SIS|P| Time | Hop_num |u| Total_latency | |0 1 1 0|ver| FI|R|SIS|P| Time | Hop_num |u| Total_latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding state for each hop index | | Forwarding state for each hop index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service ID list for hops | | Service ID list for hops |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-. . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-. . . +
Type = 6, Forwarding state; Type = 6, Forwarding state;
All parameter definitions and process in the 1st row are same in
the setup message. All parameter definitions and process in the 1st row are same in
Forward state for each hop index : each bit is the fwd state on each
hop on the path, 0: failed; 1: success; The 1st hop is at the the setup message.
most significant bit.
Service ID list for hops: it is for all hops on the path, each index bit Forward state for each hop index : each bit is the fwd state on
size is defined in SIS. The list is from the setup report message. each
hop on the path, 0: failed; 1: success; The 1st hop is at the
most significant bit.
Service ID list for hops: it is for all hops on the path, each index
bit
size is defined in SIS. The list is from the setup report message.
Figure 11: The Forwarding State Object Figure 11: The Forwarding State Object
B.8. Setup State Report Object B.8. Setup State Report Object
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1|ver|H|u| Total_latency | Reserved | |0 1 1 1|ver|H|u| Total_latency | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State for each hop index | | State for each hop index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service ID list for hops | | Service ID list for hops |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-. . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-. . . +
skipping to change at page 30, line 38 skipping to change at page 36, line 4
Authors' Addresses Authors' Addresses
Lin Han Lin Han
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Phone: +10 408 330 4613 Phone: +10 408 330 4613
Email: lin.han@huawei.com Email: lin.han@huawei.com
Yingzhen Qu Yingzhen Qu
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: yingzhen.qu@huawei.com Email: yingzhen.qu@huawei.com
Lijun Dong Lijun Dong
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: lijun.dong@huawei.com Email: lijun.dong@huawei.com
Richard Li
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: renwei.li@huawei.com
Thomas Nadeau Thomas Nadeau
Lucid Vision Lucid Vision
Hampton NH 03842 Hampton NH 03842
USA USA
Email: tnadeau@lucidvision.com Email: tnadeau@lucidvision.com
Kevin Smith Kevin Smith
Vodafone Vodafone
UK UK
Email: Kevin.Smith@vodafone.com Email: Kevin.Smith@vodafone.com
Jeff Tantsura
Apstra
Email: jefftant.ietf@gmail.com
 End of changes. 51 change blocks. 
109 lines changed or deleted 222 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/