< draft-amend-tsvwg-multipath-framework-mpdccp-00.txt   draft-amend-tsvwg-multipath-framework-mpdccp-01.txt >
Transport Area Working Group M. Amend Transport Area Working Group M. Amend
Internet-Draft Deutsche Telekom Internet-Draft E. Bogenfeld
Intended status: Informational A. Brunstrom Intended status: Informational Deutsche Telekom
Expires: September 12, 2019 A. Kassler Expires: January 9, 2020 A. Brunstrom
A. Kassler
Karlstad University Karlstad University
V. Rakocevic V. Rakocevic
City University of London City University of London
March 11, 2019 July 08, 2019
IP compatible multipath framework for heterogeneous access networks A multipath framework for UDP traffic over heterogeneous access networks
draft-amend-tsvwg-multipath-framework-mpdccp-00 draft-amend-tsvwg-multipath-framework-mpdccp-01
Abstract Abstract
More and more of today's devices are multi-homing capable, in More and more of today's devices are multi-homing capable, in
particular 3GPP user equipment like smartphones. In the current particular 3GPP user equipment like smartphones. In the current
standardization of the next upcoming mobile network generation 5G standardization of the next upcoming mobile network generation 5G
Rel. 16, this is especially targeted in the study group Access Rel.16, this is especially targeted in the study group Access Traffic
Traffic Steering Switching Splitting [3GPP, TR 23.793]. ATSSS Steering Switching Splitting [TR23.793]. ATSSS describes the
describes the flexible selection or combination of 3GPP untrusted flexible selection or combination of 3GPP untrusted access like Wi-Fi
access like Wi-Fi and cellular access, overcoming the single-access and cellular access, overcoming the single-access limitation of
limitation of today's devices and services. Another multi- today's devices and services. Another multi-connectivity scenario is
connectivity scenario is the Hybrid Access [draft-lhwxz-hybrid- the Hybrid Access [I-D.lhwxz-hybrid-access-network-architecture][I-D.
access-network-architecture, draft-muley-network-based-bonding- muley-network-based-bonding-hybrid-access], providing multiple access
hybrid-access], providing multiple access for CPEs, which extends the for CPEs, which extends the traditional way of single access
traditional way of single access connectivity at home to dual- connectivity at home to dual-connectivity over 3GPP and fixed access.
connectivity over 3GPP and fixed access. A missing piece in the A missing piece in the ATSSS and Hybrid Access is the access and path
ATSSS and Hybrid Access is the access and path measurement for measurement, which is required for efficient and beneficial traffic
efficient and beneficial traffic steering decisions. This becomes steering decisions. This becomes particularly important in
particularly important in heterogeneous access networks with a heterogeneous access networks with a multitude of volatile access
multitude of volatile access paths. MP-TCP can be employed in such paths. While MP-TCP has been proposed to be used within ATSSS, there
scenarios and concerning the ATSSS, it is the agreed protocol for the are drawbacks when being used to encapsulate unreliable traffic as it
traffic splitting mode. A decision for MP-TCP though leaves the blindly retransmits each lost frame leading to excessive delay and
increasing share of UDP in today's traffic mix (https://arxiv.org/ potential head-of-line blocking. A decision for MP-TCP though leaves
abs/1801.05168) unconsidered. In this document, a network the increasing share of UDP in today's traffic mix
architecture leveraging the MP-DCCP network protocol is proposed, (<https://arxiv.org/abs/1801.05168>) unconsidered. In this document,
which enables above scenarios and address the formulated issues a multi-access framework is proposed leveraging the MP-DCCP network
protocol, which enables flexible traffic steering, switching and
splitting also for unreliable traffic. A benefit is the support for
pluggable congestion control which enables our framework to be used
either independent or complementary to MP-TCP. either independent or complementary to MP-TCP.
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.
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 September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IP compatible multipath framework based on MP-DCCP . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Application and placement . . . . . . . . . . . . . . . . . . 5 3. IP compatible multipath framework based on MP-DCCP . . . . . 4
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Application and placement . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Informative References . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Multi-connectivity access networks are evolving. Ongoing Multi-connectivity access networks are evolving. Ongoing
standardization at 3GPP for 5G mobile networks [3GPP, TR 23.793] or standardization at 3GPP for 5G mobile networks [TR23.793] or the so
the so called Hybrid Access networks [draft-lhwxz-hybrid-access- called Hybrid Access networks [I-D.lhwxz-hybrid-access-network-archit
network-architecture, draft-muley-network-based-bonding-hybrid- ecture][I-D.muley-network-based-bonding-hybrid-access] already
access] already provides or will provide in the near future the provides or will enable in the near future the possibility to use
ability for multi-connectivity to a broad mass. A superior multi-connectivity for a very large number of mobile users. Multi-
resilience against network outages, higher capacities and network connectivity solutions come with many user benefits including
cost optimizations are only some of the reasons why it make sense to superior resilience against network outages, higher capacities for
introduce multi-connectivity. Since the multi-connectivity user traffic and network cost optimizations. Since multi-
architectures are almost mature, it requires network protocols connectivity architectures are almost mature, new network protocols
providing the technology to exploit multi-connectivity. In the are required to fully exploit multi-connectivity and maximise its
simplest case, multi-connectivity means load-balancing, distributing potential. In the simplest case, multi-connectivity is used for
individual flows over multiple paths to distribute the load. load-balancing decisions in order to balance the user flows over
However, this has no effect on resilience or capacity gain on those multiple paths. However, this has no effect on resilience or
load balanced individual flows. More complex are those scenarios capacity gain on those load balanced individual flows. More complex
where an individual flow can be seamlessly shifted between multiple scenarios include the dynamic shifting of traffic flows seamlessly
paths or can even aggregate those paths for leveraging the sum between multiple paths or even aggregating those paths for leveraging
capacities. Like [3GPP, TR 23.793] this document refers to the three the available capacity of multiple individual paths. Like [TR23.793]
distribution schemes Steering (load balancing), Switching (seamless this document refers to the three distribution schemes Steering (load
handover) and Splitting (capacity aggregation). balancing), Switching (seamlesshandover) and Splitting (capacity
aggregation).
MP-TCP [RFC6824] is a protocol, which can be applied in the above MP-TCP [RFC6824] is a protocol, which can be applied in the above
mentioned use cases and covers load-balancing, seamless communication mentioned use cases and supports load-balancing, traffic shifting
handover and also capacity aggregation. Further, it deals with among the multiple paths and also capacity aggregation. Further, it
heterogeneous and volatile access networks, since it profits from the leverages the inherent congestion control from TCP which adapts the
TCP inherent congestion control. By design, MP-TCP is limited to TCP sending rate by observing congestion signals from the network. By
services and excludes any other network protocol, in particular UDP. design, MP-TCP is limited to TCP services as it blindly re-transmits
For future multi-connectivity systems, it is not sufficient anymore lost packets. Consequently, when MP-TCP is used as a framework for
to rely on supporting only TCP. The increasing share of UPD traffic, ATSSS, it may re-transmit packets sent from unreliable services such
mainly impacted by the QUIC introduction, may significantly reduce as e.g. UDP unnecessary. This may lead to head-of-line blocking and
the share from TCP. It might be expected that with HTTP/3 carried increased latency, which is detremental to real-time services. As
over QUIC [draft-ietf-quic-http], the previous strong dominance of future multi-connectivity systems must support latency sensitive
TCP will be challenged by UDP. traffic that might be transported over unreliable transport, it is
not sufficient anymore to rely on supporting only TCP. The
increasing share of UDP traffic, mainly impacted by the QUIC
introduction, may significantly reduce the share from TCP. It might
be expected that with HTTP/3 carried over QUIC [I-D.ietf-quic-http],
the previous strong dominance of TCP will be challenged by UDP.
2. IP compatible multipath framework based on MP-DCCP 2. Requirements
A new approach, which overcomes MP-TCP's restriction to TCP services A multiaccess framework shall meet the following requirements:
and providing IP compatibility, is depicted in Fig. 1. The
architecture employs MP-DCCP [draft mp-dccp] in combination with an o IP compatibility: A multiaccess framework shall be able to
encapsulation scheme. For simplification, Fig. 1 assumes a traffic transport IP packets and not make any assumptions on which
direction from the left (sender) to the right (receiver) and requires transport protocol is encapsulated.
o Support for unreliable traffic: A multiaccess framework should
provide support for transporting unreliable traffic, such as QUIC
or UDP based flows. Therefore, unreliable transmission should
besupported.
o Support for flexible re-ordering: A multiaccess framework should
support flexible re-ordering of user traffic, including no re-
ordering at all. This requirements is important to support low
latency traffic, where the re-creation of packet order may
negatively impact delivery latency.
o Support for flexible congestion control: A multiaccess framework
should support flexible congestion control, including the
disabling of the congestion control, if the inner traffic is known
to be congestion controlled.
o Support for flexible packet scheduling: A multiaccess framework
should support different packet scheduling mechanisms, which
should be configurable from the control plane. Examples are
cheapest path first, or other more sophisticated schedulers.
o Lightweight: A multiaccess framework should be lightweight in
computational resources and limit the encapsulaton overhead.
To use QUIC as part of a multiaccess framework, by for example
providing multipath support for QUIC, it could be beneficial if
unreliable transmission is supported as well as being able to
influence or disable QUICs congestion control. In addition, it would
be beneficial if the encryption of QUIC can be disabled. This is
because for ATSSS, it is foreseen that the underlying tunnel from the
mobile over public WLANs is baseed on IPSec.
3. IP compatible multipath framework based on MP-DCCP
We propose a new multiaccess framework, which overcomes MP-TCP's
restriction to TCP services and provides IP compatibility in
Figure 1. The framework employs MP-DCCP
[I-D.amend-tsvwg-multipath-dccp] in combination with an encapsulation
scheme. For simplification, Figure 1 assumes a traffic direction
from the left (sender) to the right (receiver) and requires
application in each direction for bi-directional transmission. The application in each direction for bi-directional transmission. The
architecture in Fig. 1 can replace or complement MP-TCP to reach IP framework in Figure 1 can replace or complement MP-TCP to reach IP
compatibility. compatibility.
Service |<- MP-DCCP ->| Service Service |<- MP-DCCP >| Service
or Device or Device or Device or Device
+---------+ ___ +------+ DCCP Flow 1 +-------+ +---------+ +-------+ ___ +-----+ DCCP Flow 1 +------+ +--------+
| | _ |Seq|| Path |--------------| Re- | _ | | | | _ |Seq||Path |-------------|Re- | _ | |
| Sender |___| \___&#709;__| | : | order |____/ |___|Receiver | | Sender|___| \__\ /_| | : |order |____/ |___|Receiver|
| | IP|_/ | Sched| : | | \_|IP | | | | IP|_/ |Sched| : | | \_|IP | |
| | VNIF_in | uler |--------------| engine| VNIF_out | | | | VNIF_in |uler |-------------|engine| VNIF_out | |
+---------+ +------+ DCCP Flow n +-------+ +---------+ +-------+ +-----+ DCCP Flow n +------+ +--------+
Figure 1: IP compatible multipath framework based on MP-DCCP Figure 1: IP compatible multipath framework based on MP-DCCP
PDUs generated from the sender and travelling through the PDUs generated from the sender and travelling through the framework
architecture in Fig. 1 passes the components in the following order: in Figure 1 pass the components in the following order:
1. Sender: Generates any PDU based on the IP protocol. 1. Sender: Generates any PDU based on the IP protocol.
2. VNIF_in: IP based Virtual Network Interface as entry point to the 2. VNIF_in: IP based Virtual Network Interface as entry point to the
MP-DCCP framework. A simple routing logic in front (between (1) multipath framework. A simple routing logic in front (between
and (2)) can act as gatekeeper and decides upon redirecting (1)and (2)) can act as gatekeeper and decides upon redirecting
traffic through the VNIF or bypassing it. The VNIF adds an extra traffic through the VNIF or bypassing it. The VNIF adds an extra
IP layer to reach the multi-connectivity termination point. IP header to reach the multi-connectivity termination point.
3. Seq: Sequencing of in (2) passed PDUs depending on the incoming 3. Seq: Sequencing of the PDUs passed through (2) depending on the
order. Adds an incrementing number, which is later added to the incoming order. Adds an incrementing number, which is later
DCCP encapsulation in (4). added to the DCCP encapsulation in (4).
4. Path Scheduler: Decision logic for scheduling sequenced PDUs over 4. Path Scheduler: Decision logic for scheduling sequenced PDUs over
the individual connected DCCP flows for multipath transmission. the individual connected DCCP flows for multipath transmission.
The path scheduler can use the information from the DCCP flows The path scheduler can use the information from the DCCP flows
(see (5)) inherent congestion control information like CWND, (see (5)) inherent congestion control information like CWND,
packet loss, RTT, Jitter. After selection of a DCCP flow, the packet loss, RTT, Jitter, etc.. After selection of a DCCP flow,
PDU is encapsulated into the individual flow. Further the PDU is encapsulated into the individual flow. Further
information, at least the sequencing, is added on top as DCCP information, at least the sequencing, is added on top as DCCP
option. option.
5. DCCP Flow(s): Responsible to transmit the encapsulated PDUs to 5. DCCP Flow(s): Responsible to transmit the encapsulated PDUs to
the MP-DCCP exit point. the MP-DCCP exit point.
6. Reorder engine: Depending on the sequencing information of (3), a 6. Reorder engine: Depending on the sequencing information of (3), a
re-assembly of the PDU stream can be applied. The strictness of re-assembly of the PDU stream can be applied. Different re-order
re-ordering shall be configurable up to no re-ordering. algorithms should be supported in a configurable way, including
no re-ordering.
7. VNIF_out: Releases PDUs that have passed the re-ordering engine 7. VNIF_out: Releases PDUs that have passed the re-ordering engine
and strips the DCCP specific overhead. Again routing is and strips the DCCP specific overhead. Again, routing is
responsible to deliver the PDUs to the receiver based on the responsible to deliver the PDUs to the receiver based on the
destination information in the PDU. destination information in the PDU.
8. Receiver: Receive the PDU as generated in (1). 8. Receiver: Receive the PDU as generated in (1).
The simple enclosing of the MP-DCCP with Virtual Network Interface The simple enclosing of the MP-DCCP with Virtual Network Interface
(VNIF) provides the IP compatibility. However, a service or protocol (VNIF) provides the IP compatibility. However, a service or protocol
classifier between sender and VNIF can reduce the scope to particular classifier between sender and VNIF can reduce the scope to particular
traffic, e.g. UDP, by simple routing decisions. The MP-DCCP takes traffic, e.g. UDP, by simple routing decisions. The MP-DCCP takes
over responsibility for the multi-path transfer of the traffic, which over responsibility for the multi-path transfer of the traffic, which
is directed through the VNIF_in. For possible re-assembly operations is directed through the VNIF_in. For possible re-assembly
the IP packets are stamped with a continuously incremented stamped operations, the IP packets may be stamped with a continuously
sequence number. This is not a mandatory operation, but assumed incremented sequence number. This is not mandatory, but assumed
required in most seamless handover and capacity aggregation use required in most seamless handover and capacity aggregation use
cases. The path scheduler decides for each IP packet which DCCP flow cases. The path scheduler decides for each IP packet, which DCCP
is appropriate, based on a configurable decision logic and supported flow it should use for encapsulation, based on a configurable
by the congestion control information of the DCCP flows available for decision logic and supported by the congestion control information of
transmission. A DCCP flow selection for a PDU leads to its the DCCP flows available for transmission. A DCCP flow selection for
encapsulation into the respective DCCP flow and adding extra a PDU leads to its encapsulation into the respective DCCP flow and
information required for the multipath transmission, e.g. the adding extra information required for the multipath transmission,
sequence number. Encapsulation also means, that to the original PDU e.g. the sequence number. Encapsulation also means, that a DCCP and
a DCCP and IP header is added to reach the multi-connectivity end- IP header is added to the original PDU to reach the multi-
point. When the encapsulated PDUs arrive at the multi-path connectivity end-point. When the encapsulated PDUs arrive at the
termination point, they are re-ordered depending on the carried multi-path termination point, they are re-ordered depending on the
sequence number and a configurable logic. The re-ordering engine may carried sequence number and a configurable logic. The re-ordering
also include a logic in which packets are just forwarded (no re- engine may also include a logic in which packets are just forwarded
ordering). Re-ordering needs to be considered carefully since any (no re-ordering). Re-ordering needs to be considered carefully since
active intervention changes the latency responsiveness. The multi- any active intervention changes the latency responsiveness. The
path termination is finally completed when the DCCP overhead is multi-path termination is finally completed when the DCCP overhead is
stripped and the PDU leaves VNIF_out. Further routing depends again stripped and the PDU leaves VNIF_out. Further routing depends again
on the IP layer of the original PDU. on the IP layer of the original PDU.
3. Application and placement 4. Application and placement
The framework of Fig. 1 gives most flexibility in applying multipath The framework of Figure 1 is very flexible in applying multipath
support in different architectures and allows MP-DCCP to be applied support in different architectures and allows MP-DCCP to be applied
at any place between sender and receiver. Fig2. to Fig. 5 gives an at any place between sender and receiver. Figure 2 to Figure 5
impression about the universality which covers any imaginable provide several architectural options for the deployment of the
architecture. framework.
Device Middlebox 1 Middlebox 2 Device Device Middlebox 1 Middlebox 2 Device
+------+ +-------------+ +------------+ +--------+ +------+ +-------------+ +------------+ +--------+
|Sender| -> |MP-DCCP entry| -> |MP-DCCP exit| -> |Receiver| |Sender| -> |MP-DCCP entry| -> |MP-DCCP exit| -> |Receiver|
+------+ +-------------+ +------------+ +--------+ +------+ +-------------+ +------------+ +--------+
Figure 2: Sender and receiver independent MP-DCCP Figure 2: Sender and receiver independent MP-DCCP
Device Middlebox Device Device Middlebox Device
+----------------------+ +------------+ +--------+ +----------------------+ +------------+ +--------+
skipping to change at page 6, line 4 skipping to change at page 7, line 18
+----------------------+ +------------+ +--------+ +----------------------+ +------------+ +--------+
Figure 3: Sender integrated but receiver independent MP-DCCP Figure 3: Sender integrated but receiver independent MP-DCCP
Device Middlebox Device Device Middlebox Device
+------+ +-------------+ +-----------------------+ +------+ +-------------+ +-----------------------+
|Sender| -> |MP-DCCP entry| -> |MP-DCCP exit + Receiver| |Sender| -> |MP-DCCP entry| -> |MP-DCCP exit + Receiver|
+------+ +-------------+ +-----------------------+ +------+ +-------------+ +-----------------------+
Figure 4: Sender independent and receiver integrated MP-DCCP Figure 4: Sender independent and receiver integrated MP-DCCP
Device Device Device Device
+----------------------+ +-----------------------+ +----------------------+ +-----------------------+
|Sender + MP-DCCP entry| -> |MP-DCCP exit + Receiver| |Sender + MP-DCCP entry| -> |MP-DCCP exit + Receiver|
+----------------------+ +-----------------------+ +----------------------+ +-----------------------+
Figure 5: Sender and receiver integrated MP-DCCP Figure 5: Sender and receiver integrated MP-DCCP
4. Conclusion 5. Conclusion
The specified IP compatible multipath framework based on MP-DCCP in The specified IP compatible multipath framework based on MP-DCCP in
this document comprises several benefits: this document comprises several benefits:
o Pure routing o Pure routing
o Inherent path estimation and measurement o Inherent path estimation and measurement
o Imposes no reliability or in-order delivery o Imposes no constraints on reliability or in-order delivery of
application PDUs
o Modular re-ordering o Modular re-ordering
o Modular scheduling o Modular scheduling
o IP compatible o IP compatible
o Based on the standardized DCCP. o Based on the standardized DCCP.
Middle-box traversing, when the framework is applied in uncontrolled Middle-box traversing, when the framework is applied in uncontrolled
environments, is addressed in [RFC6733] and [draft u-dccp]. environments, is addressed in [RFC6733] and
[I-D.amend-tsvwg-dccp-udp-header-conversion].
5. Security Considerations 6. Security Considerations
[Tbd] [Tbd]
6. Acknowledgments 7. Acknowledgments
7. Informative References 8. Informative References
[I-D.amend-tsvwg-dccp-udp-header-conversion]
Amend, M., Brunstrom, A., Kassler, A., and V. Rakocevic,
"Lossless and overhead free DCCP - UDP header conversion
(U-DCCP)", draft-amend-tsvwg-dccp-udp-header-conversion-01
(work in progress), July 2019.
[I-D.amend-tsvwg-multipath-dccp]
Amend, M., Brunstrom, A., Kassler, A., and V. Rakocevic,
"DCCP Extensions for Multipath Operation with Multiple
Addresses", draft-amend-tsvwg-multipath-dccp-01 (work in
progress), March 2019.
[I-D.ietf-quic-http] [I-D.ietf-quic-http]
Bishop, M., "Hypertext Transfer Protocol Version 3 Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", draft-ietf-quic-http-18 (work in progress), (HTTP/3)", draft-ietf-quic-http-18 (work in progress),
January 2019. January 2019.
[I-D.lhwxz-hybrid-access-network-architecture] [I-D.lhwxz-hybrid-access-network-architecture]
Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M. Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M.
Zhang, "Hybrid Access Network Architecture", draft-lhwxz- Zhang, "Hybrid Access Network Architecture", draft-lhwxz-
hybrid-access-network-architecture-02 (work in progress), hybrid-access-network-architecture-02 (work in progress),
skipping to change at page 7, line 22 skipping to change at page 9, line 5
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>. <https://www.rfc-editor.org/info/rfc6733>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<https://www.rfc-editor.org/info/rfc6824>. <https://www.rfc-editor.org/info/rfc6824>.
[TR23.793]
3GPP, "Study on access traffic steering, switch and
splitting support in the 5G System (5GS) architecture",
December 2018.
Authors' Addresses Authors' Addresses
Markus Amend Markus Amend
Deutsche Telekom Deutsche Telekom
T-Online-Allee 1 Deutsche-Telekom-Allee 7
Darmstadt 64295 Darmstadt
Germany Germany
Email: Markus.Amend@telekom.de Email: Markus.Amend@telekom.de
Eckard Bogenfeld
Deutsche Telekom
Deutsche-Telekom-Allee 7
64295 Darmstadt
Germany
Email: Eckard.Bogenfeld@telekom.de
Anna Brunstrom Anna Brunstrom
Karlstad University Karlstad University
Universitetsgatan 2 Universitetsgatan 2
651 88 Karlstad 651 88 Karlstad
Sweden Sweden
Email: anna.brunstrom@kau.se Email: anna.brunstrom@kau.se
Andreas Kassler Andreas Kassler
Karlstad University Karlstad University
 End of changes. 34 change blocks. 
124 lines changed or deleted 205 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/