DetNet J. Farkas
Internet-Draft B. Varga
Intended status: Standards Track Ericsson
Expires: January 9, 2020 R. Cummings
National Instruments
Y. Jiang
Huawei Technologies Co., Ltd.
July 08, 2019

DetNet Flow Information Model
draft-ietf-detnet-flow-information-model-04

Abstract

This document describes flow and service information model for Deterministic Networking (DetNet). These models are defined for IP and MPLS DetNet data planes

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 https://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 January 9, 2020.

Copyright Notice

Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

A Deterministic Networking (DetNet) service provides a capability to carry a unicast or a multicast data flow for an application with constrained requirements on network performance, e.g., low packet loss rate and/or latency. DetNet and TSN have common architecture as expressed in [IETFDetNet] and [I-D.ietf-detnet-architecture]. The DetNet service is provided for DetNet flows via the DetNet service and forwarding sub-layers.

DetNet service is IP or MPLS and DetNet is currently defined for IP and MPLS networks as shown in Figure 1 based on Figure 2 and Figure 3 of [I-D.ietf-detnet-data-plane-framework]. A DetNet flow includes one or more App-flow(s) as payload. App-flows can be Ethernet, MPLS, or IP flows, which impacts what header fields are use in order to identify a flow. DetNet flows are created by DetNet encapsulation of App-flow(s) (e.g., with added MPLS labels, etc.). In some scenarios App-flow and DetNet flow look similar on the wire (e.g., L3 App-flow over a DetNet IP network).


                          +-----+
                          | TSN |
     +-------+          +-+-----+-+
     | DN IP |          | DN MPLS |
  +--+--+----+----+   +-+---+-----+-+
  | TSN | DN MPLS |   | TSN | DN IP |
  +-----+---------+   +-----+-------+

    

Figure 1: DetNet Service Examples as per Data Plane Framework

As shown in Figure 1 as per [I-D.ietf-detnet-data-plane-framework] a DetNet flow can be treated as an application level flow (App-flow) e.g., at DetNet flow aggregation or in a sub-network that interconnects DetNet nodes.

The DetNet flow and service information model provided by this document contains both DetNet flow and App-flow specific information in an integrated fashion.

In a given network scenario three information models can distinguished:

Service and flow information models are used between the user and the network operator. Configuration information models are used between the management/control plane entity of the network and the network nodes. They are shown in Figure 2.

   User                  Network Operator
           flow/service  
    /\      info model    +---+ 
   /  \ <---------------> | X |    management/control
   ----                   +-+-+       plane entity
                            ^   
                            |   configuration
                            |     info model
                     +------------+
                     v      |     |
                    +-+     |     v  Network
                    +-+     v    +-+  nodes
                           +-+   +-+
                           +-+

Figure 2: Usage of Information models (flow, service and configuration)

DetNet flow and service information model is based on [I-D.ietf-detnet-architecture] and on the concept of data model specified by [IEEE8021Qcc]. Furthermore, the starting point of the DetNet flow information model was the flow identification possibilities described in [IEEE8021CB], which is used by [IEEE8021Qcc] as well. In addition to TSN data model, [IEEE8021Qcc] also specifies configuration of TSN features (e.g., traffic scheduling specified by [IEEE8021Qbv]). Due to the common architecture and flow model, configuration features can be leveraged in certain deployment scenarios, e.g., when the network that provides the DetNet service includes both L3 and L2 network segments.

1.1. Goals

As it is expressed in the Charter [IETFDetNet], the DetNet WG collaborates with IEEE 802.1 TSN in order to define a common architecture for both Layer 2 and Layer 3, which is beneficial for various reasons, e.g., in order to simplify implementations. The flow and service information models should be also aligned along those lines. Therefore, the DetNet flow and service information models described in this document are based on [IEEE8021Qcc], which is an amendment to [IEEE8021Q].

This document intends to specify flow and service information models only.

1.2. Non Goals

This document (this revision) does not intend to specify either flow data model or DetNet configuration. From these aspects, the goals of this document differ from the goals of [IEEE8021Qcc], which also specifies data model and configuration of certain TSN features.

2. Terminology

2.1. Terms Used in This Document

