One document matched: draft-shen-nsis-rsvp-mobileipv6-00.txt
Internet Engineering Task Force Charles Qi Shen
draft-shen-nsis-rsvp-mobileipv6-00.txt Winston Seah
July 12, 2002 Anthony Lo
Expires: January 2003 ICR
Haihong Zheng
Marc Greis
Nokia
Mobility Extensions to RSVP in an RSVP-Mobile IPv6 Framework
<draft-shen-nsis-rsvp-mobileipv6-00.txt>
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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".
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
1 Abstract
This memo first gives a brief review of a RSVP and Mobile IPv6
interoperation framework proposed in [1] and compared its features
with the Performance Requirements set forth by Requirements of a QoS
Solution for Mobile IP [2]. The subsequent part of the memo presents
specification details including message formats, processing rules and
algorithms that form the framework. The vast majority of these
specifications has been verified by a prototype implementation. It is
expected that this work could serve as a useful input in dealing with
NSIS protocol and mobility issue.
2 Terminology
MS - Mobile Sender A Mobile Node that is acting as a Flow
Sender.
MR - Mobile Receiver A Mobile Node that is acting as a Flow
Receiver.
Shen, Seah, Lo, Zheng and Greis [Page 1]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002
SNCR - Sender Nearest Common Router the first common router on
the old path and new path after a handoff caused by MN
functioning as a MS.
RNCR - Receiver Nearest Common Router the first common router on
the old path and new path after a handoff caused by MN
functioning as a MR.
NCR - Nearest Common Router could be either a SNCR or a RNCR.
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.
3 Introduction
The increasing interest in supporting QoS sensitive applications in a
mobile environment has led to extensive work on interoperation of QoS
signaling and mobility mechanisms. Typically the issue is addressed
in the context of RSVP and Mobile IP . This memo is a follow-up of
our previous proposal on an Interoperation Framework for using RSVP
in an Mobile IPv6 network[1].
In this memo, we first give a brief review of the framework and
evaluate it against the Requirement of a QoS Solution for Mobile IP
[2] that was formed after our framework proposal. Then we present the
specification details concerning New Message/Object Formats,
processing rules as well as (Nearest Common Router) NCR Decision
Algorithms which have been developed extensively since the previous
framework memo.
It is known that the IETF Next Step In Signaling (NSIS) WG has been
charted to look at a future resource signaling protocol and the NSIS
framework is well likely to cover the interaction with general
mobility mechanism as well. In view of the fact that, RSVP is
recommended to be used as a starting point for NSIS, and Mobile IP is
likely the pre-dominant mobility mechanism for IP macro-mobility, we
expect this work to be a useful input to the area of NSIS and
mobility interaction. In addition, we provide a separate discussion
on several issues related to general NSIS and mobility interaction in
[3]. The similar topic is also covered as part of a framework
proposal by Handcock et. al. [4].
It is worth noting that, the vast majority of signaling logic and
processing rules disclosed herein have been verified by a prototype
implementation modified from the latest ISI RSVP release.
4 Framework and Requirements Review
Shen, Seah, Lo, Zheng and Greis [Page 2]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002
The essential point of our framework[1] is to maintain a unique flow
identifier regardless of node mobility. To achieve this specifically
within the Mobile IP and RSVP context, we have chosen to use MN HAs
in RSVP SESSION object and RSVP SENDER_TEMPLATE object. While the
correct routing of signaling packets is ensured by using MN CoAs.
A brief review of our RSVP-Mobile IPv6 framework is given below. We
assume a generic scenario where both communication parties could be
mobile. So we will use the terms Mobile Sender (MS) and Mobile
Receiver (MR) instead of MN to reflect the situation more accurately,
wherever necessary. The illustration of framework operation in each
of the MR and MS case is divided into three signaling phases
according to different functionalities, although they indeed overlap
in terms of actual signaling timing.
4.1 Framework Review: Mobile Sender (MS) Case
4.1.1 Resource Establishment in the New Path
When the MS obtains a new care-of address upon handoff, it
immediately sends a PATH message containing its mobility information
(which is its new CoA) towards the CN. This PATH message triggers the
establishment of PATH state in the RSVP routers on the path until it
reaches the Sender Nearest Common Router (SNCR). The SNCR finds the
PATH message arriving with a previous hop address different from the
one stored in the path state, upon which it immediately replies with
a RESV message towards the MN using the new path. The reserved
resources between the SNCR and the CN can be reused.
4.1.2 Resource Release in the Obsoleted Path
In addition to the above, the SNCR sends a RESVTEAR message towards
the previous hop stored in the old path state. The RESVTEAR message
triggers the removal of the reserved resources on the old path which
are no longer needed.
4.1.3 Refresh Handling in the Common Path
The SNCR also forwards the received handoff PATH message to the next
hop in any case so as to update the mobility information in all RSVP
routers on the rest of the path. This is to ensure correct routing of
subsequent refresh messages.
4.2 Framework Review: Mobile Receiver (MR) Case
4.2.1 Resource Establishment in the New Path
When the MR obtained a new care-of address upon handoff, it is
Shen, Seah, Lo, Zheng and Greis [Page 3]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002
required to inform the Receiver Nearest Common Router (RNCR) of its
mobility information in order to trigger a quick handoff PATH message
from the RNCR. This avoids waiting for a handoff PATH message from
the CN, which requires at least a round trip time between MR and CN.
This is achieved by the use of a new RSVP PATHREQ message. It may
optionally be piggybacked in a PATH message sent by the MN when it
acts as both MS and MR. In the following discussion, we assume the
former method, or a separate PATHREQ message is used. The PATHREQ
message which carries MR's mobility information (the new CoA) will be
sent toward the CN and will be examined by each intermediate RSVP
node until it reaches RNCR. The RNCR then triggers a Local Repair for
the receiver route change that is, the router sends a handoff PATH
message associated with the unique flow identifier, to the MN's new
care-of address. This serves to establish resource state in the new
path as soon as possible.
4.2.2 Resource Release in the Obsoleted Path
In addition to the above, RNCR also sends a PATHTEAR message towards
the MN's old care-of address. The PATHTEAR message triggers the
removal of the resources on the old path which are no longer needed.
4.2.3 Refresh Handling in the Common Path
RNCR also forwards the PATHREQ message to the next hop until it
reaches the CN so as to update the mobility information in all the
RSVP routers on the common path. This is to insure correct routing of
subsequent refresh messages.
4.3 Requirements Review: Evaluate the Framework Against Requirements
A quick examination of the Requirement of a QoS Solution for Mobile
IP [2] shows that the above framework addressed all three performance
requirements set forth, namely
o Minimize the interruption in QoS at the time of handover.
o Localize the QoS (re)establishment to the affected parts of
the packet path in the network.
o Releasing after handover the QoS state (if any) along the old
packet path.
The first and second requirements are addressed by the use of NCR in
establishing resource state within new path incurred by handoff. The
third requirement is met by explicitly issuing of corresponding state
teardown messages at the NCRs. In the following sections we present
specification details concerning New Message/Object Formats, NCR
Shen, Seah, Lo, Zheng and Greis [Page 4]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002
Algorithms and Processing rules that form the above RSVP-Mobile IPv6
framework.
5 Formats of New RSVP Objects and Messages
5.1 Formats of SENDER_MOBILITY Object and RECEIVER_MOBILITY Object
New MOBILITY objects are defined in order to convey MN's mobility
information to RSVP. In the simplest case for Mobile IP, it contains
the MN's current care-of address. By including these new objects, the
RSVP process does not need to get the mobility information of the MN
from the IP header of the RSVP messages, the clear interface between
the IP layer and the RSVP process is maintained.
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Care-of Address +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Flags | (Reserved) | Sequence Number |
+-------------+-------------+-------------+-------------+
Flags: 8 bits
0x01: NCR Identified
When set, indicates that the NCR has been identified.
Figure 1: MOBILITY Object
In accordance with the simplex nature of RSVP, two types of MOBILITY
objects are defined, namely, SENDER_MOBILITY objects and
RECEIVER_MOBILITY objects. Figure 1 shows the format for the MOBILITY
object. The length field indicates the total object length in bytes.
Shen, Seah, Lo, Zheng and Greis [Page 5]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002
The Class Num and the C-Type for the MOBILITY object would have to be
assigned by IANA. SENDER_MOBILITY objects and RECEIVER_MOBILITY
objects shall have different Class Nums. The contents of the MOBILITY
object contain:
o Mobility information which is MS or MR's current care-of
address.
o An NCR Flag bit which indicates whether the appropriate NCR
has been located. The bit carries an initial value of 0 and is
set to 1 by the NCR.
o A two-byte Sequence Number field which increases by one after
each handoff and thus indicates how up-to-date the mobility
information is.
5.2 Format of PATHREQ Message
The new PATHREQ message is defined to allow the MR to request a PATH
message from RNCR immediately after it performs a handoff. Figure 2
shows the format of a PATHREQ message, it contains:
o An RSVP common header, in which the message type for PATHREQ
message has to be assigned by IANA.
o A SESSION object containing the MR's home address.
o A SENDER_TEMPLATE object containing the MS's home address.
o A RECEIVER_MOBILITY object containing the MR's current care-of
address.
o A SENDER_MOBILITY object containing the MS's current care-of
address.
Inclusion of the above four objects makes RSVP aware of the care-of
address and home address of both MS and MR thus covers the most
complicated case where both communication parties are MNs and acts as
Sender and Receiver simultaneously. In case either party is
stationary, the corresponding MOBILITY object will not be applicable
and the home address above is replaced by the corresponding fixed
address.
6 Nearest Common Router (NCR) Decision Algorithm
The decision for NCRs is divided into two parts: SNCR and RNCR.
Generally, decision for SNCR is triggered by receiving of PATH
Shen, Seah, Lo, Zheng and Greis [Page 6]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002
+-------------+-------------+-------------+-------------+
| RSVP Common Header |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ SESSION object +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ SENDER_TEMPLATE object +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ RECEIVER_MOBILITY object +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ SENDER_MOBILITY object +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
Figure 2: PATHREQ Message
messages; decision for RNCR is triggered by receiving of PATHREQ
messages; RNCR and SNCR may be physically collocated in the same
router, or could be in two different network entities.
Shen, Seah, Lo, Zheng and Greis [Page 7]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002
6.1 Decision Algorithm for Sender NCR (SNCR)
RSVP decides that it is the SNCR if all of the following conditions
are met.
o A PATH message which contains a SENDER_MOBILITY object is
received.
o The NCR Flag bit in the received SENDER_MOBILITY object is
Zero.
o There is a matching PSB found for the PATH message.
o The matching PSB does not include a SENDER_MOBILITY object or
the matching PSB contains a SENDER_MOBILITY object which has a
sequence number lower than that of the received
SENDER_MOBILITY object.
6.2 Decision Algorithm for Receiver NCR (RNCR)
RSVP decides that it is the RNCR if all of the following conditions
are met.
o A PATHREQ message which contains a RECEIVER_MOBILITY object is
received.
o The NCR Flag bit in the received RECEIVER_MOBILITY object is
Zero.
o There is a matching PSB found for the SESSION object in the
received PATHREQ message.
o The matching PSB does not include a RECEIVER_MOBILITY object
or the matching PSB contains a RECEIVER_MOBILITY object which
has a sequence number lower than that of the received
RECEIVER_MOBILITY object.
7 Processing Rules for PATHREQ Message and PATH Message with MOBILITY
Object
7.1 Processing Rule for New PATHREQ Message
The PATHREQ message is sent by a MR when it changes its care-of
address. The general processing rules when RSVP receives a PATHREQ
message are as follows:
o RSVP searches for PSBs in the opposite direction whose SESSION
object matches the corresponding object in the PATHREQ
Shen, Seah, Lo, Zheng and Greis [Page 8]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002
message.
o If there are no matching PSBs, the PATHREQ message is simply
forwarded to the next RSVP node. The source address and
destination address of the forwarded PATHREQ message are
determined as follows:
- The source address is retrieved from RECEIVER_MOBILITY
object which contains the receiver's care-of address.
- The destination address is retrieved from SENDER_MOBILITY
object which contains the sender's care-of address, if it
exists. Otherwise, the destination address is retrieved from
SENDER_TEMPLATE object which contains the sender's fixed or
home address.
o Otherwise there are matching PSBs found. For each matching
PSB,
- If RECEIVER_MOBILITY information is found in the PSB and the
sequence number of that RECEIVER_MOBILITY is higher than
that of the received RECEIVER_MOBILITY object, discard the
received PATHREQ message.
- Otherwise, if RECEIVER_MOBILITY is not found in the PSB or
RECEIVER_MOBILITY is found in the PSB but with a lower
sequence number:
- The PSB is updated with the new RECEIVER_MOBILITY object.
- If SENDER_MOBILITY exists either or both in PSB or
PATHREQ, compare their sequence number, update PSB with
the newer SENDER_MOBILITY object if applicable.
- Check the NCR Flag bit in the received RECEIVER_MOBILITY
object:
- If the NCR Flag bit is 1, and the RSVP node is not the
sender, forward the PATHREQ message to the next RSVP
node using the same source and destination address
decision rules as stated above when there is no matching
PSB.
- If the Flag bit is 0, the RSVP node is identified as
RNCR. It does the following:
Sets the NCR Flag bit into 1; Constructs a handoff PATH
message that includes the RECEIVER_MOBILITY object, and
Shen, Seah, Lo, Zheng and Greis [Page 9]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002
sends it to the receiver's current care-of address
obtained from the same RECEIVER_MOBILITY object;
Constructs a PATHTEAR message containing the old
RECEIVER_MOBILITY object, if exists, to the receiver's
old care-of address; If the RSVP node is not sender of
the flow, it further forwards the PATHREQ message to the
next RSVP node using the same source and destination
address construction rule as stated above when there is
no matching PSB.
7.2 New Processing Rules for PATH Message
To deal with node mobility, PATH messages shall carry MOBILITY
objects. If the MS performs a handoff, a SENDER_MOBILITY object will
be included in the PATH messages. If the MR performs a handoff and
reports it to the sender through PATHREQ message, the subsequent PATH
message will carry the RECEIVER_MOBILITY object.
The following states new/modified processing rules for PATH messages
in addition to existing rules specified in RFC 2209 due to the
introduction of new MOBILITY objects.
o When RSVP creates a new PSB for a new PATH message with
MOBILITY objects, the following rules apply in addition to/in
place of existing rules where applicable:
- If SENDER_MOBILITY object is included in the PATH message,
it is also copied to the newly created PSB.
- If RECEIVER_MOBILITY object is included in the PATH message,
it is also copied to the newly created PSB.
- When the PATH message is forwarded to the next RSVP node.
The source address and destination address of the forwarded
PATH message are determined as follows:
- The source address is retrieved from SENDER_MOBILITY
object which contains the sender's care-of address, if it
exists. Otherwise, the source address is retrieved from
SENDER_TEMPLATE object which contains the sender's fixed
or home address.
- The destination address is retrieved from
RECEIVER_MOBILITY object which contains the receiver's
care-of address, if it exists. Otherwise, the destination
address is retrieved from SESSION object which contains
the receiver's fixed or home address.
Shen, Seah, Lo, Zheng and Greis [Page 10]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002
o Otherwise, if matching PSB is found, the following rules apply
in addition to/ in place of existing rules where applicable:
- First, if a RECEIVER_MOBILITY object is included in the PATH
message, the RSVP node determines whether it carries the
most updated information based on the sequence number of the
object. If the existing PSB contains no RECEIVER_MOBILITY
information or the received RECEIVER_MOBILITY information is
newer than the existing one, the PSB updates its
RECEIVER_MOBILITY information.
- Second, if a SENDER_MOBILITY object is included in the PATH
message, the RSVP node determines whether it carries the
most updated information based on the sequence number of the
object. If the received SENDER_MOBILITY is older than the
existing one in PSB, stops processing the PATH message and
discards it. Otherwise, if the existing PSB contains no
SENDER_MOBILITY information or the received SENDER_MOBILITY
information is newer than the existing one,
- The PSB updates its SENDER_MOBILITY information.
- The NCR Flag bit in the received SENDER_MOBILITY object is
checked. If it is not set, the RSVP node is identified as
SNCR. It does the following:
Sets the NCR Flag bit to 1; Sends a RESV message to the
previous hop which leads to the MS's current care-of
address; Sends a RESVTEAR message to the previous hop
which leads to the MS's old care-of address; If the RSVP
node is not receiver of the flow, it further forwards the
PATH message to the next RSVP node using the same source
and destination address decision rules as stated above
when there is no matching PSB.
- Otherwise the RSVP node is not SNCR. If the RSVP node is
not receiver of the flow, it forwards the PATH message to
the next RSVP node using the same source and destination
address decision rules as stated above when there is no
matching PSB.
8 Future Work
In traditional operation of RSVP, a flow identifier is virtually also
used as a reservation identifier. This seems to be fine in fixed
networks. In mobile environments however, it might sometimes be
desirable to separate these two, while the flow identifier could be
changing from time to time, the reservation identifier remains
Shen, Seah, Lo, Zheng and Greis [Page 11]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002
constant all the time [3,4]. It should be noted that our proposed
framework does not in any sense exclude this possibility. More
specifically, in cases where the reservation identifier is defined
differently than the flow identifier, our use of HAs as reservation
identifier does not exclude the use of addresses other than HAs, such
as the CoAs as flow identifier. In this case, it is expected that the
signaling logic explained in this memo will still largely be
applicable, although certain modifications are likely to be needed.
The applicability of this approach in our framework is currently
under study.
9 Acknowledgments
We would like to thank Mr. Donglin Shi for helpful discussion during
the prototype implementation of this work.
10 Bibliography
[1] C. Q. Shen, W. Seah, A. Lo, H. Zheng, and M. Greis, "An
Interoperation Framework for Using RSVP in Mobile IPv6 Networks,"
draft-shen-rsvp-mobileipv6-interop-00.txt , July 2001. Work in
Progress.
[2] H. Chaskar (Editor), "Requirements of a QoS Solution for Mobile
IP," draft-ietf-mobileip-qos-requirements-02.txt , June 2001. Work
in Progress.
[3] C. Q. Shen, "Several Framework Issues Regarding NSIS and
Mobility," draft-shen-nsis-mobility-fw-00.txt , July 2002. Work in
Progress.
[4] R. Hancock et.al., "Next Steps in Signaling: A Framework
Proposal," draft-hancock-nsis-fw-00.txt , June 2002. Work in
Progress.
11 Authors' addresses
Charles Qi Shen
Institute for Communications Research (ICR)
20 Science Park Road
#02-34/37, TeleTech Park
Singapore Science Park II
Singapore 117674
Phone: +65 6870-9358
Email: shenqi@icr.a-star.edu.sg
Winston Seah
Institute for Communications Research (ICR)
Shen, Seah, Lo, Zheng and Greis [Page 12]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002
20 Science Park Road
#02-34/37, TeleTech Park
Singapore Science Park II
Singapore 117674
Phone: +65 6870-9163
Email: winston@icr.a-star.edu.sg
Anthony Lo
Institute for Communications Research (ICR)
20 Science Park Road
#02-34/37, TeleTech Park
Singapore Science Park II
Singapore 117674
Haihong Zheng
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894 4232
Email: haihong.zheng@nokia.com
Marc Greis
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 374 0629
Email: marc.greis@nokia.com
12 Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
Shen, Seah, Lo, Zheng and Greis [Page 13]
Internet Draft RSVP Mobile IPv6 Interop July 17, 2002
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents
1 Abstract ............................................ 1
2 Terminology ......................................... 1
3 Introduction ........................................ 2
4 Framework and Requirements Review ................... 2
4.1 Framework Review: Mobile Sender (MS) Case ........... 3
4.1.1 Resource Establishment in the New Path .............. 3
4.1.2 Resource Release in the Obsoleted Path .............. 3
4.1.3 Refresh Handling in the Common Path ................. 3
4.2 Framework Review: Mobile Receiver (MR) Case ......... 3
4.2.1 Resource Establishment in the New Path .............. 3
4.2.2 Resource Release in the Obsoleted Path .............. 4
4.2.3 Refresh Handling in the Common Path ................. 4
4.3 Requirements Review: Evaluate the Framework
Against Requirements ........................................... 4
5 Formats of New RSVP Objects and Messages ............ 5
5.1 Formats of SENDER_MOBILITY Object and
RECEIVER_MOBILITY Object ....................................... 5
5.2 Format of PATHREQ Message ........................... 6
6 Nearest Common Router (NCR) Decision Algorithm ...... 6
6.1 Decision Algorithm for Sender NCR (SNCR) ............ 8
6.2 Decision Algorithm for Receiver NCR (RNCR) .......... 8
7 Processing Rules for PATHREQ Message and PATH
Message with MOBILITY Object ................................... 8
7.1 Processing Rule for New PATHREQ Message ............. 8
7.2 New Processing Rules for PATH Message ............... 10
8 Future Work ......................................... 11
9 Acknowledgments ..................................... 12
10 Bibliography ........................................ 12
11 Authors' addresses .................................. 12
12 Full Copyright Statement ............................ 13
Shen, Seah, Lo, Zheng and Greis [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 08:15:43 |