One document matched: draft-briscoe-tsvwg-ecn-encap-guidelines-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!-- Alterations to I-D/RFC boilerplate -->
<?rfc private="" ?>
<!-- Default private="" Produce an internal memo 2.5pp shorter than an I-D or RFC -->
<?rfc rfcprocack="yes" ?>
<!-- Default rfcprocack="no" add a short sentence acknowledging xml2rfc -->
<?rfc strict="no" ?>
<!-- Default strict="no" Don't check I-D nits -->
<?rfc rfcedstyle="yes" ?>
<!-- Default rfcedstyle="yes" attempt to closely follow finer details from the latest observable RFC-Editor style -->
<!-- IETF process -->
<?rfc iprnotified="no" ?>
<!-- Default iprnotified="no" I haven't disclosed existence of IPR to IETF -->
<!-- ToC format -->
<?rfc toc="yes" ?>
<!-- Default toc="no" No Table of Contents -->
<!-- Cross referencing, footnotes, comments -->
<?rfc symrefs="yes"?>
<!-- Default symrefs="no" Don't use anchors, but use numbers for refs -->
<?rfc sortrefs="yes"?>
<!-- Default sortrefs="no" Don't sort references into order -->
<?rfc comments="yes" ?>
<!-- Default comments="no" Don't render comments -->
<?rfc inline="no" ?>
<!-- Default inline="no" if comments is "yes", then render comments inline; otherwise render them in an `Editorial Comments' section -->
<!-- Pagination control -->
<?rfc compact="yes"?>
<!-- Default compact="no" Start sections on new pages -->
<?rfc subcompact="no"?>
<!-- Default subcompact="(as compact setting)" yes/no is not quite as compact as yes/yes -->
<!-- HTML formatting control -->
<?rfc emoticonic="yes" ?>
<!-- Default emoticonic="no" Doesn't prettify HTML format -->
<rfc category="info" docName="draft-briscoe-tsvwg-ecn-encap-guidelines-00"
ipr="trust200902">
<front>
<title abbrev="ECN Encapsulation Guidelines">Guidelines for Adding
Congestion Notification to Protocols that Encapsulate IP</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>BT</organization>
<address>
<postal>
<street>B54/77, Adastral Park</street>
<street>Martlesham Heath</street>
<city>Ipswich</city>
<code>IP5 3RE</code>
<country>UK</country>
</postal>
<phone>+44 1473 645196</phone>
<email>bob.briscoe@bt.com</email>
<uri>http://bobbriscoe.net/</uri>
</address>
</author>
<date day="02" month="March" year="2011" />
<area>Transport</area>
<workgroup>Transport Area Working Group</workgroup>
<keyword>Congestion Control and Management</keyword>
<keyword>Congestion Notification</keyword>
<keyword>Information Security</keyword>
<keyword>Tunnelling</keyword>
<keyword>Encapsulation & Decapsulation</keyword>
<keyword>Protocol</keyword>
<keyword>ECN</keyword>
<keyword>Layering</keyword>
<abstract>
<t>The purpose of this document is to guide the design of congestion
notification in any lower layer protocol that encapsulates IP. The aim
is for explicit congestion signals to propagate consistently from lower
layer protocols into IP. Then the IP internetwork layer can act as a
portability layer to carry congestion notification from non-IP-aware
congested nodes to the destination transport endpoint. Following these
guidelines should assure interworking between new encapsulations of
congestion notification, whether specified by the IETF or other
standards bodies.</t>
</abstract>
</front>
<!-- ================================================================ -->
<middle>
<!-- ================================================================ -->
<section anchor="ecnencap_Introduction" title="Introduction">
<t>Explicit Congestion Notification (ECN <xref target="RFC3168"></xref>)
was defined in the IP header to allow a congested resource to notify the
onset of congestion without having to drop packets, by explicitly
marking a proportion of packets with the congestion experienced (CE)
codepoint.<!--In the layered model of communication, each layer accepts requests to forward PDUs and eventually returns
a status code to the higher layer. Without ECN, each layer returns either a 'delivered' status code or an
implicit 'not delivered'. Explicit notification of congestion adds a useful 'delivered but congestion
experienced' status code to each layer interface.--></t>
<t>Some subnetwork technologies (e.g. Frame Relay) have always supported
explicit notification of congestion and it is gradually being added to
others. The IETF would like to encourage this trend. Of course, the IETF
does not have standards authority over every link layer protocol. So
this document gives guidelines for designing propagation of congestion
notification across the interface between IP and protocols that may
encapsulate IP (i.e. that can be layered beneath IP).</t>
<t>Each lower layer technology will exhibit slightly different issues
and compromises, so the IETF or the relevant standards body must be free
to define the specifics of each lower layer congestion notification
scheme. However, if the guidelines below are followed, congestion
notification should interwork between different technologies, using IP
in its role as a 'portability layer'.</t>
<t>Often link and physical layer resources are 'non-blocking' by design.
In these cases congestion notification does not need to be implemented
at the lower layer; ECN in IP would be sufficient. A degenerate example
is a point-to-point Ethernet link. Excess loading of the link merely
causes the queue from the higher layer to back up, while the lower layer
remains immune to congestion. Even a whole meshed subnetwork can be made
immune to interior congestion by careful network design; interior links
can be sufficiently provisioned relative to the edge capacities to
absorb even worst-case patterns of load.</t>
<t>Nonetheless, other subnetworks can involve a mesh of links where
traffic can converge on interior nodes and cause congestion. One way to
support ECN in such cases has been to use so called "layer 3 switches".
These are Ethernet switches that can bury into the Ethernet payload to
find an IP header and manipulate or act on certain IP fields (Diffserv,
ECN etc). For instance, in Data Center TCP <xref target="DCTCP"></xref>,
layer 3 switches are used to mark the ECN field of the IP header within
the Ethernet payload.</t>
<t>Although marking the IP header on a layer 3 switch is a useful
tactical approach in a controlled environment such as within a data
centre, it presents problems in more general settings. For instance,
many Ethernet switches are not layer 3 switches so they cannot read and
modify an IP payload. Also it might be costly to find an IP header (v4
or v6) when it may be encapsulated by more than one Ethernet header
(e.g. when using multiple encapsulations of MAC in MAC <xref
target="IEEE802.1Qah"></xref>). </t>
<t>In these more general cases, ECN may best be supported by
standardising explicit notification of congestion into the specific link
layer protocol. It will then also be necessary to define how the
end-station of the lower layer subnet propagates this explicit signal up
to the IP internetwork layer.</t>
<t>Many logical link technologies are based on self-contained protocol
data units (PDUs). In these typical cases, at each decapsulation of an
outer (lower layer) header, any congestion marking will have to be
arranged to propagate into the forwarded (upper layer) header. It can
then continue forwards, possibly picking up further congestion signals
from congested resources along the way until it finally reaches the
destination transport. Then typically the destination will feed this
congestion notification back to the source transport.</t>
<t>The purpose of this document is to guide the design of congestion
notification in any lower layer, so that explicit congestion signals in
PDUs at a lower layer will propagate consistently into PDUs of the upper
IP layer.</t>
<t>These guidelines are consistent with the way in which propagation of
ECN has already been defined for IP-in-IP <xref
target="RFC6040"></xref>, IP-in-MPLS and MPLS-in-MPLS <xref
target="RFC5129"></xref>. <xref target="RFC6040"></xref> brings the
original ECN specification <xref target="RFC3168"></xref> and the
specification of IPsec <xref target="RFC4301"></xref> into line. <xref
target="RFC5129"></xref> defines how a label switched router can mark
the outer MPLS shim header to signal congestion and, when the packets
reach the decapsulator at the edge of the MPLS network, the marks can be
propagated into the IP header (or into an inner MPLS header) and onward
to the destination transport.</t>
<section anchor="ecnencap_Scope" title="Scope">
<t>This document only concerns wire protocol processing of explicit
notification of congestion and makes no changes or recommendations
concerning algorithms for congestion marking or congestion
response.</t>
<t>This document focuses on the congestion notification interface
between IP (v4 or v6) and lower layer protocols that can encapsulate
IP. However, it is likely that the guidelines will also be useful when
a lower layer protocol encapsulates itself (e.g. Ethernet MAC in MAC
<xref target="IEEE802.1Qah"></xref>) or when it encapsulates other
protocols. </t>
<t>In some layer 2 technologies, explicit congestion notification has
been defined for use internally within the subnet, but the interface
with ECN in IP has not been defined. If the lower layer has its own
feedback and load regulation, there is no need to propagate congestion
signalling up the layers. For instance, EFCI (explicit forward
congestion indication) has been present in ATM <xref
target="ITU-T.I.371"></xref> for a long time, but it has been used for
internal control and management rather than being propagated to
endpoint transports for them to control end-to-end congestion. FECN
(forward ECN) was included in Frame Relay standards but Frame Relay
has no internal rate control mechanisms. Therefore, as no interface to
IP ECN has ever been defined, FECN is only used to detect where more
capacity should be provisioned <xref target="Buck00"></xref>.</t>
<t>In another example, quantised congestion notification (QCN - also
known as backward congestion notification or BCN) is being defined for
Ethernet <xref target="IEEE802.1Qau"></xref>. QCN avoids the need to
define a congestion notification interface with IP by limiting itself
to confined scenarios where all endpoints are directly attached by the
same layer 2 technology, such as in server area networks. One aim of
the guidelines below is to avoid an outcome where one congestion
notification scheme has been defined for internal use within a
subnetwork technology, but then another has to be defined for
interfacing to IP.</t>
<t>Whether some form of explicit congestion notification already
exists in a lower layer protocol or whether it is being added, this
document can be used to design the interface to propagate explicit
congestion notification between the lower layer protocol and IP. </t>
<t>§9.3 of RFC3168 on adding ECN to IP <xref
target="RFC3168"></xref> pointed out that the IETF might in future
want to define how ECN should be added to IETF protocols that
encapsulate IP, such as L2TP <xref target="RFC2661"></xref>, GRE
[<xref format="counter" target="RFC1701"></xref>, <xref
format="counter" target="RFC2784"></xref>] or PPTP <xref
target="RFC2637"></xref>. More recently, the IETF is working on adding
ECN support as a TRILL header option <xref
target="trill-rbridge-options"></xref>. This document is intended to
provide design guidelines for any protocol that might encapsulate IP,
whether maintained by the IETF or by other standards bodies. </t>
</section>
</section>
<!-- ================================================================ -->
<section anchor="ecnencap_Reqs_Language" title="Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t>Further terminology used within this document:<list style="hanging">
<t hangText="Protocol data unit (PDU):">Information that is
delivered as a unit among peer entities of a layered network
consisting of protocol control information (typically a header) and
possibly user data of that layer. The scope of this document
includes layer 2 and layer 3 networks, where the PDU is respectively
termed a frame or a packet. PDU is a general term for either. It
also includes a payload with a shim header lying somewhere between
layer 2 & 3.</t>
<t hangText="Encapsulator:">The link or tunnel endpoint function
that adds an outer header to a PDU (also termed the 'link ingress',
the 'ingress tunnel endpoint' or just the 'ingress' where the
context is clear).</t>
<t hangText="Decapsulator:">The link or tunnel endpoint function
that removes an outer header from a PDU (also termed the 'link
egress', the 'egress tunnel endpoint' or just the 'egress' where the
context is clear).</t>
<t hangText="Incoming header:">The header of an arriving PDU before
encapsulation.</t>
<t hangText="Outer header:">The header added to encapsulate a
PDU.</t>
<t hangText="Inner header:">The header encapsulated by the outer
header.</t>
<t hangText="Outgoing header:">The header forwarded by the
decapsulator using logic that combines the fields in the outer and
inner headers.</t>
<t hangText="ECN-PDU:">A PDU destined for an ECN-capable transport
(i.e. a transport that will understand explicit congestion
notifications). This is intended to be a general term for a PDU at
any layer, not just an IP PDU. An IP packet with a non-zero ECN
field would be an ECN-PDU, but the term is intended to also be used
to describe PDUs of protocols that encapsulate IP packets.</t>
<t hangText="Not-ECN-PDU:">A PDU destined for a transport that is
not ECN-capable.</t>
<t hangText="Load Regulator:">For each flow of PDUs, the transport
function that is capable of controlling the data rate. Typically
located at the data source, but in-path nodes can regulate load in
some congestion control arrangements (e.g. admission control or
policing nodes). Note the term "a function capable of controlling
the load" deliberately includes a transport that doesn't actually
control the load but ought to (e.g. an application without
congestion control that uses UDP).</t>
<t hangText="Congestion Baseline:">The function that created (or
most recently reset) the congestion notification field.</t>
</list></t>
</section>
<section anchor="ecnencap_Design_Guidelines"
title="Design Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP">
<t>These guidelines are consitent with the guidelines on the design of
alternate schemes for IP tunnelling of the ECN field <xref
target="RFC6040"></xref> and the more general best current practice for
the design of alternate ECN schemes given in <xref
target="RFC4774"></xref>.</t>
<t>The capitalised term 'SHOULD (NOT)' has been used in preference to
'MUST (NOT)' because it is difficult to know the compromises that will
be necessary in each protocol design. If a particular protocol design
chooses to contradict a 'SHOULD (NOT)' given in the advice below, it
MUST include a sound justification.</t>
<section anchor="ecnencap_WireProtocolECNSupport"
title="Indication of ECN Support in the Wire Protocol">
<t>An active queue management (AQM) scheme SHOULD NOT apply explicit
congestion notifications to PDUs that are destined for legacy
transports that will not understand them. Therefore the lower layer
needs to be able to distinguish whether PDUs are destined for an
ECN-capable transport or not. We use the term ECN-PDUs for a PDU that
is destined for an ECN-capable transport, and Not-ECN-PDU for one
destined for a transport that will not understand ECN.</t>
<t>In IP, if the ECN field in each PDU is cleared to the Not-ECT (not
ECN-capable transport) codepoint, it indicates that the transport will
not understand congestion markings. The mechanism a lower layer uses
to distinguish the ECN-capability of PDUs need not mimic that of IP,
but it should achieve the same outcome. For instance, ECN-capable
transports might only be allowed to use PDUs identified by a
particular set of labels or tags. Alternatively, logical link
protocols that use flow state might determine whether a PDU should be
congestion marked by checking for ECN-support in the flow state.
Whatever mechanisms might be invented, it SHOULD be possible for the
lower layer protocol not to forward congestion on Not-ECN-PDUs
destined for transports that will not understand them.</t>
<t>The per-domain checking of ECN support in MPLS <xref
target="RFC5129"></xref> is a good example of a way to avoid sending
congestion markings to transports that will not understand them. In
MPLS, header space is extremely limited, therefore RFC5129 does not
provide a field in the MPLS header to indicate that the PDU is
destined for an ECN-capable transport. Instead, interior nodes in a
domain are allowed to set explicit congestion indications without
checking whether the PDU is destined for a transport that will
understand them. Nonetheless, this is made safe by requiring that the
network operator upgrades all decapsulating edges of a whole domain to
support ECN at once. Therefore, on decapsulation there will always be
a check that the higher layer transport is ECN-capable (by checking
for the Not-ECT codepoint in the inner IP header). If the decapsulator
discovers that the higher layer (inner header) indicates the transport
will not understand ECN, it drops an ECN-marked packet on behalf of
the earlier congested node (see Decapsulation Guideline <xref
target="ecnencap_dropNot-ECTinnerCEouter"></xref> in <xref
target="ecnencap_DecapGuidelines"></xref>).</t>
<t>Note that it was only appropriate to define such an incremental
deployment strategy because MPLS is targeted solely at professional
operators, who can be expected to ensure that a whole subnetwork is
consistently configured. This strategy might not be appropriate for
other link technologies targeted at zero-configuration deployment by
the general public (e.g. Ethernet). For such 'plug-and-play'
environments it will be necessary to invent a failsafe approach that
ensures congestion markings will never fall into black holes however
inconsistently a system is put together. Alternatively, congestion
notification relying on correct system configuration could be confined
to flavours of Ethernet intended only for professional network
operators, such as IEEE 802.1ah Provider Backbone Bridges (PBB).</t>
</section>
<section anchor="ecnencap_EncapGuidelines"
title="Encapsulation Guidelines">
<t><list style="numbers">
<t>Even if an incoming PDU is capable of understanding ECN (an
ECN-PDU), the ingress to a subnet SHOULD disable ECN when it
forwards the PDU at the lower layer (e.g. by setting the outer
header of the PDU to identify it as a Not-ECN-PDU) unless the
ingress can guarantee that the corresponding egress of the link
will correctly propagate any congestion markings added to the
outer header across the subnet. This guarantee might be
provided:<list style="symbols">
<t>by inherent design of the protocol</t>
<t>by configuration</t>
<t>by the ingress explicitly checking that the egress
propagates ECN.</t>
</list></t>
<t anchor="ecnencap_Encap_Copy">Once the ingress to a subnet has
established that ECN will be correctly propagated at the egress,
on encapsulation it SHOULD encode the same level of congestion in
outer headers as is arriving in incoming headers. For example it
might copy any incoming congestion notification into the outer
header of the lower layer protocol.<vspace blankLines="1" />This
meets the requirement that all outer headers ought to reflect
congestion accumulated along the whole upstream path, not just
since the ingress of the subnet. More precisely, congestion
notifications in outer headers SHOULD reflect congestion since the
node that is regulating the load (the Load Regulator). <vspace
blankLines="1" />This guideline is intended to ensure that any
bulk congestion monitoring further downstream is meaningful (e.g.
by a network management node monitoring ECN in passing frames).
The level of ECN in passing frames is not meaningful unless the
Congestion Baseline (where congestion notifications start at zero)
is known. It is not useful to start a new Congestion Baseline at
the start of each subnet, but it is useful to define the
Congestion Baseline at the node that is regulating the load (the
Load Regulator). <!--{ToDo: It may be safe to assume a subnetwork technology will not span a trust boundary.
Espectially if copy on encap is not desirable, e.g. if using Floyd's 1-bit MPLS scheme.}--><vspace
blankLines="1" />In some circumstances (e.g. pseudowire emulations
with link-local flow control), the whole path is divided into
segments, each with its own congestion notification and feedback
loop. In these cases, the function that regulates load at the
start of each segment will need to reset congestion notification
(i.e. clear any accumulated congestion notifications) at the start
of its segment. </t>
</list></t>
</section>
<section anchor="ecnencap_DecapGuidelines"
title="Decapsulation Guidelines">
<t>Congestion notification SHOULD NOT simply be copied from outer
headers to the forwarded header. The outgoing congestion notification
field SHOULD be calculated from the inner and outer headers, using the
following rules. If there is any conflict, rules earlier in the list
take precedence over rules later in the list:<list style="numbers">
<t anchor="ecnencap_dropNot-ECTinnerCEouter">If the arriving inner
header is a Not-ECN-PDU it implies the transport will not
understand explicit congestion markings. Then:<list
style="symbols">
<t>If the outer header carries an explicit congestion marking,
the packet SHOULD be dropped—the only indication of
congestion the transport will understand.</t>
<!--{ToDo: RFC6040 allows forwarding if it is not the most severe marking.}-->
<t>If the outer is an ECN-PDU that carries no indication of
congestion or a Not-ECN-PDU the PDU SHOULD be forwarded, but
still only as a Not-ECN-PDU.</t>
</list></t>
<t>If the outer header does not support explicit congestion
notification (a Not-ECN-PDU), but the inner header does (an
ECN-PDU), the inner header SHOULD be forwarded unchanged.</t>
<t>In some lower layer protocols congestion may be signalled as a
numerical level, such as in quantised congestion notification
<xref target="IEEE802.1Qau"></xref>. If such an encoding
encapsulates an ECN-capable IP packet, a function will be needed
to convert the quantised congestion level into the frequency of
congestion markings in outgoing IP packets.</t>
<t>Congestion indications may be ranked by severity. For instance
no congestion would be the weakest indication, with possibly
increasing levels of congestion encoded by increasingly stronger
indications, e.g. pre-congestion notification (PCN) can be encoded
at two severity levels <xref
target="pcn-3-in-1-encoding"></xref>.<vspace blankLines="1" />If
the arriving inner header is an ECN-PDU, where the inner and outer
headers carry indications of congestion of different severity, the
more severe indication SHOULD be forwarded in preference to the
less severe. Obviously, if the severities in both inner and outer
are the same, the same severity should be forwarded.</t>
<t>The inner and outer headers might carry a combination of
congestion notification fields that should not be possible given
any currently used protocol transitions. For instance, if
Encapsulation Guideline <xref target="ecnencap_Encap_Copy"></xref>
in <xref target="ecnencap_EncapGuidelines"></xref> had been
followed, it should not be possible to have a less severe
indication of congestion in the outer than in the inner. It MAY be
appropriate to log unexpected combiantions of headers and possibly
raise an alarm. If a safe outgoing codepoint can be defined for
such a PDU, the PDU SHOULD be forwarded rather than dropped.
<vspace blankLines="1" />Some implementers discard PDUs with
currently unused combinations of headers just in case they
represent an attack. However, an approach using alarms is
preferable so that operators can keep track of possible attacks
but currently unused combinations are not precluded from use in
future standards actions.</t>
</list></t>
</section>
<section title="Reframing and Congestion Markings">
<t>Where framing boundaries are different between two layers,
congestion indications SHOULD be propagated on the basis that a
congestion indication on a PDU applies to all the octets in the PDU.
On average, an encapsulator or decapsulator SHOULD approximately
preserve the number of marked octets arriving and leaving (counting
the size of inner headers, but not added encapsulating headers).</t>
<t>An algorithm for reframing congestion indications over different
sized PDUs SHOULD NOT hold any marked octets back to be signalled in
later frames. For instance, a reframing algorithm might maintain a
count of marked octets arriving and departing. Such an algorithm
SHOULD propagate a congestion indication in the next departing PDU if
there have been more arriving marked octets than departing, even if
after marking the next PDU the count of departing marked octets will
be greater than those arriving.</t>
</section>
</section>
<!-- ================================================================ -->
<!-- ================================================================ -->
<section anchor="ecnencap_IANA_Considerations" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<!-- ================================================================ -->
<section anchor="ecnencap_Security_Considerations"
title="Security Considerations">
<t>{TBA}</t>
</section>
<!-- ================================================================ -->
<section anchor="ecnencap_Conclusions" title="Conclusions">
<t>{TBA}</t>
</section>
<!-- ================================================================ -->
<section anchor="ecnencap_Acknowledgements" title="Acknowledgements">
<t>Bob Briscoe is partly funded by Trilogy, a research project
(ICT-216372) supported by the European Community under its Seventh
Framework Programme. The views expressed here are those of the author
only.</t>
</section>
<!-- ================================================================ -->
<section anchor="ecnencap_Comments_Solicited" title="Comments Solicited">
<t>Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list
<tsvwg@ietf.org>, and/or to the authors.</t>
</section>
</middle>
<back>
<!-- ================================================================ -->
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include='reference.RFC.3168'?>
<?rfc include='reference.RFC.4774'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2637'?>
<?rfc include='reference.RFC.2661'?>
<?rfc include='reference.RFC.2784'?>
<?rfc include='reference.RFC.1701'?>
<?rfc include='reference.RFC.4301'?>
<?rfc include='reference.RFC.5129'?>
<?rfc include='reference.RFC.6040'?>
<?rfc include='localref.I-D.ietf-pcn-3-in-1-encoding'?>
<?rfc include='localref.I-D.ietf-trill-rbridge-options'?>
<?rfc include='localref.IEEE802.1Qah.MACinMAC'?>
<?rfc include='localref.IEEE802.1QauCongNotif'?>
<?rfc include='localref.ITU-T.I.371_ATMTrafficMgmt'?>
<?rfc include='localref.Alizadeh10.DCTCP'?>
<?rfc include='localref.Buckwalter00.FrameRelay'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 16:21:26 |