draft-ietf-detnet-flow-information-model-00.txt   draft-ietf-detnet-flow-information-model-01.txt 
DetNet J. Farkas DetNet J. Farkas
Internet-Draft B. Varga Internet-Draft B. Varga
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: July 12, 2018 R. Cummings Expires: September 6, 2018 R. Cummings
National Instruments National Instruments
J. Yuanlong Y. Jiang
Z. Yiyong
Huawei Huawei
January 08, 2018 Y. Zha
Tencent
March 05, 2018
DetNet Flow Information Model DetNet Flow Information Model
draft-ietf-detnet-flow-information-model-00 draft-ietf-detnet-flow-information-model-01
Abstract Abstract
This document describes flow and service information model for This document describes flow and service information model for
Deterministic Networking (DetNet). The DetNet service is provided Deterministic Networking (DetNet). The DetNet service is provided
either for a Layer 3 or a Layer 2 flow. This document provides 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 DetNet flow and service information model both for Layer 3 and Layer
2 flows in an integrated fashion. 2 flows in an integrated fashion.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 12, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 19
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Non Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions Used in This Document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
4. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 5 4. Naming Conventions . . . . . . . . . . . . . . . . . . . . . 5
5. End System and DetNet domain . . . . . . . . . . . . . . . . 6 5. Service model . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Service overview . . . . . . . . . . . . . . . . . . . . 6
6.1. Identification and Specification of Flows . . . . . . . . 8 5.2. Service parameters . . . . . . . . . . . . . . . . . . . 6
6.1.1. DetNet L3 Flow Identification and Specification at 5.3. Reference Points . . . . . . . . . . . . . . . . . . . . 7
UNI . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Service scenarios . . . . . . . . . . . . . . . . . . . . 8
6.1.2. DetNet L2 Flow Identification and Specification at 6. End System and DetNet domain . . . . . . . . . . . . . . . . 8
UNI . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1.3. DetNetwork Flow Identification and Specification . . 10 7.1. Identification and Specification of Flows . . . . . . . . 11
6.2. Traffic Specification . . . . . . . . . . . . . . . . . . 10 7.1.1. DetNet L3 Flow Identification and Specification at
6.3. Flow Rank . . . . . . . . . . . . . . . . . . . . . . . . 11 UNI . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Service Rank . . . . . . . . . . . . . . . . . . . . . . 12 7.1.2. DetNet L2 Flow Identification and Specification at
7. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 UNI . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1.3. DetNetwork Flow Identification and Specification . . 12
9. Common Attributes of Source and Destination . . . . . . . . . 13 7.2. Traffic Specification . . . . . . . . . . . . . . . . . . 12
9.1. End System Interfaces . . . . . . . . . . . . . . . . . . 13 7.3. Flow Rank . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Interface Capabilities . . . . . . . . . . . . . . . . . 13 7.4. Service Rank . . . . . . . . . . . . . . . . . . . . . . 14
9.3. User to Network Requirements . . . . . . . . . . . . . . 14 8. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Common Attributes of Source and Destination . . . . . . . . . 16
12. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. End System Interfaces . . . . . . . . . . . . . . . . . 16
12.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 16 10.2. Interface Capabilities . . . . . . . . . . . . . . . . . 16
13. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.3. User to Network Requirements . . . . . . . . . . . . . . 17
13.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 17 11. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.2. Interface Configuration . . . . . . . . . . . . . . . . 18 12. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 19 13. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 18
14. Service-status . . . . . . . . . . . . . . . . . . . . . . . 19 13.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 18
15. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 19
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 14.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 20
17. Security Considerations . . . . . . . . . . . . . . . . . . . 19 14.2. Interface Configuration . . . . . . . . . . . . . . . . 21
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 14.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 21
18.1. Normative References . . . . . . . . . . . . . . . . . . 19 15. Service-status . . . . . . . . . . . . . . . . . . . . . . . 21
18.2. Informative References . . . . . . . . . . . . . . . . . 20 16. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
18. Security Considerations . . . . . . . . . . . . . . . . . . . 22
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
19.1. Normative References . . . . . . . . . . . . . . . . . . 22
19.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
A Deterministic Networking (DetNet) service provides a capability to A Deterministic Networking (DetNet) service provides a capability to
carry a unicast or a multicast data flow for an application with carry a unicast or a multicast data flow for an application with
constrained requirements on network performance, e.g., low packet constrained requirements on network performance, e.g., low packet
loss rate and/or latency. The DetNet service is provided either for 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, 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-alt]. Similarly, Time-Sensitive
Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged Networking (TSN) [IEEE8021TSN]) can be used for L2 flows in a bridged
skipping to change at page 6, line 13 skipping to change at page 6, line 13
o Names SHOULD be descriptive. o Names SHOULD be descriptive.
o Names MUST start with uppercase letters. o Names MUST start with uppercase letters.
o Composed names MUST use capital letters for the first letter of o Composed names MUST use capital letters for the first letter of
each component. All other letters are lowercase, even for each component. All other letters are lowercase, even for
acronyms. Exceptions are made for acronyms containing a mixture acronyms. Exceptions are made for acronyms containing a mixture
of lowercase and capital letters, such as IPv6. Examples are of lowercase and capital letters, such as IPv6. Examples are
SourceMacAddress and DestinationIPv6Address. SourceMacAddress and DestinationIPv6Address.
5. End System and DetNet domain 5. Service model
5.1. 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.
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
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).
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])
Service attributes for DetNet connectivity are:
o Bandwidth parameter(s),
o Delay parameter(s),
o Loss parameter(s),
o Connectivity type,
o In order delivery,
o Service rank.
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.).
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.)
Depending on the application and the end-system capabilities DetNet
service may be requested to provide in order delivery.
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.
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:
o App-flow endpoint: End system's internal reference point for the
native data flow.
o DetNet-UNI: UNI interface ("U") on a DetNet edge node.
o DetNet-NNI: NNI interface ("N") between DetNet domains.
[[NOTE: Contributions are welcome whether we should define or
distinguish internal reference point(s) for DetNet-aware end-systems
as well. ]]
DetNet-UNI and DetNet-NNI are assumed in this document to be packet-
based reference points and provide connectivity over the packet
network and between domains. A DetNet-UNI adds networking technology
specific encapsulation to the data flow in order to transport it over
the network.
[[NOTE: Differences between the service over end-systems internal
reference points and DetNet-UNI is for further discussions. For
example, in-order delivery is expected in end system internal
reference points, whereas it is considered optional over the DetNet-
UNI. ]]
5.4. Service scenarios
Using the above defined reference points, two major service scenarios
can be identified:
o End-to-End-Service: the service reaches out to final source or
destination nodes, so it is an e2e service between application
hosting devices (end systems).
o DetNet-Service: the service connects networking islands, so it is
a service between the borders of network domain(s).
[[NOTE: we may consider to define further scenarios based on the
result of reference point related discussions. ]]
6. End System and DetNet domain
Deterministic service is required by time/loss sensitive Deterministic service is required by time/loss sensitive
application(s) running on an end system during communication with its application(s) running on an end system during communication with its
peer(s). Such a data exchange has various requirements on delay and/ peer(s). Such a data exchange has various requirements on delay and/
or loss parameters. or loss parameters.
The DetNet architecture [I-D.ietf-detnet-architecture] distinguishes The DetNet architecture [I-D.ietf-detnet-architecture] distinguishes
two kinds of end systems: Source and Destination. The same two kinds of end systems: Source and Destination. The same
distinction is applied for the DetNet flow information model. In distinction is applied for the DetNet flow information model. In
addition to the end systems interested in a flow, the status addition to the end systems interested in a flow, the status
skipping to change at page 7, line 31 skipping to change at page 9, line 44
There are two operations for each flow with respect to a Source or a There are two operations for each flow with respect to a Source or a
Destination (and an Ingress or an Egress): Destination (and an Ingress or an Egress):
o Join: Source/Destination request to join the flow. o Join: Source/Destination request to join the flow.
o Leave: Source/Destination request to leave the flow. o Leave: Source/Destination request to leave the flow.
o Modify: Source/Destination request to change the flow. o Modify: Source/Destination request to change the flow.
Modify operation can be considered to address cases when a flow is Modify operation can be considered to address cases when a flow is
slightly changed, e.g., only MaxPayloadSize (Section 6.2) has been slightly changed, e.g., only MaxPayloadSize (Section 7.2) has been
changed. The advantage of having a Modify is that it allows to changed. The advantage of having a Modify is that it allows to
initiate a change of flow spec while leaving the current flow is initiate a change of flow spec while leaving the current flow is
operating until the change is accepted. If there is no linkage operating until the change is accepted. If there is no linkage
between the Join and the Leave, then in figuring out whether the new between the Join and the Leave, then in figuring out whether the new
flow spec can be supported, the central entity has to assume that the flow spec can be supported, the central entity has to assume that the
resources committed to the current flow are in use. Via Modify the resources committed to the current flow are in use. Via Modify the
central entity knows that the resources supporting the current flow central entity knows that the resources supporting the current flow
can be available for supporting the altered flow. Modify is can be available for supporting the altered flow. Modify is
considered to be an optional operation due to possible control-plane considered to be an optional operation due to possible control-plane
limitations. limitations.
As the DetNet UNI can provide service for both L3 and L2 flows, end 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 systems may not need to implement the L3 <=> L2 Transfer Function
specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also specified by [IEEE8021CB] (see, e.g., subclause 6.3; see also
subclause 46.1 in [IEEE8021Qcc]). An edge node may implement a subclause 46.1 in [IEEE8021Qcc]). An edge node may implement a
function similar to the Transfer Function, see, e.g., the Svc Proxy function similar to the Transfer Function, see, e.g., the Svc Proxy
in Figure 1 in [I-D.ietf-detnet-dp-alt]. in Figure 1 in [I-D.ietf-detnet-dp-alt].
6. Flow 7. Flow
The flows leveraging DetNet service can be unicast or multicast data The flows leveraging DetNet service can be unicast or multicast data
flows for an application with constrained requirements on network flows for an application with constrained requirements on network
performance, e.g., low packet loss rate and/or latency. Therefore, performance, e.g., low packet loss rate and/or latency. Therefore,
they can require different connectivity types: point-to-point (p2p) they can require different connectivity types: point-to-point (p2p)
or point-to-multipoint (p2mp). The p2mp connectivity is created by a 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]. transport layer function (e.g., p2mp LSP) [I-D.ietf-detnet-dp-alt].
(Note that mp2mp connectivity is a superposition of p2mp (Note that mp2mp connectivity is a superposition of p2mp
connections.) connections.)
skipping to change at page 8, line 35 skipping to change at page 10, line 45
Some others may require high-bandwidth connections that make the Some others may require high-bandwidth connections that make the
usage of techniques like packet replication economically challenging usage of techniques like packet replication economically challenging
or even impossible. Some applications may not tolerate loss, but are or even impossible. Some applications may not tolerate loss, but are
not delay sensitive (e.g., bufferless sensors). Time/loss sensitive not delay sensitive (e.g., bufferless sensors). Time/loss sensitive
applications may have somewhat special requirements especially for applications may have somewhat special requirements especially for
loss (e.g., no loss in two consecutive communication cycles; very low loss (e.g., no loss in two consecutive communication cycles; very low
outage time, etc.). outage time, etc.).
Flows have the following attributes: Flows have the following attributes:
a. DataFlowSpecification (Section 6.1) a. DataFlowSpecification (Section 7.1)
b. TrafficSpecification (Section 6.2) b. TrafficSpecification (Section 7.2)
c. FlowRank (Section 6.3) c. FlowRank (Section 7.3)
Flow attributes are described in the following sections. Flow attributes are described in the following sections.
6.1. Identification and Specification of Flows 7.1. Identification and Specification of Flows
Identification options for DetNet flows at the UNI and within the Identification options for DetNet flows at the UNI and within the
DetNet domain are specified as follows; see Section 6.1.1 for DetNet DetNet domain are specified as follows; see Section 7.1.1 for DetNet
L3 flows (at UNI), Section 6.1.2 for DetNet L2 flows (at UNI) and L3 flows (at UNI), Section 7.1.2 for DetNet L2 flows (at UNI) and
Section 6.1.3 for DetNetwork flows (within the network). Section 7.1.3 for DetNetwork flows (within the network).
6.1.1. DetNet L3 Flow Identification and Specification at UNI 7.1.1. DetNet L3 Flow Identification and Specification at UNI
DetNet L3 flows can be identified and specified by the following DetNet L3 flows can be identified and specified by the following
attributes: attributes:
a. SourceIpAddress a. SourceIpAddress
b. DestinationIpAddress b. DestinationIpAddress
c. IPv6FlowLabel c. IPv6FlowLabel
d. Dscp d. Dscp
e. Protocol e. Protocol
f. SourcePort f. SourcePort
g. DestinationPort g. DestinationPort
6.1.2. DetNet L2 Flow Identification and Specification at UNI 7.1.2. DetNet L2 Flow Identification and Specification at UNI
DetNet L2 flows can be identified and specified by the following DetNet L2 flows can be identified and specified by the following
attributes: attributes:
a. DestinationMacAddress a. DestinationMacAddress
b. SourceMacAddress b. SourceMacAddress
c. Pcp c. Pcp
skipping to change at page 10, line 5 skipping to change at page 12, line 8
uses StreamID to match Talker registrations with their corresponding uses StreamID to match Talker registrations with their corresponding
Listener registrations, i.e., to identify Streams (L2 TSN flows). Listener registrations, i.e., to identify Streams (L2 TSN flows).
The StreamID includes the following subcomponents: The StreamID includes the following subcomponents:
o A 48-bit MAC Address associated with the Talker sourcing the o A 48-bit MAC Address associated with the Talker sourcing the
stream to the bridged network. stream to the bridged network.
o A 16-bit unsigned integer value, Unique ID, used to distinguish o A 16-bit unsigned integer value, Unique ID, used to distinguish
among multiple streams sourced by the same Talker. among multiple streams sourced by the same Talker.
6.1.3. DetNetwork Flow Identification and Specification 7.1.3. DetNetwork Flow Identification and Specification
Identification of DetNet flows within the DetNet domain are used in Identification of DetNet flows within the DetNet domain are used in
the service information model. The attributes are specific to the the service information model. The attributes are specific to the
forwarding paradigm within the DetNet domain. DetNetwork flows can forwarding paradigm within the DetNet domain. DetNetwork flows can
be identified and specified by the following attributes: be identified and specified by the following attributes:
a. SourceIpAddress a. SourceIpAddress
b. DestinationIpAddress b. DestinationIpAddress
c. IPv6FlowLabel c. IPv6FlowLabel
d. MplsLabel d. (Protocol)
6.2. Traffic Specification e. (SourcePort)
f. (DestinationPort)
g. MplsLabel
[[Note: attributes in brackets are dependant on current dataplane
discussions. ]]
7.2. Traffic Specification
TrafficSpecification specifies how the Source transmits packets for TrafficSpecification specifies how the Source transmits packets for
the flow. This is effectively the promise/request of the Source to the flow. This is effectively the promise/request of the Source to
the network. The network uses this traffic specification to allocate the network. The network uses this traffic specification to allocate
resources and adjust queue parameters in network nodes. resources and adjust queue parameters in network nodes.
TrafficSpecification has the following attributes: TrafficSpecification has the following attributes:
a. Interval: the period of time in which the traffic specification a. Interval: the period of time in which the traffic specification
cannot be exceeded. cannot be exceeded.
skipping to change at page 11, line 42 skipping to change at page 14, line 5
massage which is constant. 3GPP also defines approximately-periodic massage which is constant. 3GPP also defines approximately-periodic
transmission with variations on period and uncertainty in the time transmission with variations on period and uncertainty in the time
arrival of the packets. Event-triggered traffic type corresponds arrival of the packets. Event-triggered traffic type corresponds
traffic being triggered by an MTC device event. traffic being triggered by an MTC device event.
MinIntervalBetweenEvent, defines the minimum interval between two MinIntervalBetweenEvent, defines the minimum interval between two
events. Event-triggered transmission will not happen all the time, events. Event-triggered transmission will not happen all the time,
whenever an alert is sent, it waits until the issue being solved to whenever an alert is sent, it waits until the issue being solved to
be able to send another alert. MaxPacketPerEvent, defines the max be able to send another alert. MaxPacketPerEvent, defines the max
number of packets within one message. ]] number of packets within one message. ]]
6.3. Flow Rank 7.3. Flow Rank
FlowRank provides the rank of this flow relative to other flows in FlowRank provides the rank of this flow relative to other flows in
the network. This rank is used to determine success/failure of flow the network. This rank is used to determine success/failure of flow
establishment. Rank (boolean) is used by the network to decide which establishment. Rank (boolean) is used by the network to decide which
flows can and cannot exist when network resources reach their limit. 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., 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 removed from node configuration) if a port of a node becomes
oversubscribed (e.g., due to network reconfiguration). The true oversubscribed (e.g., due to network reconfiguration). The true
value is more important than the false value (i.e., flows with false value is more important than the false value (i.e., flows with false
are dropped first). are dropped first).
6.4. Service Rank 7.4. Service Rank
ServiceRank provides the rank of this service instance relative to ServiceRank provides the rank of this service instance relative to
other services in the network. This rank is used to determine other services in the network. This rank is used to determine
success/failure of service instance establishment. Rank (boolean) is success/failure of service instance establishment. Rank (boolean) is
used by the network to decide which services can and cannot exist used by the network to decide which services can and cannot exist
when network resources reach their limit. Rank is used to help to when network resources reach their limit. Rank is used to help to
determine which services can be dropped (i.e., removed from node determine which services can be dropped (i.e., removed from node
configuration) if a port of a node becomes oversubscribed (e.g., due configuration) if a port of a node becomes oversubscribed (e.g., due
to network reconfiguration). The true value is more important than to network reconfiguration). The true value is more important than
the false value (i.e., services with false are dropped first). the false value (i.e., services with false are dropped first).
7. Source [[NOTE: relationship between ServiceRank and FlowRank needs further
discussions. A 1:N relationship is assumed (a service instance can
serv multiple flows). This sub-section is considered to move to the
service related sections. ]]
8. Source
The Source object specifies: The Source object specifies:
o The behavior of the Source for the flow (how/when the Source o The behavior of the Source for the flow (how/when the Source
transmits). transmits).
o The requirements of the Source from the network. o The requirements of the Source from the network.
o The capabilities of the interface(s) of the Source. o The capabilities of the interface(s) of the Source.
The Source object includes the following attributes: The Source object includes the following attributes:
a. DataFlowSpecification (Section 6.1) a. DataFlowSpecification (Section 7.1)
b. TrafficSpecification (Section 6.2)
c. FlowRank (Section 6.3) b. TrafficSpecification (Section 7.2)
d. EndSystemInterfaces (Section 9.1) c. FlowRank (Section 7.3)
d. EndSystemInterfaces (Section 10.1)
e. InterfaceCapabilities (Section 9.2) e. InterfaceCapabilities (Section 10.2)
f. UserToNetworkRequirements (Section 9.3) f. UserToNetworkRequirements (Section 10.3)
For the join operation, the DataFlowSpecification, FlowRank, For the join operation, the DataFlowSpecification, FlowRank,
EndSystemInterfaces, and TrafficSpecification SHALL be included EndSystemInterfaces, and TrafficSpecification SHALL be included
within the Source. For the join operation, the within the Source. For the join operation, the
UserToNetworkRequirements and InterfaceCapabilities groups MAY be UserToNetworkRequirements and InterfaceCapabilities groups MAY be
included within the Source. included within the Source.
For the leave operation, the DataFlowSpecification and For the leave operation, the DataFlowSpecification and
EndSystemInterfaces SHALL be included within the Source. EndSystemInterfaces SHALL be included within the Source.
For the modify operation, the same object SHALL and MAY included as For the modify operation, the same object SHALL and MAY included as
for the join operation. for the join operation.
8. Destination 9. Destination
The Destination object includes the following attributes: The Destination object includes the following attributes:
a. DataFlowSpecification (Section 6.1) a. DataFlowSpecification (Section 7.1)
b. EndSystemInterfaces (Section 9.1) b. EndSystemInterfaces (Section 10.1)
c. InterfaceCapabilities (Section 9.2) c. InterfaceCapabilities (Section 10.2)
d. UserToNetworkRequirements (Section 9.3) d. UserToNetworkRequirements (Section 10.3)
For the join operation, the DataFlowSpecification and For the join operation, the DataFlowSpecification and
EndSystemInterfaces SHALL be included within the Destination. For EndSystemInterfaces SHALL be included within the Destination. For
the join operation, the UserToNetworkRequirements and the join operation, the UserToNetworkRequirements and
InterfaceCapabilities groups MAY be included within the Destination. InterfaceCapabilities groups MAY be included within the Destination.
For the leave operation, the DataFlowSpecification and For the leave operation, the DataFlowSpecification and
EndSystemInterfaces SHALL be included within the Destination. EndSystemInterfaces SHALL be included within the Destination.
For the modify operation, the same object SHALL and MAY included as For the modify operation, the same object SHALL and MAY included as
for the join operation. for the join operation.
[[NOTE (to be removed from a future revision): Should we add [[NOTE (to be removed from a future revision): Should we add
DestinationRank? It could distinguish the importance of Destinations DestinationRank? It could distinguish the importance of Destinations
if the flow cannot be provided for all Destinations.]] if the flow cannot be provided for all Destinations.]]
9. Common Attributes of Source and Destination 10. Common Attributes of Source and Destination
Source and Destination end systems have the following common Source and Destination end systems have the following common
attributes in addition to DataFlowSpecification (Section 6.1). attributes in addition to DataFlowSpecification (Section 7.1).
9.1. End System Interfaces 10.1. End System Interfaces
EndSystemInterfaces is a list of identifiers, one for each physical EndSystemInterfaces is a list of identifiers, one for each physical
interface (port) in the end system acting as a Source or Destination. interface (port) in the end system acting as a Source or Destination.
An interface is identified by an IP or a MAC address. An interface is identified by an IP or a MAC address.
EndSystemInterfaces can refer also to logical sub-Interfaces if EndSystemInterfaces can refer also to logical sub-Interfaces if
supported by the end system, e.g., based on IfIndex parameter. supported by the end system, e.g., based on IfIndex parameter.
9.2. Interface Capabilities 10.2. Interface Capabilities
InterfaceCapabilities specifies the network capabilities of all InterfaceCapabilities specifies the network capabilities of all
interfaces (ports) contained in the EndSystemInterfaces object interfaces (ports) contained in the EndSystemInterfaces object
(Section 9.1). These capabilities may be configured via the (Section 10.1). These capabilities may be configured via the
InterfaceConfiguration object (Section 13.2) of the Status object InterfaceConfiguration object (Section 14.2) of the Status object
(Section 13). (Section 14).
Note that an end system may have multiple interfaces with different Note that an end system may have multiple interfaces with different
network capabilities. In this case, each interface should be network capabilities. In this case, each interface should be
specified in a distinct top-level Source or Destination object (i.e., specified in a distinct top-level Source or Destination object (i.e.,
one entry in EndSystemInterfaces (Section 9.1)). Use of multiple one entry in EndSystemInterfaces (Section 10.1)). Use of multiple
entries in EndSystemInterfaces is intended for network capabilities entries in EndSystemInterfaces is intended for network capabilities
that span multiple interfaces (e.g., packet replication and that span multiple interfaces (e.g., packet replication and
elimination).";. elimination).";.
InterfaceCapabilities attributes: InterfaceCapabilities attributes:
a. SubInterfaceCapable (sub-interface capable) a. SubInterfaceCapable (sub-interface capable)
b. PREF-Capable (packet replication and elimination capable) b. PREF-Capable (packet replication and elimination capable)
skipping to change at page 14, line 36 skipping to change at page 17, line 10
o CB-StreamIdenTypeList (a list of the optional Stream o CB-StreamIdenTypeList (a list of the optional Stream
Identification types supported by the interface as specified in Identification types supported by the interface as specified in
[IEEE8021CB].) [IEEE8021CB].)
o CB-SequenceTypeList (a list of the optional Sequence Encode/Decode o CB-SequenceTypeList (a list of the optional Sequence Encode/Decode
types supported by the interface as specified in [IEEE8021CB].) types supported by the interface as specified in [IEEE8021CB].)
]] ]]
9.3. User to Network Requirements 10.3. User to Network Requirements
UserToNetworkRequirements specifies user requirements for the flow, UserToNetworkRequirements specifies user requirements for the flow,
such as latency and reliability. such as latency and reliability.
The UserToNetworkRequirements object includes the following The UserToNetworkRequirements object includes the following
attributes: attributes:
a. NumReplicationTrees a. NumReplicationTrees
b. MaxLatency b. MaxLatency
skipping to change at page 15, line 4 skipping to change at page 17, line 27
a. NumReplicationTrees a. NumReplicationTrees
b. MaxLatency b. MaxLatency
NumReplicationTrees specifies the number of maximally disjoint trees NumReplicationTrees specifies the number of maximally disjoint trees
that the network should configure to provide packet replication and that the network should configure to provide packet replication and
elimination for the flow. NumReplicationTrees is provided by the elimination for the flow. NumReplicationTrees is provided by the
Source only. Destinations SHALL set this element to one. Value zero Source only. Destinations SHALL set this element to one. Value zero
and one indicate no packet replication and elimination for the flow. and one indicate no packet replication and elimination for the flow.
When NumReplicationTrees is greater than one, packet replication and When NumReplicationTrees is greater than one, packet replication and
elimination is to be used for the flow. If the Source sets this elimination is to be used for the flow. If the Source sets this
element to greater than one, and packet replication and elimination element to greater than one, and packet replication and elimination
is not possible in the network (e.g., no disjoint paths, or the nodes is not possible in the network (e.g., no disjoint paths, or the nodes
do not support packet replication and elimination), then the do not support packet replication and elimination), then the
FailureCode of the Status object is non-zero (Section 13.1). FailureCode of the Status object is non-zero (Section 14.1).
MaxLatency is the maximum latency from Source to Destination(s) for a MaxLatency is the maximum latency from Source to Destination(s) for a
single packet of the flow. MaxLatency is specified as an integer single packet of the flow. MaxLatency is specified as an integer
number of nanoseconds. When this requirement is specified by the number of nanoseconds. When this requirement is specified by the
Source, it must be satisfied for all Destinations. When this Source, it must be satisfied for all Destinations. When this
requirement is specified by a Destination, it must be satisfied for requirement is specified by a Destination, it must be satisfied for
that particular Destination only. If the UserToNetworkRequirements that particular Destination only. If the UserToNetworkRequirements
group is not provided within the Source or Destination object, then group is not provided within the Source or Destination object, then
value zero SHALL be used for this element. Value zero represents a value zero SHALL be used for this element. Value zero represents a
special use for the maximum latency requirement. Value zero locks- special use for the maximum latency requirement. Value zero locks-
down the initial latency that the network provides in the down the initial latency that the network provides in the
AccumulatedLatency parameter of the Status object (Section 13) after AccumulatedLatency parameter of the Status object (Section 14) after
the successful configuration of the flow, such that any subsequent the successful configuration of the flow, such that any subsequent
increase in the latency beyond that initial value causes the flow to increase in the latency beyond that initial value causes the flow to
fail. fail.
[[NOTE-1 (to be removed from a future revision): Should we add a [[NOTE-1 (to be removed from a future revision): Should we add a
parameter to specify the maximum packet loss rate that can be parameter to specify the maximum packet loss rate that can be
tolerated for the flow?]] tolerated for the flow?]]
[[NOTE-2 (to be removed from a future revision): TrafficSpecification [[NOTE-2 (to be removed from a future revision): TrafficSpecification
(Section 6.2) specifies the Peak Information Rate (PIR) of the flow, (Section 7.2) specifies the Peak Information Rate (PIR) of the flow,
which is a kind of user requirement to the network. Should we add which is a kind of user requirement to the network. Should we add
Committed Information Rate (CIR), i.e., the minimum rate the user Committed Information Rate (CIR), i.e., the minimum rate the user
requests to be guaranteed for the flow by the network?]] requests to be guaranteed for the flow by the network?]]
10. Ingress 11. Ingress
Placeholder ... Placeholder ...
11. Egress 12. Egress
Placeholder ... Placeholder ...
12. DetNet Domain 13. DetNet Domain
The DetNet Domain may change the encapsulation of a DetNet L2 or L3 The DetNet Domain may change the encapsulation of a DetNet L2 or L3
flow at the UNI. That impacts not only how a flow can be recognised flow at the UNI. That impacts not only how a flow can be recognised
inside the DetNet domain but also the resource reservation inside the DetNet domain but also the resource reservation
calculations. calculations.
The DetNet Domain object specifies: The DetNet Domain object specifies:
o The behavior of the flow (how/when it is transmited). o The behavior of the flow (how/when it is transmited).
o The requirements of the flow from the network. o The requirements of the flow from the network.
o The capabilities of the DetNet domain. o The capabilities of the DetNet domain.
The DetNet domain object includes the following attributes: The DetNet domain object includes the following attributes:
a. DataFlowSpecification (Section 6.1) a. DataFlowSpecification (Section 7.1)
b. TrafficSpecification (Section 6.2) b. TrafficSpecification (Section 7.2)
c. ServiceRank (Section 6.4) c. ServiceRank (Section 7.4)
d. DetnetDomainCapabilities (Section 12.1) d. DetnetDomainCapabilities (Section 13.1)
e. UserToNetworkRequirements (Section 9.3) e. UserToNetworkRequirements (Section 10.3)
12.1. DetNet Domain Capabilities 13.1. DetNet Domain Capabilities
DetnetDomainCapabilities specifies the network capabilities, which DetnetDomainCapabilities specifies the network capabilities, which
can be used to provide DetNet service. DetNet Edge nodes may change can be used to provide DetNet service. DetNet Edge nodes may change
the encapsulation of a flow according to the data plane used inside the encapsulation of a flow according to the data plane used inside
the DetNet domain. the DetNet domain.
DetnetDomainCapabilities object includes the following attributes: DetnetDomainCapabilities object includes the following attributes:
a. EncapsulationFormat (data plane specific encapsulation) a. EncapsulationFormat (data plane specific encapsulation)
b. PREF-Capable (packet replication and elimination capable) b. PREF-Capable (packet replication and elimination capable)
13. Flow-status 14. Flow-status
The FlowStatus object is provided by the network each Source and The FlowStatus object is provided by the network each Source and
Destination of the flow. The Status object provides the status of Destination of the flow. The Status object provides the status of
the flow with respect to the establishment of the flow by the the flow with respect to the establishment of the flow by the
network. The Status object is delivered via the corresponding UNI to network. The Status object is delivered via the corresponding UNI to
each Source and Destination end system of the flow. The Status is each Source and Destination end system of the flow. The Status is
distinct for each Source or Destination because the distinct for each Source or Destination because the
AccumulatedLatency and InterfaceConfiguration objects are distinct, AccumulatedLatency and InterfaceConfiguration objects are distinct,
see below. see below.
The Status object SHALL include the attributes a), b), c); and MAY The Status object SHALL include the attributes a), b), c); and MAY
include attributes d), e): include attributes d), e):
a. DataFlowSpecification (Section 6.1) a. DataFlowSpecification (Section 7.1)
b. StatusInfo (Section 14.1)
b. StatusInfo (Section 13.1)
c. AccumulatedLatency (this section below) c. AccumulatedLatency (this section below)
d. InterfaceConfiguration (Section 13.2) d. InterfaceConfiguration (Section 14.2)
e. FailedInterfaces (Section 13.3) e. FailedInterfaces (Section 14.3)
DataFlowSpecification identifies the flow for which status is DataFlowSpecification identifies the flow for which status is
provided. DataFlowSpecification is described in (Section 6.1) If the provided. DataFlowSpecification is described in (Section 7.1) If the
Status object is provided without a Source or Destination object in a Status object is provided without a Source or Destination object in a
protocol message via a UNI, then the DataFlowSpecification object protocol message via a UNI, then the DataFlowSpecification object
SHALL be included within the Status object for both join and leave SHALL be included within the Status object for both join and leave
operations. If the Status object immediately follows a Source or operations. If the Status object immediately follows a Source or
Destination object in the protocol message, then the Destination object in the protocol message, then the
DataFlowSpecification object is obtained from the Source/Destination DataFlowSpecification object is obtained from the Source/Destination
object, and therefore DataFlowSpecification is not required within object, and therefore DataFlowSpecification is not required within
the Status object. the Status object.
AccumulatedLatency provides the worst-case latency that a single AccumulatedLatency provides the worst-case latency that a single
packet of the flow can encounter along its current path(s) in the packet of the flow can encounter along its current path(s) in the
network. When provided to a Source, AccumulatedLatency is the worst- network. When provided to a Source, AccumulatedLatency is the worst-
case latency for all Destinations (worst path). AccumulatedLatency case latency for all Destinations (worst path). AccumulatedLatency
is specified as an integer number of nanoseconds. Latency is is specified as an integer number of nanoseconds. Latency is
measured using the time at which the data frame's message timestamp measured using the time at which the data frame's message timestamp
point passes the reference plane marking the boundary between the point passes the reference plane marking the boundary between the
network media and PHY. The message timestamp point is specified by network media and PHY. The message timestamp point is specified by
IEEE Std 802.1AS [IEEE8021AS] for various media. For a successful IEEE Std 802.1AS [IEEE8021AS] for various media. For a successful
Status, the network returns a value less than or equal to the Status, the network returns a value less than or equal to the
MaxLatency of the UserToNetworkRequirements (Section 9.3). If the MaxLatency of the UserToNetworkRequirements (Section 10.3). If the
NumReplicationTrees of the UserToNetworkRequirements (Section 9.3) is NumReplicationTrees of the UserToNetworkRequirements (Section 10.3)
one, then the AccumlatedLatency SHALL provide the worst latency for is one, then the AccumlatedLatency SHALL provide the worst latency
the current path from the Source to each Destination. If the path is for the current path from the Source to each Destination. If the
changed (e.g., due to rerouting), then the AccumulatedLatency changes path is changed (e.g., due to rerouting), then the AccumulatedLatency
accordingly. If the NumReplicationTrees of the changes accordingly. If the NumReplicationTrees of the
UserToNetworkRequirements (Section 9.3) is greater than one, UserToNetworkRequirements (Section 10.3) is greater than one,
AccumlatedLatency SHALL provide the worst latency for all paths in AccumlatedLatency SHALL provide the worst latency for all paths in
use from the Source to each Destination. use from the Source to each Destination.
13.1. Status Info 14.1. Status Info
StatusInfo provides information regarding the status of a flow's StatusInfo provides information regarding the status of a flow's
configuration in the network. configuration in the network.
The StatusInfo object MAY include the following attributes: The StatusInfo object MAY include the following attributes:
a. SourceStatus is an enumeration for the status of the flow's a. SourceStatus is an enumeration for the status of the flow's
Source: Source:
* None: no Source * None: no Source
skipping to change at page 18, line 31 skipping to change at page 21, line 9
c. FailureCode: A non-zero code that specifies the problem if the c. FailureCode: A non-zero code that specifies the problem if the
flow encounters a failure (e.g., packet replication and flow encounters a failure (e.g., packet replication and
elimination is requested but not possible, or SourceStatus is elimination is requested but not possible, or SourceStatus is
Failed, or DestinationStatus is Failed, or DestinationStatus is Failed, or DestinationStatus is Failed, or DestinationStatus is
PartialFailed). PartialFailed).
[[NOTE (to be removed from a future revision): FailureCodes to be [[NOTE (to be removed from a future revision): FailureCodes to be
defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN defined for DetNet. Table 46-1 of [IEEE8021Qcc] describes TSN
failure codes.]] failure codes.]]
13.2. Interface Configuration 14.2. Interface Configuration
InterfaceConfiguration provides information about of interfaces in InterfaceConfiguration provides information about of interfaces in
the Source/Destination. This configuration related information the Source/Destination. This configuration related information
assists the network in meeting the requirements of the flow. The assists the network in meeting the requirements of the flow. The
InterfaceConfiguration object is according to the capabilities of the InterfaceConfiguration object is according to the capabilities of the
interface. InterfaceConfiguration can be distinct for each Source or interface. InterfaceConfiguration can be distinct for each Source or
Destination of each flow. If the InterfaceConfiguration object is Destination of each flow. If the InterfaceConfiguration object is
not provided within the Status object, then the network SHALL assume not provided within the Status object, then the network SHALL assume
zero elements as the default (no interface configuration). zero elements as the default (no interface configuration).
The InterfaceConfiguration object MAY include one or more the The InterfaceConfiguration object MAY include one or more the
following attributes: following attributes:
a. MAC or IP Address to identify the interface a. MAC or IP Address to identify the interface
b. DataFlowSpecification (Section 6.1) b. DataFlowSpecification (Section 7.1)
13.3. Failed Interfaces 14.3. Failed Interfaces
FailedInterfaces provides a list of one or more physical interfaces FailedInterfaces provides a list of one or more physical interfaces
(ports) in the failed node when a failure occurs in the network. (ports) in the failed node when a failure occurs in the network.
The FailedInterface object includes the following attributes: The FailedInterface object includes the following attributes:
a. MAC or IP Address to identify the interface a. MAC or IP Address to identify the interface
b. InterfaceName b. InterfaceName
InterfaceName is the name of the interface (port) within the node. InterfaceName is the name of the interface (port) within the node.
This interface name SHALL be persistent, and unique within the node. This interface name SHALL be persistent, and unique within the node.
14. Service-status 15. Service-status
Placeholder ... Placeholder ...
15. Summary 16. Summary
This document describes DetNet flow information model both for DetNet This document describes DetNet flow information model both for DetNet
L3 flows and DetNet L2 flows based on the TSN data model specified by L3 flows and DetNet L2 flows based on the TSN data model specified by
[IEEE8021Qcc]. This revision is extended with DetNet specific flow [IEEE8021Qcc]. This revision is extended with DetNet specific flow
information model elements. information model elements.
16. IANA Considerations 17. IANA Considerations
N/A. N/A.
17. Security Considerations 18. Security Considerations
N/A. N/A.
18. References 19. References
18.1. Normative References 19.1. Normative References
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-03 (work in progress), August 2017. detnet-architecture-03 (work in progress), August 2017.
[I-D.ietf-detnet-dp-alt] [I-D.ietf-detnet-dp-alt]
Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., Korhonen, J., Farkas, J., Mirsky, G., Thubert, P.,
Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol
and Solution Alternatives", draft-ietf-detnet-dp-alt-00 and Solution Alternatives", draft-ietf-detnet-dp-alt-00
skipping to change at page 20, line 23 skipping to change at page 22, line 46
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters",
RFC 6003, DOI 10.17487/RFC6003, October 2010, RFC 6003, DOI 10.17487/RFC6003, October 2010,
<https://www.rfc-editor.org/info/rfc6003>. <https://www.rfc-editor.org/info/rfc6003>.
18.2. Informative References 19.2. Informative References
[GPP22885] [GPP22885]
3GPP, "Study on LTE support for Vehicle-to-Everything 3GPP, "Study on LTE support for Vehicle-to-Everything
(V2X) services", (V2X) services",
<http://www.3gpp.org/DynaReport/22885.html>. <http://www.3gpp.org/DynaReport/22885.html>.
[IEEE8021AS] [IEEE8021AS]
IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local IEEE 802.1, "IEEE 802.1AS-2011: IEEE Standard for Local
and metropolitan area networks - Timing and and metropolitan area networks - Timing and
Synchronization for Time-Sensitive Applications in Bridged Synchronization for Time-Sensitive Applications in Bridged
skipping to change at page 22, line 4 skipping to change at page 24, line 19
Email: janos.farkas@ericsson.com Email: janos.farkas@ericsson.com
Balazs Varga Balazs Varga
Ericsson Ericsson
Konyves Kalman krt. 11/B Konyves Kalman krt. 11/B
Budapest 1097 Budapest 1097
Hungary Hungary
Email: balazs.a.varga@ericsson.com Email: balazs.a.varga@ericsson.com
Rodney Cummings Rodney Cummings
National Instruments National Instruments
11500 N. Mopac Expwy 11500 N. Mopac Expwy
Bldg. C Bldg. C
Austin, TX 78759-3504 Austin, TX 78759-3504
USA USA
Email: rodney.cummings@ni.com Email: rodney.cummings@ni.com
Jiang Yuanlong Yuanlong Jiang
Huawei Huawei
Email: jiangyuanlong@huawei.com Email: jiangyuanlong@huawei.com
Zha Yiyong Yiyong Zha
Huawei Tencent
Email: zhayiyong@huawei.com
 End of changes. 73 change blocks. 
116 lines changed or deleted 245 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/