--- 1/draft-ietf-detnet-flow-information-model-01.txt 2018-10-22 15:13:09.877979348 -0700 +++ 2/draft-ietf-detnet-flow-information-model-02.txt 2018-10-22 15:13:09.925980508 -0700 @@ -1,24 +1,23 @@ DetNet J. Farkas Internet-Draft B. Varga Intended status: Standards Track Ericsson -Expires: September 6, 2018 R. Cummings +Expires: April 25, 2019 R. Cummings National Instruments Y. Jiang - Huawei Y. Zha - Tencent - March 05, 2018 + Huawei Technologies Co., Ltd. + October 22, 2018 DetNet Flow Information Model - draft-ietf-detnet-flow-information-model-01 + draft-ietf-detnet-flow-information-model-02 Abstract This document describes flow and service information model for Deterministic Networking (DetNet). The DetNet service is provided either for a Layer 3 or a Layer 2 flow. This document provides DetNet flow and service information model both for Layer 3 and Layer 2 flows in an integrated fashion. Status of This Memo @@ -29,21 +28,21 @@ 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 September 6, 2018. + This Internet-Draft will expire on April 25, 2019. Copyright Notice Copyright (c) 2018 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 @@ -79,42 +78,42 @@ 7.4. Service Rank . . . . . . . . . . . . . . . . . . . . . . 14 8. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Common Attributes of Source and Destination . . . . . . . . . 16 10.1. End System Interfaces . . . . . . . . . . . . . . . . . 16 10.2. Interface Capabilities . . . . . . . . . . . . . . . . . 16 10.3. User to Network Requirements . . . . . . . . . . . . . . 17 11. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 18 - 13.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 18 + 13.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 19 14. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 19 14.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 20 14.2. Interface Configuration . . . . . . . . . . . . . . . . 21 14.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 21 - 15. Service-status . . . . . . . . . . . . . . . . . . . . . . . 21 - 16. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 15. Service-status . . . . . . . . . . . . . . . . . . . . . . . 22 + 16. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 18. Security Considerations . . . . . . . . . . . . . . . . . . . 22 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 19.1. Normative References . . . . . . . . . . . . . . . . . . 22 19.2. Informative References . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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. The DetNet service is provided either for a Layer 3 (L3) flow or a Layer 2 (L2) flow by an IP/MPLS network, - see, e.g., [I-D.ietf-detnet-dp-alt]. Similarly, Time-Sensitive + see, e.g., [I-D.ietf-detnet-dp-sol-mpls]. Similarly, Time-Sensitive Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged network. DetNet and TSN have common architecture as expressed in [IETFDetNet] and [I-D.ietf-detnet-architecture]. DetNet service can be leveraged both by L3 and L2 flows, i.e., by DetNet L3 flows and DetNet L2 flows. Therefore, the DetNet flow and service information model provided by this document covers both DetNet L3 flows and DetNet L2 flows in an integrated fashion. In a given network scenario three information models can distinguished: @@ -252,63 +251,76 @@ e.g., low packet loss rate and/or latency. The simplest DetNet service is to provide bridging over the DN domain (i.e., tunneling for L2), where the connected hosts are in the same broadcast (BC) domain. Forwarding over the DetNet domain is based on L2 (MAC) addresses (i.e. dst-MAC). Somewhat more sophisticated is DetNet Routing service that provides routing, so available only for L3 hosts that are in different BC domains. Forwarding over the DetNet domain is based on L3 (IP) addresses (i.e. dst-IP). - Figure 5. and Figure 8. in [I-D.ietf-detnet-architecture] shows the + Figure 5. and Figure 8. in [I-D.ietf-detnet-architecture] show the DetNet service related reference points and main components. 5.2. Service parameters - Two forwarding methods are distinguished: (1) Bridging and (2) - Routing. The DN service is represented by a DN-PSeudoWire (DN-PW). + A DetNet network receives DetNet flows via a UNI as shown in Figure 5 + in [I-D.ietf-detnet-architecture]. The DetNet network connects the + UNIs via tunnels in order to provide DetNet service as shown in + Figure 8 in [I-D.ietf-detnet-architecture]. - Data-flows are received over the UNI. Usually there is a DN service - related legacy VPN service. The DN service and the legacy VPN - service use a common AC (attachment circuit). Legacy VPN is used by - regular traffic of the DetNet end-systems. DN flows are "directed" - by a selector to DN-PW(s). (See Figure 8. in - [I-D.ietf-detnet-architecture]) + The DetNet service attributes are the following: - Service attributes for DetNet connectivity are: + o Bandwidth + It is the bandwidth guaranteed for the DetNet service. - o Bandwidth parameter(s), + o Delay parameters + The are two delay parameters for a DetNet service: - o Delay parameter(s), + * Maximum latency, which is the maximum end-to-end one-way + latency for the DetNet service. - o Loss parameter(s), - o Connectivity type, + * Packet Delay Variation (PDV), which is the difference between + the minimum and the maximum end-to-end one-way latency. The + PDV parameter describes the maximum packet delay variation for + the DetNet service. (Note that PDV is sometimes referred to as + jitter.) - o In order delivery, + o Loss parameters - o Service rank. + * The maximum Packet Loss Ratio (PLR) parameter describes the + maximum packet loss ratio for the DetNet service between the + edges of the DetNet network. - 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.). + * Some applications have special loss requirement. 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 based on + sequence number. - 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.) + o Maximum allowed misordering + Maximum allowed misordering describes the tolerable maximum number + of packets that can be received out of order. The maximum allowed + misordering can be measured based on sequence number. The value + zero for the maximum allowed misordering indicates that in order + delivery is required, misordering cannot be tolerated. - Depending on the application and the end-system capabilities DetNet - service may be requested to provide in order delivery. + o Connectivity type + 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.) + o Service rank Service rank provides the rank of a service instance relative to - other services in the network. Rank is used by the network in case - of network resource limitation scenarios. + other services in the network. Rank is used by the network in + case of network resource limitation scenarios. 5.3. Reference Points From service model design perspective a fundamental question is the location of the service endpoints, i.e., where the service starts and ends. Note: Further discussion is needed based on data plane encapsulation results what reference points should be defined. Only some possible examples listed here: @@ -428,32 +440,32 @@ central 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 control-plane limitations. As the DetNet UNI can provide service for both L3 and L2 flows, end systems may not need to implement the L3 <=> L2 Transfer Function specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also subclause 46.1 in [IEEE8021Qcc]). An edge node may implement a function similar to the Transfer Function, see, e.g., the Svc Proxy - in Figure 1 in [I-D.ietf-detnet-dp-alt]. + in Figure 3 in [I-D.ietf-detnet-architecture]. 7. Flow The flows leveraging DetNet service can be unicast or multicast data flows for an application with constrained requirements on network performance, e.g., low packet loss rate and/or latency. Therefore, they can require different connectivity types: point-to-point (p2p) or point-to-multipoint (p2mp). The p2mp connectivity is created by a - transport layer function (e.g., p2mp LSP) [I-D.ietf-detnet-dp-alt]. - (Note that mp2mp connectivity is a superposition of p2mp - connections.) + transport layer function (e.g., p2mp LSP) + [I-D.ietf-detnet-dp-sol-mpls]. (Note that mp2mp connectivity is a + superposition of p2mp connections.) Many flows using DetNet service are periodic with fix packet size (i.e., Constant Bit Rate (CBR) flows), or periodic with variable packet size. Delay 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 (delay and loss). For example, some real-time applications allow graceful degradation if loss happens (e.g., sample-based processing, media distribution). @@ -599,33 +610,33 @@ Committed Rate indicates the rate at which traffic commits to be sent by the source (described in terms of the CIR (Committed Information Rate) and CBS (Committed Burst Size) attributes.) Excess Rate indicates the extent by which the traffic sent by the source exceeds the committed rate. The Excess Rate is described in terms of the EIR (Excess Information Rate) and EBS (Excess Burst Size) attributes. ]] [[NOTE3: a third alternative is to define application based traffic models such as [GPP22885] defines periodic and event-driven traffic model, and 5G PPP work defines traffic model for MTC (Machine Type - Communication) use cases. Periodic traffic type is usually for - status update between devices or devices transmit status report to a - central unit in regular basis. TrafficPeriod, defines the period of - the status update message. DataSize, defines the data size of the - massage which is constant. 3GPP also defines approximately-periodic - transmission with variations on period and uncertainty in the time - arrival of the packets. Event-triggered traffic type corresponds - traffic being triggered by an MTC device event. - MinIntervalBetweenEvent, defines the minimum interval between two - events. Event-triggered transmission will not happen all the time, - whenever an alert is sent, it waits until the issue being solved to - be able to send another alert. MaxPacketPerEvent, defines the max - number of packets within one message. ]] + Communication) use cases [I-D.ietf-detnet-use-cases]. Periodic + traffic type is usually for status update between devices or devices + transmit status report to a central unit in regular basis. + TrafficPeriod, defines the period of the status update message. + DataSize, defines the data size of the massage which is constant. + 3GPP also defines approximately-periodic transmission with variations + on period and uncertainty in the time arrival of the packets. Event- + triggered traffic type corresponds traffic being triggered by an MTC + device event. MinIntervalBetweenEvent, defines the minimum interval + between two events. Event-triggered transmission will not happen all + the time, whenever an alert is sent, it waits until the issue being + solved to be able to send another alert. MaxPacketPerEvent, defines + the max number of packets within one message. ]] 7.3. Flow Rank FlowRank provides the rank of this flow relative to other flows in the network. This rank is used to determine success/failure of flow establishment. Rank (boolean) is used by the network 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 a port of a node becomes oversubscribed (e.g., due to network reconfiguration). The true @@ -1007,53 +1017,47 @@ N/A. 19. References 19.1. Normative References [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", draft-ietf- - detnet-architecture-03 (work in progress), August 2017. - - [I-D.ietf-detnet-dp-alt] - Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., - Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol - and Solution Alternatives", draft-ietf-detnet-dp-alt-00 - (work in progress), October 2016. + detnet-architecture-08 (work in progress), September 2018. - [I-D.ietf-detnet-use-cases] - Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., - Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., - Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana, - X., Mahmoodi, T., Spirou, S., Vizarreta, P., Huang, D., - Geng, X., Dujovne, D., and M. Seewald, "Deterministic - Networking Use Cases", draft-ietf-detnet-use-cases-13 - (work in progress), September 2017. + [I-D.ietf-detnet-dp-sol-mpls] + Korhonen, J. and B. Varga, "DetNet MPLS Data Plane + Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in + progress), October 2018. [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, . 19.2. Informative References [GPP22885] 3GPP, "Study on LTE support for Vehicle-to-Everything (V2X) services", . + [I-D.ietf-detnet-use-cases] + Grossman, E., "Deterministic Networking Use Cases", draft- + ietf-detnet-use-cases-19 (work in progress), October 2018. + [IEEE8021AS] IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local and metropolitan area networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", 2011, . [IEEE8021CB] IEEE 802.1, "IEEE P802.1CB: IEEE Draft Standard for Local @@ -1083,42 +1087,49 @@ [IEEE8021TSN] IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) Task Group", . [IETFDetNet] IETF, "IETF Deterministic Networking (DetNet) Working Group", . Authors' Addresses + Janos Farkas Ericsson - Konyves Kalman krt. 11/B - Budapest 1097 + Magyar tudosok korutja 11 + Budapest 1117 Hungary Email: janos.farkas@ericsson.com Balazs Varga Ericsson - Konyves Kalman krt. 11/B - Budapest 1097 + 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 + Huawei Technologies Co., Ltd. + Bantian, Longgang district + Shenzhen 518129 + China Email: jiangyuanlong@huawei.com Yiyong Zha - Tencent + Huawei Technologies Co., Ltd. + China + + Email: zhayiyong@huawei.com