Internet DRAFT - draft-li-6man-service-aware-ipv6-network
draft-li-6man-service-aware-ipv6-network
Network Working Group Z. Li
Internet-Draft S. Peng
Intended status: Standards Track Huawei Technologies
Expires: September 12, 2019 March 11, 2019
Service-aware IPv6 Network
draft-li-6man-service-aware-ipv6-network-00
Abstract
A multitude of applications are carried over the network, which have
varying needs for network bandwidth, latency, jitter, and packet
loss, etc. Some applications such as online gaming and live video
streaming have very demanding network requirements thereof require
special treatments in the network. However, since the current
network is lack of enough information of service requirements of such
applications it is difficult to guarantee the SLA or it may take long
time to provide such guarantee. This document proposes the solution
to make use of IPv6 extensions header to convey the service
requirement information along with the packet to the network to
facilitate the service deployment and network resource adjustment to
guarantee SLA for applications. Then it defines the service-aware
options which can be used in the different IPv6 extension headers for
the purpose.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019.
Li & Peng Expires September 12, 2019 [Page 1]
Internet-Draft Service-aware IPv6 Network March 2019
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Online Gaming . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Video streaming . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Service-aware Options . . . . . . . . . . . . . . . . . . . . 5
5.1. Service-aware ID Option . . . . . . . . . . . . . . . . . 5
5.2. Service-Para Option . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
A multitude of applications are carried over the network, which have
varying needs for network bandwidth, latency, jitter, and packet
loss, etc. Some applications such as online gaming and live video
streaming have very demanding network requirements thereof require
special treatments in the network. However, since the current
network is lack of enough information of service requirements of such
applications it is difficult to guarantee the SLA or it may take long
time to provide such guarantee. This document proposes the solution
to take use of IPv6 extensions header to convey the service
requirement information along with the packet to the network to
facilitate the service deployment and network resource adjustment to
guarantee SLA for applications. Then it defines the service-aware
Li & Peng Expires September 12, 2019 [Page 2]
Internet-Draft Service-aware IPv6 Network March 2019
options which can be used in the different IPv6 extension headers for
the purpose.
2. Use Cases
This section shows the various demanding requirements of some
applications in the following use cases. The traffic of these
applications needs to be differentiated from other traffic and
applied with special treatments in the network.
2.1. Online Gaming
Good network performance is normally a prerequisite for satisfactory
game play, especially for the online gaming. The maximum allowable
ping rate (network latency) and the required minimum download/upload
speed (network bandwidth) are the key factors to make the online
gaming playable. Shooting or racing online gaming is normally based
on quick action and needs to update the game status in real time by
continuously sending and receiving updates to/from the game server
and/or other players. The network paths with low latency and low
packet loss need to be explicitly selected from the game players to
the game server.
2.2. Video streaming
The network latency, jitter, bandwidth, and packet loss are the key
factors for the video streaming. Live video streaming has even more
strict requirements. High quality video source (e.g. from Netflix)
require more bandwidth in order to stream properly. Real time
streaming services also requires real time content delivery from the
web server to the end user ideally via carefully planned explicit TE
paths. The online gaming often involves live video streaming.
3. Problem Statement
[RFC3272] reviews a number of IETF activities which are primarily
intended to evolve the IP architecture to support new service
definitions which allow preferential or differentiated treatment to
be accorded to certain types of traffic. The challenge when using
traditional ways to guarantee SLA is that the packets are not able to
carry enough information of service requirements of applications.
The network devices mainly relies on the 5-tuple of the packets which
cannot provide fine-grained service process. If more information is
needed, it has to refer to DPI which will introduce more cost in the
network and impose security challenges.
In the era of SDN the orchestrator is introduced for the
orchestration of applications and the network. The SDN controller
Li & Peng Expires September 12, 2019 [Page 3]
Internet-Draft Service-aware IPv6 Network March 2019
can be aware of the service requirements of the applications on the
network through the interface interworking with the orchestrator.
The service requirements is used by the controller for traffic
management. The method raises the following problems: 1) The whole
loop is long and time-consuming which is not suitable for the real-
time adjustment for applications; 2) Too many interfaces are involved
in the loop which proposes more challenges of standardization and
inter-operability, and it is difficult to be standardized for easy
interworking.
4. Framework
+-----+ +-----+
|App x|----\ /---->|App x|
+-----+ | +-----------+ +--------+ +---------+ +---------+ | +-----+
\--->| | | |---A---| |---A---| |---/
|Edge Device|----|Head-End|---B---|Mid-Point|---B---|End-Point|
/--->| | | |---C---| |---C---| |---\
+-----+ | +-----------+ +--------+ +---------+ +---------+ | +-----+
|App y|----/ \---->|App y|
+-----+ +-----+
Figure 1 Service-aware IPv6 Network
In the service-aware IPv6 network shown in Figure 1, there are
following components:
1. Service-aware Apps: The IPv6 enabled applications runs in the
host which can add the service requirements of the applications on
network through the IPv6 extension header ([RFC8200]) or remove it
from the IPv6 extension header. The service requirement information
includes the IPv6 service-aware ID which identifies the IPv6 packets
of the traffic belongs to the specific SLA level/Applications/User
and the parameters for the specific service such as bandwidth, delay,
delay variation, packet loss ratio, etc. The service requirements
will be processed by the IPv6 enabled nodes along the path or the
SRv6 ([I-D.filsfils-spring-srv6-network-programming]) enabled node
along the SRv6 path which be programmed in the host. The Apps can
also need not to add any service requirement information in the IPv6
extension header.
2. Service-aware Edge Device: The Edge Device can add the service
requirements of the applications on network through the IPv6
extension header on behalf of the IPv6 enabled applications or change
the service requirements conveyed by the packets of the service-aware
applications according to local policies which is out of the scope of
this document. The service requirements will be processed by the
Li & Peng Expires September 12, 2019 [Page 4]
Internet-Draft Service-aware IPv6 Network March 2019
IPv6 enabled nodes along the path or the SRv6 enabled node along the
SRv6 path which be programmed by the Edge Device.
3. Service-process Head-End: The service requirements may be
processed as a service path such as SRv6 TE path of SFC at the
Service-process Head-End. The service requirements conveyed in the
IPv6 packets can be mapped to a service path which satisfies the
specific requirement, trigger to set up the new service path by the
Head-End, or trigger the global traffic adjustment by the controller
according to the information provided by the network devices. The
process depends on the local policy which is out of the scope this
document.
4. Service-process Mid-Point: The Mid-Point provides the path
service according to the service path set up by the Head-End which
satisfies the service requirement conveyed by the IPv6 packets. The
Mid-Point may also adjust the resource locally to guarantee the
service requirements depending on specific policies which is out of
the scope of this document.
5. Service-process End-Point: The process of the specific service
path will end at the End-Point. The service requirements information
can be removed at the End-Point or go on to be conveyed with the IPv6
packets.
In this way the network is able to be aware of the service
requirements of the applications explicitly. According to these
service requirement information carried in the IPv6 packets the
network is able to adjust its resource fast to satisfy the service
requirement of applications. The flow-driven method also reduces the
challenges of inter-operability and loop control loop.
5. Service-aware Options
Two service-aware options are defined, i.e. Service-aware ID option
and Service-Para Option to support the Service-aware IPv6 network.
5.1. Service-aware ID Option
The Service-aware ID option indicates the information of the
applications, users, and service requirements, which is defined in
the following figure:
Li & Peng Expires September 12, 2019 [Page 5]
Internet-Draft Service-aware IPv6 Network March 2019
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Service-aware ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. IPv6 Service-aware ID Option
Option Type: TBD
Opt Data Len: 16 octets.
The IPv6 Service-aware ID is 128bits long which can have the
following structures:
-- Structure I: Any combination of SLA level (e.g. Gold, Silver,
Bronze), APP ID, and/or user ID. The length of each field is
variable, which is shown in the following diagram:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLA Level | APP ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. IPv6 Service-aware ID Structure I
-- Structure II: Any combination of SLA level (e.g. Gold, Silver,
Bronze), APP ID, and/or user ID plus the arguments which indicates
the service requirements of the identified application, which is
shown in the following diagram:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLA Level | APP ID | User ID | Arguments |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. IPv6 Service-aware ID Structure II
-- Structure III: An SRv6 SID, with its arguments as the information
specified in Structure 2, which is shown in the following diagram:
Li & Peng Expires September 12, 2019 [Page 6]
Internet-Draft Service-aware IPv6 Network March 2019
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Address | Function ID | Arguments |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. IPv6 Service-aware ID Structure III
This Option can be put into the IPv6 Hop-by-Hop Options, Destination
Options, and SRH TLV ([I-D.ietf-6man-segment-routing-header]).
5.2. Service-Para Option
The Service-Para Option is a variable-length option carrying multiple
service requirement parameters. Each service requirement parameter
is put into the corresponding Service Para Sub-TLV, as shown in
Figure 6. This Option can be put into the IPv6 Hop-by-Hop Options,
Destination Options, and SRH TLV.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Service Para Sub-TLVs(Variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. IPv6 Service-Para Option
Option Type TBD
Opt Data Len 8-bit unsigned integer. Length of the
Service Para Sub-TLVs.
Service Para Sub-TLVs Variable-length field with Service
Para Sub-TLVs.
The corresponding Service Para Sub-TLVs are shown in the following
figures respectively.
1. BW Sub-TLV
This BW sub-TLV indicates the bandwidth requirement of applications.
The format of this sub-TLV is shown in the following diagram:
Li & Peng Expires September 12, 2019 [Page 7]
Internet-Draft Service-aware IPv6 Network March 2019
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Class Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. BW Sub-TLV
where:
Type: TBD
Length: 4
Class Type: The Bandwidth Type.
RESERVED: This field is reserved for future use. It MUST be set to 0
when sent and MUST be ignored when received.
Bandwidth: This field carries the bandwidth requirement along the
path.
2. Delay Sub-TLV
This Delay Sub-TLV indicates the delay requirement of applications.
The format of this sub-TLV is shown in the following diagram:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. Delay Sub-TLV
where:
Type: TBD
Length: 4
RESERVED: This field is reserved for future use. It MUST be set to 0
when sent and MUST be ignored when received.
Li & Peng Expires September 12, 2019 [Page 8]
Internet-Draft Service-aware IPv6 Network March 2019
Delay: This 24-bit field carries the delay requirements in
microseconds, encoded as an integer value. When set to the maximum
value 16,777,215 (16.777215 sec), then the delay is at least that
value and may be larger. This value is the highest delay that can be
tolerated.
3. Delay Variation Sub-TLV
This Delay Variation Sub-TLV indicates the delay variation
requirement of applications. The format of this sub-TLV is shown in
the following diagram:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Delay Variation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. Delay Variation Sub-TLV
where:
Type: TBD
Length: 4
RESERVED: This field is reserved for future use. It MUST be set to 0
when sent and MUST be ignored when received.
Delay Variation: This 24-bit field carries the delay variation
requirements in microseconds, encoded as an integer value.
4. Packet Loss Ratio Sub-TLV
This Packet Loss Ratio Sub-TLV indicates the packet loss ratio
requirement of applications. The format of this sub-TLV is shown in
the following diagram:
Li & Peng Expires September 12, 2019 [Page 9]
Internet-Draft Service-aware IPv6 Network March 2019
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Packet Loss Ratio |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10. Packet Loss Ratio Sub-TLV
where:
Type: TBD
Length: 4
RESERVED: This field is reserved for future use. It MUST be set to 0
when sent and MUST be ignored when received.
Link Loss: This 24-bit field carries link packet loss ratio
requirement. This value is the highest packet-loss ratio that can be
tolerated.
6. IANA Considerations
IANA maintains the registry for the Options and Sub-TLVs.
Service-Para Option will require one new type code per sub-TLV
defined in this document:
Type Value
----------------------------------------------------
TBD Service-aware ID Option
TBD Service-Para Option
TBD BW Sub-TLV
TBD Delay Sub-TLV
TBD Delay Variation Sub-TLV
TBD Packet Loss Sub-TLV
Li & Peng Expires September 12, 2019 [Page 10]
Internet-Draft Service-aware IPv6 Network March 2019
7. Security Considerations
TBD
8. References
8.1. Normative References
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network-
programming-07 (work in progress), February 2019.
[I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-16 (work in
progress), February 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
8.2. Informative References
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.
Xiao, "Overview and Principles of Internet Traffic
Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002,
<https://www.rfc-editor.org/info/rfc3272>.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Li & Peng Expires September 12, 2019 [Page 11]
Internet-Draft Service-aware IPv6 Network March 2019
Shuping Peng
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: pengshuping@huawei.com
Li & Peng Expires September 12, 2019 [Page 12]
