draft-ietf-detnet-flow-information-model-01.txt   draft-ietf-detnet-flow-information-model-02.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: September 6, 2018 R. Cummings Expires: April 25, 2019 R. Cummings
National Instruments National Instruments
Y. Jiang Y. Jiang
Huawei
Y. Zha Y. Zha
Tencent Huawei Technologies Co., Ltd.
March 05, 2018 October 22, 2018
DetNet Flow Information Model DetNet Flow Information Model
draft-ietf-detnet-flow-information-model-01 draft-ietf-detnet-flow-information-model-02
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 40 skipping to change at page 1, line 39
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 September 6, 2018. This Internet-Draft will expire on April 25, 2019.
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 44 skipping to change at page 2, line 43
7.4. Service Rank . . . . . . . . . . . . . . . . . . . . . . 14 7.4. Service Rank . . . . . . . . . . . . . . . . . . . . . . 14
8. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Source . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Destination . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Common Attributes of Source and Destination . . . . . . . . . 16 10. Common Attributes of Source and Destination . . . . . . . . . 16
10.1. End System Interfaces . . . . . . . . . . . . . . . . . 16 10.1. End System Interfaces . . . . . . . . . . . . . . . . . 16
10.2. Interface Capabilities . . . . . . . . . . . . . . . . . 16 10.2. Interface Capabilities . . . . . . . . . . . . . . . . . 16
10.3. User to Network Requirements . . . . . . . . . . . . . . 17 10.3. User to Network Requirements . . . . . . . . . . . . . . 17
11. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 18 13. DetNet Domain . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 18 13.1. DetNet Domain Capabilities . . . . . . . . . . . . . . . 19
14. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. Flow-status . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 20 14.1. Status Info . . . . . . . . . . . . . . . . . . . . . . 20
14.2. Interface Configuration . . . . . . . . . . . . . . . . 21 14.2. Interface Configuration . . . . . . . . . . . . . . . . 21
14.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 21 14.3. Failed Interfaces . . . . . . . . . . . . . . . . . . . 21
15. Service-status . . . . . . . . . . . . . . . . . . . . . . . 21 15. Service-status . . . . . . . . . . . . . . . . . . . . . . . 22
16. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 16. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
18. Security Considerations . . . . . . . . . . . . . . . . . . . 22 18. Security Considerations . . . . . . . . . . . . . . . . . . . 22
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
19.1. Normative References . . . . . . . . . . . . . . . . . . 22 19.1. Normative References . . . . . . . . . . . . . . . . . . 22
19.2. Informative References . . . . . . . . . . . . . . . . . 22 19.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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-sol-mpls]. 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
network. DetNet and TSN have common architecture as expressed in network. DetNet and TSN have common architecture as expressed in
[IETFDetNet] and [I-D.ietf-detnet-architecture]. DetNet service can [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 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 DetNet L2 flows. Therefore, the DetNet flow and service information
model provided by this document covers both DetNet L3 flows and model provided by this document covers both DetNet L3 flows and
DetNet L2 flows in an integrated fashion. DetNet L2 flows in an integrated fashion.
In a given network scenario three information models can In a given network scenario three information models can
distinguished: distinguished:
skipping to change at page 6, line 30 skipping to change at page 6, line 30
e.g., low packet loss rate and/or latency. e.g., low packet loss rate and/or latency.
The simplest DetNet service is to provide bridging over the DN domain 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 (i.e., tunneling for L2), where the connected hosts are in the same
broadcast (BC) domain. Forwarding over the DetNet domain is based on broadcast (BC) domain. Forwarding over the DetNet domain is based on
L2 (MAC) addresses (i.e. dst-MAC). Somewhat more sophisticated is L2 (MAC) addresses (i.e. dst-MAC). Somewhat more sophisticated is
DetNet Routing service that provides routing, so available only for DetNet Routing service that provides routing, so available only for
L3 hosts that are in different BC domains. Forwarding over the L3 hosts that are in different BC domains. Forwarding over the
DetNet domain is based on L3 (IP) addresses (i.e. dst-IP). 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. DetNet service related reference points and main components.
5.2. Service parameters 5.2. Service parameters
Two forwarding methods are distinguished: (1) Bridging and (2) A DetNet network receives DetNet flows via a UNI as shown in Figure 5
Routing. The DN service is represented by a DN-PSeudoWire (DN-PW). 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 The DetNet service attributes are the following:
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
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), * Packet Delay Variation (PDV), which is the difference between
o Connectivity type, 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 * Some applications have special loss requirement. The maximum
requirements especially for loss (e.g., no loss in two consecutive consecutive loss tolerance parameter describes the maximum
communication cycles; very low outage time, etc.). 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 o Maximum allowed misordering
point-to-multipoint (p2mp). Connectivity type p2mp is created by a Maximum allowed misordering describes the tolerable maximum number
transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity of packets that can be received out of order. The maximum allowed
is a superposition of p2mp connections.) 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 o Connectivity type
service may be requested to provide in order delivery. 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.)
Service rank provides the rank of a service instance relative to o Service rank
other services in the network. Rank is used by the network in case Service rank provides the rank of a service instance relative to
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 5.3. Reference Points
From service model design perspective a fundamental question is the From service model design perspective a fundamental question is the
location of the service endpoints, i.e., where the service starts and location of the service endpoints, i.e., where the service starts and
ends. ends.
Note: Further discussion is needed based on data plane encapsulation Note: Further discussion is needed based on data plane encapsulation
results what reference points should be defined. Only some possible results what reference points should be defined. Only some possible
examples listed here: examples listed here:
skipping to change at page 10, line 13 skipping to change at page 10, line 27
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 3 in [I-D.ietf-detnet-architecture].
7. 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)
(Note that mp2mp connectivity is a superposition of p2mp [I-D.ietf-detnet-dp-sol-mpls]. (Note that mp2mp connectivity is a
connections.) superposition of p2mp connections.)
Many flows using DetNet service are periodic with fix packet size Many flows using DetNet service are periodic with fix packet size
(i.e., Constant Bit Rate (CBR) flows), or periodic with variable (i.e., Constant Bit Rate (CBR) flows), or periodic with variable
packet size. packet size.
Delay and loss parameters are correlated because the effect of late Delay and loss parameters are correlated because the effect of late
delivery can result data loss for an application. However, not all delivery can result data loss for an application. However, not all
applications require hard limits on both parameters (delay and loss). applications require hard limits on both parameters (delay and loss).
For example, some real-time applications allow graceful degradation For example, some real-time applications allow graceful degradation
if loss happens (e.g., sample-based processing, media distribution). if loss happens (e.g., sample-based processing, media distribution).
skipping to change at page 13, line 38 skipping to change at page 14, line 4
Committed Rate indicates the rate at which traffic commits to be sent Committed Rate indicates the rate at which traffic commits to be sent
by the source (described in terms of the CIR (Committed Information by the source (described in terms of the CIR (Committed Information
Rate) and CBS (Committed Burst Size) attributes.) Excess Rate Rate) and CBS (Committed Burst Size) attributes.) Excess Rate
indicates the extent by which the traffic sent by the source exceeds 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 the committed rate. The Excess Rate is described in terms of the EIR
(Excess Information Rate) and EBS (Excess Burst Size) attributes. ]] (Excess Information Rate) and EBS (Excess Burst Size) attributes. ]]
[[NOTE3: a third alternative is to define application based traffic [[NOTE3: a third alternative is to define application based traffic
models such as [GPP22885] defines periodic and event-driven traffic models such as [GPP22885] defines periodic and event-driven traffic
model, and 5G PPP work defines traffic model for MTC (Machine Type model, and 5G PPP work defines traffic model for MTC (Machine Type
Communication) use cases. Periodic traffic type is usually for Communication) use cases [I-D.ietf-detnet-use-cases]. Periodic
status update between devices or devices transmit status report to a traffic type is usually for status update between devices or devices
central unit in regular basis. TrafficPeriod, defines the period of transmit status report to a central unit in regular basis.
the status update message. DataSize, defines the data size of the TrafficPeriod, defines the period of the status update message.
massage which is constant. 3GPP also defines approximately-periodic DataSize, defines the data size of the massage which is constant.
transmission with variations on period and uncertainty in the time 3GPP also defines approximately-periodic transmission with variations
arrival of the packets. Event-triggered traffic type corresponds on period and uncertainty in the time arrival of the packets. Event-
traffic being triggered by an MTC device event. triggered traffic type corresponds traffic being triggered by an MTC
MinIntervalBetweenEvent, defines the minimum interval between two device event. MinIntervalBetweenEvent, defines the minimum interval
events. Event-triggered transmission will not happen all the time, between two events. Event-triggered transmission will not happen all
whenever an alert is sent, it waits until the issue being solved to the time, whenever an alert is sent, it waits until the issue being
be able to send another alert. MaxPacketPerEvent, defines the max solved to be able to send another alert. MaxPacketPerEvent, defines
number of packets within one message. ]] the max number of packets within one message. ]]
7.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
skipping to change at page 22, line 20 skipping to change at page 22, line 31
N/A. N/A.
19. References 19. References
19.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-08 (work in progress), September 2018.
[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.
[I-D.ietf-detnet-use-cases] [I-D.ietf-detnet-dp-sol-mpls]
Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., Korhonen, J. and B. Varga, "DetNet MPLS Data Plane
Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in
Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana, progress), October 2018.
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.
[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>.
19.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>.
[I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-19 (work in progress), October 2018.
[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
Local Area Networks", 2011, Local Area Networks", 2011,
<http://standards.ieee.org/getieee802/ <http://standards.ieee.org/getieee802/
download/802.1AS-2011.pdf>. download/802.1AS-2011.pdf>.
[IEEE8021CB] [IEEE8021CB]
IEEE 802.1, "IEEE P802.1CB: IEEE Draft Standard for Local IEEE 802.1, "IEEE P802.1CB: IEEE Draft Standard for Local
skipping to change at page 24, line 4 skipping to change at page 24, line 6
[IEEE8021TSN] [IEEE8021TSN]
IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN)
Task Group", <http://www.ieee802.org/1/pages/tsn.html>. Task Group", <http://www.ieee802.org/1/pages/tsn.html>.
[IETFDetNet] [IETFDetNet]
IETF, "IETF Deterministic Networking (DetNet) Working IETF, "IETF Deterministic Networking (DetNet) Working
Group", <https://datatracker.ietf.org/wg/detnet/charter/>. Group", <https://datatracker.ietf.org/wg/detnet/charter/>.
Authors' Addresses Authors' Addresses
Janos Farkas Janos Farkas
Ericsson Ericsson
Konyves Kalman krt. 11/B Magyar tudosok korutja 11
Budapest 1097 Budapest 1117
Hungary Hungary
Email: janos.farkas@ericsson.com Email: janos.farkas@ericsson.com
Balazs Varga Balazs Varga
Ericsson Ericsson
Konyves Kalman krt. 11/B Magyar tudosok korutja 11
Budapest 1097 Budapest 1117
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
Yuanlong Jiang Yuanlong Jiang
Huawei Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129
China
Email: jiangyuanlong@huawei.com Email: jiangyuanlong@huawei.com
Yiyong Zha Yiyong Zha
Tencent Huawei Technologies Co., Ltd.
China
Email: zhayiyong@huawei.com
 End of changes. 33 change blocks. 
76 lines changed or deleted 86 lines changed or added

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