Internet DRAFT - draft-luo-grow-ts-use-cases
draft-luo-grow-ts-use-cases
Network Working Group Y. Luo
Internet-Draft L. Ou
Intended status: Informational China Telcom Co., Ltd.
Expires: September 19, 2016 S. Lu
Tencent
S. Zhuang
N. Wu
Huawei
March 18, 2016
Use-cases for Traffic Steering in Operator Networks
draft-luo-grow-ts-use-cases-00
Abstract
Transporting data to their users through operators' networks is a
fundamental service that can benefit both providers and consumers.
Due to the dramatically increased popularity and desire of
differentiated services and their constraints, it is essential for
operators to provide the traffic steering service under limited
network resources and maximize their benefits at the same time.
This document lists some typical use cases for traffic steering
services. This document does not attempt to enumerate all kinds of
scenarios, but rather it describes several key features of these
scenarios from which solutions may be constructed.
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 http://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."
Luo, et al. Expires September 19, 2016 [Page 1]
Internet-DrafTraffic Steering Use Case in Operator Networks March 2016
This Internet-Draft will expire on September 19, 2016.
Copyright Notice
Copyright (c) 2016 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
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use-cases for ISP . . . . . . . . . . . . . . . . . . . . . . 3
3.1. EoS-oriented Steering . . . . . . . . . . . . . . . . . . 3
3.1.1. An Example for Prioritized Users . . . . . . . . . . 3
3.1.2. Derived Requirements . . . . . . . . . . . . . . . . 4
3.2. Load Balancing Oriented Steering . . . . . . . . . . . . 4
3.2.1. An Example of Load Balancing between Aggregation and
Core . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. An Example of Load Balancing in Core . . . . . . . . 5
3.2.3. An Example of Load Balancing among ISPs . . . . . . . 6
3.2.4. An Example for Transit Selection . . . . . . . . . . 6
3.2.5. Derived Requirements . . . . . . . . . . . . . . . . 7
4. Use-cases for OTT . . . . . . . . . . . . . . . . . . . . . . 8
4.1. QoS-oriented Steering . . . . . . . . . . . . . . . . . . 8
4.2. Business-oriented Steering . . . . . . . . . . . . . . . 9
4.3. Inbound Traffic Steering . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
Luo, et al. Expires September 19, 2016 [Page 2]
Internet-DrafTraffic Steering Use Case in Operator Networks March 2016
1. Introduction
Transporting data to their users through operators' networks is a
fundamental service that can benefit both providers and consumers.
Since data/information transport is playing a key role nowadays,
operators have to face this increasing challenge through satisfying
services with differentiated criterias, such as latency, throughput,
reliability and even user-defined constraints. Kinds of steering
techniques, either manually or automatically, have been introduced to
achieve that goal. Some situations such as fault, utilization and
also making profit have to be taken care at the same time.
This document lists some typical use cases for traffic steering
services. This document does not attempt to enumerate all kinds of
scenarios, but rather it describes several key features of these
scenarios from which solutions may be constructed.
2. Terminology
o QoS: Quality of Service
o EoS: Experience of Service
o ISP: Internet Service Provider
o OTTSP: Over the Top Service Provider
3. Use-cases for ISP
3.1. EoS-oriented Steering
It is a reasonable commercial way to provide multiple paths to the
same destination with differentiated experiences to prioritized
users/services. This is an efficient approach to maximize providers'
network resources and their profit and give choices to users/
services.
3.1.1. An Example for Prioritized Users
Luo, et al. Expires September 19, 2016 [Page 3]
Internet-DrafTraffic Steering Use Case in Operator Networks March 2016
+----------+
| HongKong |
--+----------+--
--- | ---
--- | ---
-- | --
+----------+ | +----------+
|Singapore | | | LA |
+----------+ | +----------+
-- |Path1 --
--- | ---
Path2 --- | --- Path3
--+----------+--
| Sydney |
+----------+
|
|
+-----------+-----------+
| | |
+-------+ +-------+ +-------+
|Silver | |Gold | |Bronze |
|Users | |Users | |Users |
+-------+ +-------+ +-------+
Figure 1 EoS-oriented path selection for ISP
As depicted above, there are three prioritized users in Sydney,
saying Gold, Silver and Bronze, wish to visit website located in
HongKong. An ISP provides three different paths with different
experiences according to users' priority. The Gold Users may use
Path1 with less latency and loss. The Silver Users may use the Path2
through Singapore with less latency but maybe some congestion there.
The Bronze Users may use Path3 through LA with some latency and loss.
3.1.2. Derived Requirements
o REQ01: A classification mechanism/system is REQUIRED to exist to
identify users' traffic and the correspond priority respectively.
o REQ02: A decision procedure/mechanism for path selection is
REQUIRED to exist to decide traffic forwarding strategy based on
the input from a classification mechanism.
3.2. Load Balancing Oriented Steering
It is a persistent goal for providers to increase the utilization
ratio of their current network resources. Through transferring load
to less preferred links, the throughput of the whole network may be
increased.
Luo, et al. Expires September 19, 2016 [Page 4]
Internet-DrafTraffic Steering Use Case in Operator Networks March 2016
3.2.1. An Example of Load Balancing between Aggregation and Core
Aggregation C * Core * Aggregation D
* *
* *
* +----------+ *
* | Core A | *
+------+ --+----------+-- +------+
|WAN C1|-+ ---* *--- +-|WAN D1|
+------+ | --- * * --- | +------+
| -- * * -- |
| +----------+* * +----------+ |
+-| AGG C |* * | AGG D |-+
| +----------+* * +----------+ |
| -- * * -- |
+------+ | --- * * --- | +------+
|WAN C2|-+ ---* *--- +-|WAN D2|
+------+ --+----------+-- +------+
* | Core B | *
* +----------+ *
Figure 2 An Example of Load Balancing between Aggregation and Core
As depicted above, traffic from Aggregation C to Aggregation D
follows the path AGG C->Core B->AGG D as the primary path. It is a
reasonable practise to transfer some traffic load to less utilized
path AGG C->Core A->AGG D when the primary path CBD has congestion.
3.2.2. An Example of Load Balancing in Core
Aggregation * Core
*
+------+ +------+ *
|WAN D |--|AGG D |-+ *
+------+ +------+ | *
| *
| *
| *
+------+ +------+ | * +----------+ +----------+
|WAN E |--|AGG E |-+---| Core A |----| Core B |
+------+ +------+ | * +----------+ +----------+
| * | |
| * | |
| * | |
+------+ +------+ | * | +----------+
|WAN F |--|AGG F |-+ * +----------| Core C |
+------+ +------+ * +----------+
Figure 3 An Example of Load Balancing in Core
Luo, et al. Expires September 19, 2016 [Page 5]
Internet-DrafTraffic Steering Use Case in Operator Networks March 2016
As depicted above, traffice from Core C to WAN area ususally passes
through link CA in Core area. Part of traffice should be transferred
to link CBA when link CA congested.
3.2.3. An Example of Load Balancing among ISPs
* *
City A * City B * City C
* *
+-------+ * +-------+ * +-------+
|IXP A1 |----|IXP B1|---|IXP C1 |
+-------+ * +-------+ * +-------+ ISP 1
| * | * | |
*******|*************|*********|**|**********
| +----------|---------+ |
| | * | * | ISP 2
| | * | * |
+------+ * +------+ * +------+
|IXP A2|----|IXP B2|----|IXP C2|
+------+ * +------+ * +------+
| * | * |
| * | * |
+-------+ * +-------+ * +-------+
|Core A |----|Core B |---|Core C |
+-------+ * +-------+ * +-------+
Figure 4 An Example of Load Balancing among ISPs
As depicted above, traffice from IXP C1 to A usually passes through
link IXP C1->IXP A2->A. This is a long distant route, directly
connect city C and city A. Part of traffice should be transferred to
link IXP C1->IXP B1->IXP A1->IXP A2->A when primary link congested.
3.2.4. An Example for Transit Selection
It is quite common that multiple paths may exist for the same
destination at the same time in an ISP network. Usually those paths
with better QoS properties such as latency, loss, jitter and etc are
often preferred. Since these properties keep changing from time to
time, the decision of path selection has to be made dynamically.
Luo, et al. Expires September 19, 2016 [Page 6]
Internet-DrafTraffic Steering Use Case in Operator Networks March 2016
********************************
* *
* AS C1 *
* * AS Y1
* *
* +---+ +---+ * +-----------+
* /| B |---------| C |-----| Transit A | AS Z1
* / +---+\ +---+ * +-----------+--
* / | \\ // | * -- +-----------+
*+---+/ | \\// | * --| |
*| A | | //\ | * |Destination|
*+---+\ | // \\ | * --| |
* \ | / \ | * -- +-----------+
* \ +---+ +---+ * +-----------+--
* \| D |---------| E |-----| Transit B |
* +---+ +---+ * +-----------+
* *
* IP Core * AS X1
* *
********************************
Figure 5 An Example for Transit Selection
As depicted above, the traffic to destination in AS Z1 from ISP IP
core network (AS C1) has two choices on transit, saying Transit A and
Transit B. Transit A will be preferred when the QoS of Transit B
gets worse. As a result, the same traffic will go through Transit A
instead.
3.2.5. Derived Requirements
o REQ03: A resource monitoring mechanism/system is REQUIRED to exist
for dynamically report the resource usage of target subnets.
o REQ04: A decision procedure/mechanism for path selection is
REQUIRED to exist to decide traffic forwarding strategy based on
the input from a resource monitoring mechanism.
o REQ05: A QoS monitoring mechanism/system is REQUIRED to exist for
dynamically report the QoS conditions of those transits.
o REQ06: A decision procedure/mechanism for path selection is
REQUIRED to exist to decide traffic forwarding strategy based on
the input from a QoS monitoring mechanism.
o REQ07: A decision distribution mechanism/system is REQUIRED to
exist to populate the adjustment behavior accordingly.
Luo, et al. Expires September 19, 2016 [Page 7]
Internet-DrafTraffic Steering Use Case in Operator Networks March 2016
o REQ08: The three mechanisms above are RECOMMENDED to be automatic
ones.
4. Use-cases for OTT
4.1. QoS-oriented Steering
Actually similar situation exists in OTT service providers' networks
too. An OTTSP may have multiple network exits separated in different
sites. Depending on different conditions, it is optional for an
OTTSP to choose one of those exits to connect with the same ISP.
* *
City A * City B * City C
* *
* +-----+ *
* |Users| *
* +-----+ *
* | *
+-----------+-----------+
| * | * |
+-----+ * +-----+ * +-----+
| R11 |-----| R12 |-----| R13 |
+-----+ * +-----+ * +-----+ OTT
| * | * |
*****|***********|***********|*********
| * | * |
| * | * | ISP
+-----+ * +-----+ * +-----+
| R21 |-----| R22 |-----| R23 |
+-----+ * +-----+ * +-----+
| * | * |
+-----------+-----------+
* | *
* +-----+ * +-------+
* | AR |--------|Content|
* +-----+ * |Server |
+-------+
Figure 6 QoS-oriented Steering in OTT networks
As depicted above, the OTTSP has 3 exits with its ISP in City A, City
B and City C. Based on network conditions, this OTTSP may choose
different exits to steer its traffic into ISP's networks.
Luo, et al. Expires September 19, 2016 [Page 8]
Internet-DrafTraffic Steering Use Case in Operator Networks March 2016
4.2. Business-oriented Steering
Besides network conditions, an OTTSP may make its steering strategy
based on different business. For example, the OTTSP in the graph
above may choose different exits on per-business base, which REQUIREs
a mechanism/system exists to identify different businesses from
traffic flow.
REQ09: A mechanism/system exists to identify different businesses
from traffic flow.
4.3. Inbound Traffic Steering
Besides exits, an OTTSP may wish to have choices on entrances for
inbound traffic. Because of internal policies, an ISP may choose to
ignore or even prohibit an OTTSP's attempt to affect traffic paths.
It will be beneficial for both providers if a perfect solution with
detailed consideration may help to solve this problem, which is
absolutely out of the scope of this document.
REQ10: An interactive mechanism/system is REQUIRED to exist for
negotiation between OTT and ISP to solve the scenario of inbound
traffic steering.
5. IANA Considerations
This document has no request to IANA.
6. Security Considerations
This document has no security issue introduced.
7. Acknowledgements
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Luo, et al. Expires September 19, 2016 [Page 9]
Internet-DrafTraffic Steering Use Case in Operator Networks March 2016
8.2. Informative References
[I-D.chen-i2rs-ts-use-case]
Chen, M. and S. Hares, "I2RS Traffic Steering Use Case",
draft-chen-i2rs-ts-use-case-01 (work in progress), July
2014.
[I-D.chen-idr-rr-based-traffic-steering-usecase]
Chen, M., Zhuang, S., Zhu, Y., and S. Wang, "Use Cases of
Route Reflection based Traffic Steering", draft-chen-idr-
rr-based-traffic-steering-usecase-00 (work in progress),
July 2013.
[I-D.li-idr-flowspec-rpd]
Li, Z., Ou, L., Luo, Y., Lu, S., Zhuang, S., and N. Wu,
"BGP FlowSpec Extensions for Routing Policy Distribution
(RPD)", draft-li-idr-flowspec-rpd-01 (work in progress),
October 2015.
Authors' Addresses
Yujia Luo
China Telcom Co., Ltd.
109 West Zhongshan Ave,Tianhe District
Guangzhou 510630
China
Email: luoyuj@gsta.com
Liang Ou
China Telcom Co., Ltd.
109 West Zhongshan Ave,Tianhe District
Guangzhou 510630
China
Email: oul@gsta.com
Sujian Lu
Tencent
Tengyun Building,Tower A ,No. 397 Tianlin Road
Shanghai, Xuhui District 200233
China
Email: jasonlu@tencent.com
Luo, et al. Expires September 19, 2016 [Page 10]
Internet-DrafTraffic Steering Use Case in Operator Networks March 2016
Shunwan Zhuang
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Nan Wu
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: eric.wu@huawei.com
Luo, et al. Expires September 19, 2016 [Page 11]
