< draft-han-tsvwg-ip-transport-qos-01.txt   draft-han-tsvwg-ip-transport-qos-02.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: April 22, 2019 R. Li Expires: October 19, 2019 R. Li
Huawei Technologies Huawei Technologies
T. Nadeau T. Nadeau
Lucid Vision Lucid Vision
K. Smith K. Smith
Vodafone Vodafone
J. Tantsura J. Tantsura
Apstra Apstra
October 19, 2018 April 17, 2019
Resource Reservation Protocol for IP Transport QoS Resource Reservation Protocol for IP Transport QoS
draft-han-tsvwg-ip-transport-qos-01 draft-han-tsvwg-ip-transport-qos-02
Abstract Abstract
IP is designed for use in Best Effort Networks, which are networks IP is designed for use in Best Effort Networks, which are networks
that provide no guarantee that data is delivered, or that delivery that provide no guarantee that data is delivered, or that delivery
meets any specified quality of service parameters. However there are meets any specified quality of service parameters. However there are
new applications requiring IP to provide deterministic services in new applications requiring IP to provide deterministic services in
terms of bandwidth and latency, such as network based AR/VR 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
skipping to change at page 1, line 47 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 April 22, 2019. This Internet-Draft will expire on October 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Design Targets . . . . . . . . . . . . . . . . . . . . . 6 3.1. Design Targets . . . . . . . . . . . . . . . . . . . . . 6
3.2. Scope and Assumptions . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . 9 3.5. IPv6 Approach . . . . . . . . . . . . . . . . . . . . . . 10
4. Key Messages and Parameters . . . . . . . . . . . . . . . . . 10 4. Key Messages and Parameters . . . . . . . . . . . . . . . . . 11
4.1. Setup and Setup State Report messages . . . . . . . . . . 10 4.1. Setup and Setup State Report messages . . . . . . . . . . 11
4.2. Forwarding State and Forwarding State Report messages 11 4.2. Forwarding State and Forwarding State Report messages 12
4.3. Hop Number . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Hop Number . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Flow Identifying Method and Service ID . . . . . . . . . 13 4.4. Flow Identifying Method and Service ID . . . . . . . . . 13
4.5. QoS State and life of Time . . . . . . . . . . . . . . . 14 4.5. QoS State and life of Time . . . . . . . . . . . . . . . 14
4.6. Authentication . . . . . . . . . . . . . . . . . . . . . 14 4.6. Authentication . . . . . . . . . . . . . . . . . . . . . 14
5. Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . 14 5. Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Basic Hardware Capability . . . . . . . . . . . . . . . . 15 5.1. Basic Hardware Capability . . . . . . . . . . . . . . . . 15
5.2. Flow Identification in Packet Forwarding . . . . . . . . 15 5.2. Flow Identification in Packet Forwarding . . . . . . . . 16
5.3. QoS Forwarding State Detection and Failure Handling . . . 16 5.3. QoS Forwarding State Detection and Failure Handling . . . 16
6. Details of Working with Transport Layer . . . . . . . . . . . 17 6. Details of Working with Transport Layer . . . . . . . . . . . 17
6.1. Working with TCP . . . . . . . . . . . . . . . . . . . . 17 6.1. Working with TCP . . . . . . . . . . . . . . . . . . . . 17
6.2. Working with UDP and other Protocols . . . . . . . . . . 19 6.2. Working with UDP and other Protocols . . . . . . . . . . 20
7. Additional Considerations . . . . . . . . . . . . . . . . . . 20 7. Additional Considerations . . . . . . . . . . . . . . . . . . 20
7.1. User and Application driven . . . . . . . . . . . . . . . 20 7.1. User and Application driven . . . . . . . . . . . . . . . 20
7.2. Traffic Management in Host . . . . . . . . . . . . . . . 21 7.2. Traffic Management in Host . . . . . . . . . . . . . . . 21
7.3. Heterogeneous Network . . . . . . . . . . . . . . . . . . 21 7.3. Heterogeneous Network . . . . . . . . . . . . . . . . . . 22
7.4. Proxy Control . . . . . . . . . . . . . . . . . . . . . . 22 7.4. Proxy Control . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28
Appendix B. Message Objects . . . . . . . . . . . . . . . . . . 28 Appendix B. Message Objects . . . . . . . . . . . . . . . . . . 29
B.1. Setup State Object . . . . . . . . . . . . . . . . . . . 28 B.1. Setup State Object . . . . . . . . . . . . . . . . . . . 29
B.2. Bandwidth Object . . . . . . . . . . . . . . . . . . . . 30 B.2. Bandwidth Object . . . . . . . . . . . . . . . . . . . . 31
B.3. Burst Msg . . . . . . . . . . . . . . . . . . . . . . . . 30 B.3. Burst Msg . . . . . . . . . . . . . . . . . . . . . . . . 31
B.4. Latency Object . . . . . . . . . . . . . . . . . . . . . 31 B.4. Latency Object . . . . . . . . . . . . . . . . . . . . . 32
B.5. Authentication Object . . . . . . . . . . . . . . . . . . 31 B.5. Authentication Object . . . . . . . . . . . . . . . . . . 32
B.6. OAM Object . . . . . . . . . . . . . . . . . . . . . . . 32 B.6. OAM Object . . . . . . . . . . . . . . . . . . . . . . . 33
B.7. Forwarding State Object . . . . . . . . . . . . . . . . . 33 B.7. Forwarding State Object . . . . . . . . . . . . . . . . . 34
B.8. Setup State Report Object . . . . . . . . . . . . . . . . 33 B.8. Setup State Report Object . . . . . . . . . . . . . . . . 34
B.9. Forward State Report Object . . . . . . . . . . . . . . . 34 B.9. Forward State Report Object . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
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 Augmented Reality (AR) or Virtual Reality For example, network based Augmented Reality (AR) or Virtual Reality
skipping to change at page 9, line 20 skipping to change at page 9, line 20
Simplicity Simplicity
The in-band signaling message is forwarded with the normal data The in-band signaling message is forwarded with the normal data
packet, it does not need to run a separate protocol. This will packet, it does not need to run a separate protocol. This will
dramatically reduce the complexity of the control. dramatically reduce the complexity of the control.
Performance and scalability Performance and scalability
Due to the simplicity of in-band signaling for control, it is Due to the simplicity of in-band signaling for control, it is
easier to provide a better performance and scalability for a new easier to provide a better performance and scalability for a new
future. future.
Note, the requirement of IP in-band signaling was proposed before by There have been similar works done or proposed in the industry for
John Harper [I-D.harper-inband-signalling-requirements]. And the in- quite some time. The in-band QoS signaling for IPv6 was discussed by
band QoS signaling for IPv6 was simply discussed in Lawrence Roberts in 2005 [I-D.roberts-inband-qos-ipv6]. The
[I-D.roberts-inband-qos-ipv6]. Unfortunately, both works did not requirements of IP in-band signaling was proposed by Jon Haper in
continue. 2007 [I-D.harper-inband-signalling-requirements]. Telecommunications
Industry Association (TIA) published a standard for "QoS Signaling
for IP QoS Support and Sender Authentication" in 2006 [TIA].
This document proposes a detailed solution for QoS service using in- This document proposes an optimized solution for QoS service using
band signaling, and it also tries to address issues raised by in-band signaling, and it also tries to address issues raised by
previous proposals, such as security, scalability and performance. previous proposals, such as security, scalability and performance.
The major differences from the previous works are:
1. Focus on IPv6 only.
2. The proposed solution could be driven by end-user operating
system's protocol stack such as TCP, UDP or other protocols, or
by network device working as a proxy.
3. Simplified signaling process with minimal information carried,
reduced QoS state maintenance at network devices.
4. Use different IPv6 options for signaling and signaling state
report.
5. Support both bandwidth reservation and latency expectation at
each hop.
6. Support dynamic resource reservation.
7. Support dynamic QoS forwarding state monitoring.
3.5. IPv6 Approach 3.5. IPv6 Approach
IPv6 extension header is used for signaling. There are two types of IPv6 extension header is used for signaling. There are two types of
extension header used for the purpose of transport QoS control, one extension header used for the purpose of transport QoS control, one
is the hop-by-hop EH (HbH-EH) and another is the destination EH (Dst- is the hop-by-hop EH (HbH-EH) and another is the destination EH (Dst-
EH). EH).
The HbH-EH may be examined and processed by the nodes that are The HbH-EH may be examined and processed by the nodes that are
explicitly configured to do so [RFC8200], and these nodes are called explicitly configured to do so [RFC8200], and these nodes are called
HbH-EH-aware nodes. Note, not all nodes along a patch need to HbH- HbH-EH-aware nodes. Note, not all nodes along a patch need to HbH-
skipping to change at page 26, line 20 skipping to change at page 27, line 13
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] [I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft- Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-19 (work in progress), October 2018. ietf-detnet-use-cases-20 (work in progress), December
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
skipping to change at page 27, line 45 skipping to change at page 28, line 40
[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.
[TIA] TIA 1039 Revision A, "QoS Signaling for IP QoS Support and
Sender Authentication", 2015, <https://global.ihs.com/doc_
detail.cfm?&csf=TIA&item_s_key=00480715&item_key_date=8804
31>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors are very grateful to Fred Baker for his valuable The authors are very grateful to Fred Baker for his valuable
contributions to this document. 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
 End of changes. 16 change blocks. 
38 lines changed or deleted 67 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/