Internet DRAFT - draft-korhonen-detnet-telreq
draft-korhonen-detnet-telreq
Network Working Group J. Korhonen
Internet-Draft Broadcom Corporation
Intended status: Informational May 27, 2015
Expires: November 28, 2015
Deterministic networking for radio access networks
draft-korhonen-detnet-telreq-00
Abstract
This document describes requirements for deterministic networking in
cellular radio access and transport networks context. The
requirements include time synchronization, clock distribution and
ways of establishing time-sensitive streams for both Layer-2 and
Layer-3 user plane traffic using IETF protocol solutions.
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."
This Internet-Draft will expire on November 28, 2015.
Copyright Notice
Copyright (c) 2015 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.
Korhonen Expires November 28, 2015 [Page 1]
Internet-Draft DetNet for RAN May 2015
Table of Contents
1. Introduction and background . . . . . . . . . . . . . . . . . 2
2. Network architecture . . . . . . . . . . . . . . . . . . . . 3
3. Time synchronization requirements . . . . . . . . . . . . . . 5
4. Time-sensitive stream requirements . . . . . . . . . . . . . 6
5. Security considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction and background
The recent developments in telecommunication networks, especially in
the cellular domain, are heading towards transport networks where
precise time synchronization support has to be one of the basic
building blocks. While the transport networks themselves have
practically transitioned to all-AP packet based networks to meet the
bandwidth and cost requirements, a highly accurate clock distribution
has become a challenge. Earlier the transport networks in the
cellular domain were typically time division and multiplexing (TDM)
-based and provided frequency synchronization capabilities as a part
of the transport media. Alternatively other technologies such as
Global Positioning System (GPS) or Synchronous Ethernet (SyncE)
[SyncE] were used. New radio access network deployment models and
architectures may require time sensitive networking services with
strict requirements on other parts of the network that previously
were not considered to be packetized at all. The time and
synchronization support are already topical for backhaul and midhaul
packet networks [MEF], and becoming a real issue for fronthaul
networks. Specifically in the fronthaul networks the timing and
synchronization requirements can be extreme for packet based
technologies, for example, in order of sub +-20 ns packet delay
variation (PDV) and frequency accuracy of +0.002 PPM [Fronthaul].
Both Ethernet and IP/MPLS [RFC3031] (and PseudoWires (PWE) [RFC3985]
for legacy transport support) have become popular tools to build and
manage new all-IP radio access networks (RAN)
[I-D.kh-spring-ip-ran-use-case]. Although various timing and
synchronization optimizations have already been proposed and
implemented including 1588 PTP enhancements
[I-D.ietf-tictoc-1588overmpls][I-D.mirsky-mpls-residence-time], these
solution are not necessarily sufficient for the forthcoming RAN
architectures or guarantee the higher time-synchronization
requirements [CPRI]. There are also existing solutions for the TDM
over IP [RFC5087] [RFC4553] or Ethernet transports [RFC5086]. The
really interesting and important existing work for time sensitive
Korhonen Expires November 28, 2015 [Page 2]
Internet-Draft DetNet for RAN May 2015
networking has been done for Ethernet [TSNTG], which specifies the
use of IEEE 1588 time precision protocol (PTP) [IEEE1588] in the
context of IEEE 802.1D and IEEE 802.1Q. While IEEE 802.1AS
[IEEE8021AS] specifies a Layer-2 time synchronizing service other
specification, such as IEEE 1722 [IEEE1722] specify Ethernet-based
Layer-2 transport for time-sensitive streams. New promising work
seeks to enable the transport of time-sensitive fronthaul streams in
Ethernet bridged networks [IEEE8021CM]. Similarly to IEEE 1722 there
is an ongoing standardization effort to define Layer-2 transport
encapsulation format for transporting radio over Ethernet (RoE) in
IEEE 1904.3 Task Force [IEEE19043].
As already mentioned all-IP RANs and various "haul" networks would
benefit from time synchronization and time-sensitive transport
services. Although Ethernet appears to be the unifying technology
for the transport there is still a disconnect providing Layer-3
services. The protocol stack typically has a number of layers below
the Ethernet Layer-2 that shows up to the Layer-3 IP transport. It
is not uncommon that on top of the lowest layer (optical) transport
there is the first layer of Ethernet followed one or more layers of
MPLS, PseudoWires and/or other tunneling protocols finally carrying
the Ethernet layer visible to the user plane IP traffic. While there
are existing technologies, especially in MPLS/PWE space, to establish
circuits through the routed and switched networks, there is a lack of
signaling the time synchronization and time-sensitive stream
requirements/reservations for Layer-3 flows in a way that the entire
transport stack is addressed and the Ethernet layers that needs to be
configured are addressed. Furthermore, not all "user plane" traffic
will be IP. Therefore, the same solution need also address the use
cases where the user plane traffic is again another layer or Ethernet
frames. There is existing work describing the problem statement
[I-D.finn-detnet-problem-statement] and the architecture
[I-D.finn-detnet-architecture] for deterministic networking (DetNet)
that eventually targets to provide solutions for time-sensitive (IP/
transport) streams with deterministic properties over Ethernet-based
switched networks.
This document describes requirements for deterministic networking in
a cellular telecom transport networks context. The requirements
include time synchronization, clock distribution and ways of
establishing time-sensitive streams for both Layer-2 and Layer-3 user
plane traffic using IETF protocol solutions.
2. Network architecture
Figure Figure 1 illustrates a typical, 3GPP defined, cellular network
architecture, which also has fronthaul and midhaul network segments.
The fronthaul refers to the network connecting base stations (base
Korhonen Expires November 28, 2015 [Page 3]
Internet-Draft DetNet for RAN May 2015
band processing units) to the remote radio heads (antennas). The
midhaul network typically refers to the network inter-connecting base
stations (or small/pico cells).
Fronthaul networks build on the available excess time after the base
band processing of the radio frame has completed. Therefore, the
available time for networking is actually very limited, which in
practise determines how far the remote radio heads can be from the
base band processing units (i.e. base stations). For example, in a
case of LTE radio the Hybrid ARQ processing of a radio frame is
allocated 3 ms. Typically the processing completes way earlier (say
up to 400 us, could be much less, though) thus allowing the remaining
time to be used e.g. for fronthaul network. 200 us equals roughly 40
km of optical fiber based transport (assuming round trip time would
be total 2*200 us). The base band processing time and the available
"delay budget" for the fronthaul is a subject to change, possibly
dramatically, in the forthcoming "5G" to meet, for example, the
envisioned reduced radio round trip times, and other architecural and
service requirements [NGMN].
The maximum "delay budget" is then consumed by all nodes and required
buffering between the remote radio head and the base band processing
in addition to the distance incurred delay. Packet delay variation
(PDV) is problematic to fronthaul networks and must be minimized. If
the transport network cannot guarantee low enough PDV additional
buffering has to be introduced at the edges of the network to buffer
out the jitter. Any buffering will eat up the total available delay
budget, though. Section Section 3 will discuss the PDV requirements
in more detail.
Korhonen Expires November 28, 2015 [Page 4]
Internet-Draft DetNet for RAN May 2015
Y (remote radios)
\
Y__ \.--. .--. +------+
\_( `. +---+ _(Back`. | 3GPP |
Y------( Front )----|eNB|----( Haul )----| core |
( ` .Haul ) +---+ ( ` . ) ) | netw |
/`--(___.-' \ `--(___.-' +------+
Y_/ / \.--. \
Y_/ _( Mid`. \
( Haul ) \
( ` . ) ) \
`--(___.-'\_____+---+ (small cells)
\ |SCe|__Y
+---+ +---+
Y__|eNB|__Y
+---+
Y_/ \_Y ("local" radios)
Figure 1: Generic 3GPP-based cellular network architecture with
Front/Mid/Backhaul networks
3. Time synchronization requirements
Cellular networks starting from long term evolution (LTE) [TS36300]
[TS23401] radio the phase synchronization is also needed in addition
to the frequency synchronization. The commonly referenced fronthaul
network synchronization requirements are typically drawn from the
common public radio interface (CPRI) [CPRI] specification that
defines the transport protocol between the base band processing -
radio equipment controller (REC) and the remote antenna - radio
equipment (RE). However, the fundamental requirements still
originate from the respective cellular system and radio
specifications such as the 3GPP ones [TS25104][TS36104][TS36211]
[TS36133].
The fronthaul time synchronization requirements for the current 3GPP
LTE-based networks are listed below:
Transport link contribution to radio frequency error:
+-2 PPB. The given value is considered to be "available" for the
fronthaul link out of the total 50 PPB budget reserved for the
radio interface.
Delay accuracy:
+-8.138 ns i.e. +-1/32 Tc (UMTS Chip time, Tc, 1/3.84 MHz) to
downlink direction and excluding the (optical) cable length in one
Korhonen Expires November 28, 2015 [Page 5]
Internet-Draft DetNet for RAN May 2015
direction. Round trip accuracy is then +-16.276 ns. The value is
this low to meet the 3GPP timing alignment error (TAE) measurement
requirements.
Packet delay variation (PDV):
* For multiple input multiple output (MIMO) or TX diversity
transmissions, at each carrier frequency, TAE shall not exceed
65 ns (i.e. 1/4 Tc).
* For intra-band contiguous carrier aggregation, with or without
MIMO or TX diversity, TAE shall not exceed 130 ns (i.e. 1/2
Tc).
* For intra-band non-contiguous carrier aggregation, with or
without MIMO or TX diversity, TAE shall not exceed 260 ns (i.e.
one Tc).
* For inter-band carrier aggregation, with or without MIMO or TX
diversity, TAE shall not exceed 260 ns.
The above listed time synchronization requirements are hard to meet
even with point to point connected networks, not to mention cases
where the underlying transport network actually constitutes of
multiple hops. It is expected that network deployments have to deal
with the jitter requirements buffering at the very ends of the
connections, since trying to meet the jitter requirements in every
intermediate node is likely to be too costly. However, every measure
to reduce jitter and delay on the path are valuable to make it easier
to meet the end to end requirements.
In order to meet the timing requirements both senders and receivers
must is perfect sync. This asks for a very accurate clock
distribution solution. Basically all means and hardware support for
guaranteeing accurate time synchronization in the network is needed.
As an example support for 1588 transparent clocks (TC) in every
intermediate node would be helpful.
4. Time-sensitive stream requirements
In addition to the time synchronization requirements listed in
Section Section 3 the fronthaul networks assume practically error
free transport. The maximum bit error rate (BER) has been defined to
be 10^-12. When packetized that would equal roughly to packet error
rate (PER) of 2.4*10^-9 (assuming ~300 bytes packets).
Retransmitting lost packets and/or using forward error coding (FEC)
to circumvent bit errors are practically impossible due additional
incurred delay. Using redundant streams for better guarantees for
Korhonen Expires November 28, 2015 [Page 6]
Internet-Draft DetNet for RAN May 2015
delivery is also practically impossible due to high bandwidth
requirements fronthaul networks have. For instance, current
uncompressed CPRI bandwidth expansion ratio is roughly 20:1 compared
to the IP layer user payload it carries in a "radio sample form".
The other fundamental assumption is that fronthaul links are
symmetric. Last, all fronthaul streams (carrying radio data) have
equal priority and cannot delay or pre-empt each other. This implies
the network has always be sufficiently under subscribed to guarantee
each time-sensitive flow meets their schedule.
Mapping the fronthaul requirements to [I-D.finn-detnet-architecture]
Section 3 "Providing the DetNet Quality of Service" what is seemed
usable are:
(a) Zero congestion loss.
(b) Pinned-down paths.
The current time-sensitive networking features may still not be
sufficient for fronthaul traffic. Therefore, having specific
profiles that take the requirements of fronthaul into account are
deemed to be useful [IEEE8021CM].
The actual transport protocols and/or solutions to establish required
transport "circuits" (pinned-down paths) for fronthaul traffic are
still undefined. Those are likely to include but not limited to
solutions directly over Ethernet, over IP, and MPLS/PseudoWire
transport.
5. Security considerations
Establishing time-sensitive streams in the network entails reserving
networking resources sometimes for a considerable long time. It is
important that these reservation requests must be authenticated to
prevent malicious reservation attempts from hostile nodes or even
accidental misconfiguration. This is specifically important in a
case where the reservation requests span administrative domains.
Furthermore, the reservation information itself should be digitally
signed to reduce the risk where a legitimate node pushed a stale or
hostile configuration into the networking node.
6. IANA Considerations
This document has no IANA considerations.
Korhonen Expires November 28, 2015 [Page 7]
Internet-Draft DetNet for RAN May 2015
7. Acknowledgements
The author(s) ACK and NACK.
8. Informative References
[CPRI] CPRI Cooperation, "Common Public Radio Interface (CPRI);
Interface Specification", CPRI Specification V6.1, July
2014, <http://www.cpri.info/downloads/
CPRI_v_6_1_2014-07-01.pdf>.
[Fronthaul]
Chen, D. and T. Mustala, "Ethernet Fronthaul
Considerations", IEEE 1904.3, February 2015,
<http://www.ieee1904.org/3/meeting_archive/2015/02/
tf3_1502_che n_1a.pdf>.
[I-D.finn-detnet-architecture]
Finn, N., Thubert, P., and M. Teener, "Deterministic
Networking Architecture", draft-finn-detnet-
architecture-01 (work in progress), March 2015.
[I-D.finn-detnet-problem-statement]
Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", draft-finn-detnet-problem-statement-01 (work
in progress), October 2014.
[I-D.ietf-tictoc-1588overmpls]
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS
Networks", draft-ietf-tictoc-1588overmpls-06 (work in
progress), April 2014.
[I-D.kh-spring-ip-ran-use-case]
Khasnabish, B., hu, f., and L. Contreras, "Segment Routing
in IP RAN use case", draft-kh-spring-ip-ran-use-case-02
(work in progress), November 2014.
[I-D.mirsky-mpls-residence-time]
Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
and S. Vainshtein, "Residence Time Measurement in MPLS
network", draft-mirsky-mpls-residence-time-06 (work in
progress), May 2015.
Korhonen Expires November 28, 2015 [Page 8]
Internet-Draft DetNet for RAN May 2015
[IEEE1588]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE Std 1588-2008, 2008,
<http://standards.ieee.org/findstds/
standard/1588-2008.html>.
[IEEE1722]
IEEE, "1722-2011 - IEEE Standard for Layer 2 Transport
Protocol for Time Sensitive Applications in a Bridged
Local Area Network", IEEE Std 1722-2011, 2011,
<http://standards.ieee.org/findstds/
standard/1722-2011.html>.
[IEEE19043]
IEEE Standards Association, "IEEE 1904.3 TF", IEEE 1904.3,
2015, <http://www.ieee1904.org/3/tf3_home.shtml>.
[IEEE8021AS]
IEEE, "Timing and Synchronizations (IEEE 802.1AS-2011)",
IEEE 802.1AS-2001, 2011,
<http://standards.ieee.org/getIEEE802/
download/802.1AS-2011.pdf>.
[IEEE8021CM]
Farkas, J., "Time-Sensitive Networking for Fronthaul",
Unapproved PAR, PAR for a New IEEE Standard; IEEE
P802.1CM, April 2015,
<http://www.ieee802.org/1/files/public/docs2015/
new-P802-1CM-dr aft-PAR-0515-v02.pdf>.
[MEF] MEF, "Mobile Backhaul Phase 2 Amendment 1 -- Small Cells",
MEF 22.1.1, July 2014,
<http://www.mef.net/Assets/Technical_Specifications/PDF/
MEF_22.1.1.pdf>.
[NGMN] NGMN Alliance, "5G White Paper", NGMN 5G White Paper v1.0,
February 2015, <https://www.ngmn.org/uploads/media/
NGMN_5G_White_Paper_V1_0.pdf>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
Korhonen Expires November 28, 2015 [Page 9]
Internet-Draft DetNet for RAN May 2015
[RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time
Division Multiplexing (TDM) over Packet (SAToP)", RFC
4553, June 2006.
[RFC5086] Vainshtein, A., Sasson, I., Metz, E., Frost, T., and P.
Pate, "Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched Network
(CESoPSN)", RFC 5086, December 2007.
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi,
"Time Division Multiplexing over IP (TDMoIP)", RFC 5087,
December 2007.
[SyncE] ITU-T, "G.8261 : Timing and synchronization aspects in
packet networks", Recommendation G.8261, August 2013,
<http://www.itu.int/rec/T-REC-G.8261>.
[TS23401] 3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013.
[TS25104] 3GPP, "Base Station (BS) radio transmission and reception
(FDD)", 3GPP TS 25.104 3.14.0, March 2007.
[TS36104] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Base Station (BS) radio transmission and
reception", 3GPP TS 36.104 10.11.0, July 2013.
[TS36133] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Requirements for support of radio resource
management", 3GPP TS 36.133 12.7.0, April 2015.
[TS36211] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Physical channels and modulation", 3GPP TS
36.211 10.7.0, March 2013.
[TS36300] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA)
and Evolved Universal Terrestrial Radio Access Network
(E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300
10.11.0, September 2013.
[TSNTG] IEEE Standards Association, "IEEE 802.1 Time-Sensitive
Networks Task Group", 2013,
<http://www.IEEE802.org/1/pages/avbridges.html>.
Korhonen Expires November 28, 2015 [Page 10]
Internet-Draft DetNet for RAN May 2015
Author's Address
Jouni Korhonen
Broadcom Corporation
3151 Zanker Road
San Jose, CA 95134
USA
Email: jouni.nospam@gmail.com
Korhonen Expires November 28, 2015 [Page 11]