This document uses the terminology established in the DetNet architecture [I-D.ietf-detnet-architecture] and the the DetNet Data Plane Framework [I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be familiar with these documents and any terminology defined therein. The DetNet <=> TSN dictionary of [I-D.ietf-detnet-architecture] is used to perform translation from [IEEE8021Qcc] to this document.

The following terminology is used according to [I-D.ietf-detnet-architecture]:

App-flow
The payload (data) carried over a DetNet service.
DetNet flow
A DetNet flow is a sequence of packets which conform uniquely to a flow identifier, and to which the DetNet service is to be provided. It includes any DetNet headers added to support the DetNet service and forwarding sub-layers.

The following terminology is introduced in this document:

Source
Reference point for an App-flow, where the flow starts.
Destination
Reference point for an App-flow, where the flow terminates.
DN Ingress
Reference point for DetNet flow, where it starts. Networking technology specific encapsulation may be added here to the served App-flow(s).
DN Egress
Reference point for DetNet flow, where it terminates. Networking technology specific encapsulation may be removed here from the served App-flow(s).

2.2. Abbreviations

The following abbreviations are used in this document:

DetNet
Deterministic Networking.
DN
DetNet.
MPLS
Multiprotocol Label Switching.
PSN
Packet Switched Network.
TSN
Time-Sensitive Networking.

2.3. Naming Conventions

The following naming conventions were used for naming information model components in this document. It is recommended that extensions of the model use the same conventions.

2.4. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. DetNet Domain and its Modeling

3.1. DetNet Service Overview

The DetNet service can be defined as a service that provides a capability to carry a unicast or a multicast data flow for an application with constrained requirements on network performance, e.g., low packet loss rate and/or latency.

Figure 5. and Figure 8. in [I-D.ietf-detnet-architecture] show the DetNet service related reference points and main components.

3.2. Reference Points Used in Modeling

From service design perspective a fundamental question is the location of the service/flow endpoints, i.e., where the service/flow starts and ends.

App-flow specific reference points are the Source (where it starts) and the Destination (where it terminates). Similarly a DetNet flow have reference points named as DN Ingress (where it starts) and DN Egress (where it ends). These reference points may coexist in the same node (e.g., in a DetNet IP end system). DN Ingress and DN Egress reference points are intermediate reference points for a served App-flow.

All reference points are assumed in this document to be packet-based reference points. A DN Ingress may add and a DN Egress may remove networking technology specific encapsulation to/from the served App-flow(s) (e.g., MPLS label(s), UDP and IP headers).

3.3. Information Elements

The DetNet flow information model and the service model relies on three groups of information elements:

In the information model a DetNet flow contains one or more App-flows (N:1 mapping). During DetNet aggregation the aggregated DetNet flows are treated as App-flows and the aggregate is the DetNet flow, which provides N:1 mapping. Similarly, there is a M:1 relationship of DetNet flow(s) and a DetNet Service.

4. App-flow Related Parameters

Deterministic service is required by time/loss sensitive application(s) running on an end system during communication with its peer(s). Such a data exchange has various requirements on delay and/or loss parameters.

4.1. App-flow Characteristics

App-flow characteristics are described with the following parameters:

4.2. App-flow Requirements

App-flow requirements are described with the following parameters:

5. DetNet Flow Related Parameters

Data model specified by [IEEE8021Qcc] describes data flows using TSN service as periodic flows with fix packet size (i.e., Constant Bit Rate (CBR) flows) or with variable packet size. The same concept is applyed for flows using DetNet service.

Latency and loss parameters are correlated because the effect of late delivery can result data loss for an application. However, not all applications require hard limits on both parameters (latency and loss). For example, some real-time applications allow graceful degradation if loss happens (e.g., sample-based processing, media distribution). Some others may require high-bandwidth connections that make the usage of techniques like packet replication economically challenging or even impossible. Some applications may not tolerate loss, but are not latency sensitive (e.g., bufferless sensors). Time/loss sensitive applications may have somewhat special requirements especially for loss (e.g., no loss in two consecutive communication cycles; very low outage time, etc.).

DetNet flows have the following attributes:

  1. DnFlowID (Section 5.1)
  2. DnPayloadType (Section 5.2)
  3. DnFlowFormat (Section 5.3)
  4. DnFlowSpecification (Section 5.4)
  5. DnTrafficSpecification (Section 5.5)
  6. DnFlowEndpoints (Section 5.6)
  7. DnFlowRank (Section 5.7)
  8. DnFlowStatus (Section 5.8)

DetNet flows have the following requirement attributes:

Flow attributes are described in the following sections.

5.1. Management ID of the DetNet Flow

A unique (management) identifier is needed for each DetNet flow within the DetNet domain. It is specified in DnFlowID. It can be used to define the M:1 mapping of DetNet flows to a DetNet service.

5.2. Payload type of the DetNet Flow

DnPayloadType attribute is set according to encapsulated App-flow format. The attribute can be Ethernet, MPLS, or IP.

5.3. Format of the DetNet Flow

DnFlowFormat attribute is set according to DetNet PSN technology. The attribute can be MPLS or IP.

5.4. Identification and Specification of DetNet Flows

Identification options for DetNet flows at the Ingress/Egress and within the DetNet domain are specified as follows; see Section 5.4.1 for DetNet MPLS flows and Section 5.4.2 for DetNetw IP flows.

5.4.1. DetNet MPLS Flow Identification and Specification

Identification of DetNet MPLS flows within the DetNet domain are used in the service information model. The attributes are specific to the MPLS forwarding paradigm within the DetNet domain [I-D.ietf-detnet-mpls]. DetNetwork MPLS flows can be identified and specified by the following attributes:

  1. SLabel
  2. FLabelStack

5.4.2. DetNet IP Flow Identification and Specification

DetNet IP flows can be identified and specified by the following attributes (6-tuple) [I-D.ietf-detnet-ip]:

  1. SourceIpAddress
  2. DestinationIpAddress
  3. IPv6FlowLabel
  4. Dscp
  5. Protocol
  6. SourcePort
  7. DestinationPort

5.5. Traffic Specification of the DetNet Flow

DnTrafficSpecification attributes specify how the DN Ingress transmits packets for the DetNet flow. This is effectively the promise/request of the DN Ingress to the network. The network uses this traffic specification to allocate resources and adjust queue parameters in network nodes.

TrafficSpecification has the following attributes:

  1. Interval: the period of time in which the traffic specification cannot be exceeded.
  2. MaxPacketsPerInterval: the maximum number of packets that the Ingress will transmit in one Interval.
  3. MaxPayloadSize: the maximum payload size that the Ingress will transmit.

These attributes can be used to describe any type of traffic (e.g., CBR, VBR, etc.) and can be used during resource allocation to represent worst case scenarios.

[[Editor's note (to be removed from a future revision): Further optional attributes can be considered to achieve more efficient resource allocation. Such optional attributes might be worth for flows with soft requirements (i.e., the flow is only loss sensitive or only delay sensitive, but not both d elay-and-loss sensitive). Possible options how to extend DnTrafficSpecification attributes is for further discussion. ]]

5.6. Endpoints of the DetNet Flow

DnFlowEndpoints attribute defines the starting and termination reference points of the DetNet flow by pointing to the ingress interface/node and egress interface(s)/node(s). Depending on the network scenario it defines an interface or a node. Interface can be defined for example if the App-flow is a TSN Stream and it is received over a well defined UNI interface. For exampe for App-flows with MPLS encapsulation defining an ingress node is more common when per platform label space is used.

5.7. Rank of the DetNet Flow

DnFlowRank provides the rank of this flow relative to other flows in the DetNet domain. Rank (range: 0-255) is used by the DetNet domain to decide which flows can and cannot exist when network resources reach their limit. Rank is used to help to determine which flows can be dropped (i.e., removed from node configuration) if for example a port of a node becomes oversubscribed (e.g., due to network re-configuration).

5.8. Status of the DetNet Flow

DnFlowStatus provides the status of the DetNet flow with respect to the establishment of the flow by the DetNet domain.

The DnFlowStatus SHALL include the following attributes:

  1. DnIngressStatus is an enumeration for the status of the flow´s Ingress reference point:

  2. DnEgressStatus is an enumeration for the status of the flow´s Egress reference points:

  3. FailureCode: A non-zero code that specifies the problem if the DetNet flow encounters a failure (e.g., packet replication and elimination is requested but not possible, or DnIngressStatus is Failed, or DnEgressStatus is Failed, or DnEgressStatus is PartialFailed).

[[Editor's note (to be removed from a future revision): FailureCodes to be defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN failure codes.]]

5.9. Requirements of the DetNet Flow

DnFlowRequirements specifies requirements to ensure proper serving of the DetNet flow.

The DnFlowRequirements includes the following attributes:

  1. MinBandwidth
  2. MaxLatency
  3. MaxLatencyVariation
  4. MaxLoss
  5. MaxConsecutiveLossTolerance
  6. MaxMisordering

5.9.1. Minimum Bandwidth of the DetNet Flow

MinBandwidth is the minimum bandwidth that has to be guaranteed for the DetNet flow.

5.9.2. Maximum Latency of the DetNet Flow

MaxLatency is the maximum latency from Ingress to Egress(es) for a single packet of the DetNet flow. MaxLatency is specified as an integer number of nanoseconds.

5.9.3. Maximum Latency Variation of the DetNet Flow

MaxLatencyVariation is the difference between the minimum and the maximum end-to-end one-way latency.

5.9.4. Maximum Loss of the DetNet Flow

MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for the DetNet flow between the Ingress and Egress(es).

5.9.5. Maximum Consequtive Loss of the DetNet Flow

Some applications have special loss requirement, like MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance parameter describes the maximum number of consecutive packets whose loss can be tolerated. The maximum consecutive loss tolerance can be measured for example based on sequence number.

5.9.6. Maximum Misordering Tolerance of the DetNet Flow

MaxMisordering describes the tolerable maximum number of packets that can be received out of order. The maximum allowed misordering can be measured for example based on sequence number. The value zero for the maximum allowed misordering indicates that in order delivery is required, misordering cannot be tolerated.

5.10. BiDir requirement of the DetNet Flow

DnFlowBiDir attribute defines the requirement whether the served packets have to be routed together with packets of other flows through the DetNet domain, e.g., to provide congruent paths in the two directions.

6. DetNet Service Related Parameters

DetNet service have the following attributes:

  1. DnServiceID (Section 6.1)
  2. DnServiceDeliveryType (Section 6.2)
  3. DnServiceDeliveryProfile (Section 6.3)
  4. DNServiceConnectivity (Section 6.4)
  5. DnServiceBiDir (Section 6.5)
  6. DnServiceRank (Section 6.6)
  7. DnServiceStatus (Section 6.7)

Service attributes are described in the following sections.

6.1. Management ID of the DetNet service

A unique (management) identifier is needed for each DetNet service within the DetNet domain. It is specified in DnServiceID. It can be used to define the M:1 mapping of DetNet flows to a DetNet service.

6.2. Delivery Type of the DetNet service

DnServiceDeliveryType attribute is set according to the payload of the served DetNet flow (i.e., the encapsulated App-flow format). The attribute can be Ethernet, MPLS, or IP.

6.3. Delivery Profile of the DetNet Service

DnServiceDeliveryProfile specifies delivery profile to ensure proper serving of the DetNet flow.

The DnServiceDeliveryProfile includes the following attributes:

  1. MinBandwidth
  2. MaxLatency
  3. MaxLatencyVariation
  4. MaxLoss
  5. MaxConsecutiveLossTolerance
  6. MaxMisordering

6.3.1. Minimum Bandwidth of the DetNet Service

MinBandwidth is the minimum bandwidth that has to be guaranteed for the DetNet service.

6.3.2. Maximum Latency of the DetNet Service

MaxLatency is the maximum latency from Ingress to Egress(es) for a single packet of the DetNet flow. MaxLatency is specified as an integer number of nanoseconds.

6.3.3. Maximum Latency Variation of the DetNet Service

MaxLatencyVariation is the difference between the minimum and the maximum end-to-end one-way latency.

6.3.4. Maximum Loss of the DetNet Service

MaxLoss defines the maximum Packet Loss Ratio (PLR) parameter for the DetNet service between the Ingress and Egress(es) of the DetNet domain.

6.3.5. Maximum Consequtive Loss of the DetNet Service

Some applications have special loss requirement, like MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance parameter describes the maximum number of consecutive packets whose loss can be tolerated. The maximum consecutive loss tolerance can be measured for example based on sequence number.

6.3.6. Maximum Misordering Tolerance of the DetNet Service

MaxMisordering describes the tolerable maximum number of packets that can be received out of order. The maximum allowed misordering can be measured for example based on sequence number. The value zero for the maximum allowed misordering indicates that in order delivery is required, misordering cannot be tolerated.

6.4. Connectivity Type of the DetNet Service

Two connectivity types are distinguished: point-to-point (p2p) and point-to-multipoint (p2mp). Connectivity type p2mp is created by a transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity is a superposition of p2mp connections.)

6.5. BiDir requirement of the DetNet Service

DnServiceBiDir attribute defines the requirement whether the served packets have to be routed together with packets of other service instances through the DetNet domain, e.g., to provide congruent paths in the two directions.

6.6. Rank of the DetNet Service

DnServiceRank attribute provides the rank of a service instance relative to other services in the DetNet domain. DnServiceRank (range: 0-255) is used by the network in case of network resource limitation scenarios.

6.7. Status of the DetNet Service

DnServiceStatus information group includes elements that specify the status of the service specific state of the DetNet domain. This information group informs the user whether or not the service is ready for use.

The DnServiceStatus SHALL include the following attributes:

  1. DnServiceIngressStatus is an enumeration for the status of the service´s Ingress:

  2. DnServiceEgressStatus is an enumeration for the status of the service´s Egress:

  3. DnServiceFailureCode: A non-zero code that specifies the problem if the DetNet service encounters a failure (e.g., packet replication and elimination is requested but not possible, or DnServiceIngressStatus is Failed, or DnServiceEgressStatus is Failed, or DnServiceEgressStatus is PartialFailed).

[[Editor's note (to be removed from a future revision): DnServiceFailureCodes to be defined for DetNet service. Table 46-1 of [IEEE8021Qcc] describes TSN failure codes.]]

7. Flow Specific Operations

The DetNet flow information model relies on three high level information groups:

There are three possible operations for each DetNet flow with respect to its DetNet service at a DN Ingress or a DN Egress (similarly to App-flows at a Source or a Destination):

7.1. Join Operation

For the join operation, the DnFlowSpecification, DnFlowRank, DnFlowEndpoint, and DnTrafficSpecification SHALL be included within the DnIngress or DnEgress information group. For the join operation, the DnServiceRequirements groups MAY be included.

7.2. Leave Operation

For the leave operation, the DnFlowSpecification and DnFlowEndpoint SHALL be included within the DnIngress or DnEgress information group.

7.3. Modify Operation

For the modify operation, the DnFlowSpecification, DnFlowRank, DnFlowEndpoint, and DnTrafficSpecification SHALL be included within the DnIngress or DnEgress information group. For the join operation, the DnServiceRequirements groups MAY be included.

Modify operation can be considered to address cases when a flow is slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been changed. The advantage of having a Modify is that it allows to initiate a change of flow spec while leaving the current flow is operating until the change is accepted. If there is no linkage between the Join and the Leave, then in figuring out whether the new flow spec can be supported, the controller entity has to assume that the resources committed to the current flow are in use. Via Modify the controller entity knows that the resources supporting the current flow can be available for supporting the altered flow. Modify is considered to be an optional operation due to possible controller plane limitations.

8. Summary

This document describes DetNet flow information model and service information model for DetNet IP networks and DetNet MPLS networks.

9. IANA Considerations

N/A.

10. Security Considerations

N/A.

11. References

11.1. Normative References

[I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B. and J. Farkas, "Deterministic Networking Architecture", Internet-Draft draft-ietf-detnet-architecture-13, May 2019.
[I-D.ietf-detnet-ip] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S. and J. Korhonen, "DetNet Data Plane: IP", Internet-Draft draft-ietf-detnet-ip-01, July 2019.
[I-D.ietf-detnet-mpls] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S. and J. Korhonen, "DetNet Data Plane: MPLS", Internet-Draft draft-ietf-detnet-mpls-01, July 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", RFC 6003, DOI 10.17487/RFC6003, October 2010.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

11.2. Informative References

[I-D.ietf-detnet-data-plane-framework] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S. and J. Korhonen, "DetNet Data Plane Framework", Internet-Draft draft-ietf-detnet-data-plane-framework-01, July 2019.
[IEEE8021CB] IEEE Standards Association, "IEEE Std 802.1CB-2017 IEEE Standard for Local and metropolitan area networks - Frame Replication and Elimination for Reliability", 2017.
[IEEE8021Q] IEEE Standards Association, "IEEE Std 802.1Q-2018 IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks", 2018.
[IEEE8021Qbv] IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks - Amendment 25: Enhancements for Scheduled Traffic", 2015.
[IEEE8021Qcc] IEEE Standards Association, "IEEE Std 802.1Qcc-2018: IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks -- Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements", 2018.
[IEEE8021TSN] IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) Task Group"
[IETFDetNet] IETF, "IETF Deterministic Networking (DetNet) Working Group"

Authors' Addresses

János Farkas Ericsson Magyar tudosok korutja 11 Budapest, 1117 Hungary EMail: janos.farkas@ericsson.com
Balázs Varga Ericsson Magyar tudosok korutja 11 Budapest, 1117 Hungary EMail: balazs.a.varga@ericsson.com
Rodney Cummings National Instruments 11500 N. Mopac Expwy Bldg. C Austin, TX, 78759-3504 USA EMail: rodney.cummings@ni.com
Yuanlong Jiang Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen, 518129 China EMail: jiangyuanlong@huawei.com