< draft-malis-detnet-controller-plane-framework-00.txt   draft-malis-detnet-controller-plane-framework-01.txt >
Network Working Group A. Malis Network Working Group A. Malis
Internet-Draft Futurewei Technologies Internet-Draft Futurewei Technologies
Intended status: Informational July 02, 2019 Intended status: Informational X. Geng
Expires: January 3, 2020 Expires: January 6, 2020 M. Chen
Huawei
F. Qin
China Mobile
July 05, 2019
Deterministic Networking (DetNet) Controller Plane Framework Deterministic Networking (DetNet) Controller Plane Framework
draft-malis-detnet-controller-plane-framework-00 draft-malis-detnet-controller-plane-framework-01
Abstract Abstract
This document provides a framework overview for the Deterministic This document provides a framework overview for the Deterministic
Networking (DetNet) controller plane. It discusses concepts and Networking (DetNet) controller plane. It discusses concepts and
requirements that will be basis for Detnet controller plane solution requirements that will be basis for Detnet controller plane solution
documents. documents.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 37
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 January 3, 2020. This Internet-Draft will expire on January 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. DetNet Controller Plane Requirements . . . . . . . . . . . . 3 2. DetNet Controller Plane Requirements . . . . . . . . . . . . 4
3. DetNet Controller Plane Architecture . . . . . . . . . . . . 5 3. DetNet Control Plane Architecture . . . . . . . . . . . . . . 5
3.1. Distributed Control Plane and Signaling Protocols . . . . 5 3.1. Distributed Control Plane and Signaling Protocols . . . . 5
3.2. SDN/Fully Centralized Control Plane . . . . . . . . . . . 6 3.2. SDN/Fully Centralized Control Plane . . . . . . . . . . . 6
3.3. Hybrid Control Plane . . . . . . . . . . . . . . . . . . 7 3.3. Hybrid Control Plane . . . . . . . . . . . . . . . . . . 7
4. Control Plane for DetNet Domains . . . . . . . . . . . . . . 8 4. DetNet Control Plane Additional Details and Issues . . . . . 8
4.1. DetNet in a Traditional MPLS Domain . . . . . . . . . . . 8 4.1. Explicit Paths . . . . . . . . . . . . . . . . . . . . . 8
4.2. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Resource Reservation . . . . . . . . . . . . . . . . . . 8
4.3. DetNet with Segment Routing (SR) . . . . . . . . . . . . 9 4.3. PREOF Support . . . . . . . . . . . . . . . . . . . . . . 9
5. Management Plane Overview . . . . . . . . . . . . . . . . . . 10 4.4. DetNet in a Traditional MPLS Domain . . . . . . . . . . . 9
5.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 10 4.5. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. DetNet Operations, Administration and Maintenance (OAM) . 10 4.6. DetNet with Segment Routing (SR) . . . . . . . . . . . . 10
5.2.1. OAM for Performance Monitoring (PM) . . . . . . . . . 10 5. Management Plane Overview . . . . . . . . . . . . . . . . . . 12
5.2.2. OAM for Fault/Defect Management (FM) . . . . . . . . 11 5.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5.2. DetNet Operations, Administration and Maintenance (OAM) . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5.2.1. OAM for Performance Monitoring (PM) . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 5.2.2. OAM for Fault/Defect Management (FM) . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Deterministic Networking (DetNet) provides the capability to carry Deterministic Networking (DetNet) provides the capability to carry
specified unicast and/or multicast data flows for real-time specified unicast and/or multicast data flows for real-time
applications with extremely low data loss rates and bounded latency applications with extremely low data loss rates and bounded latency
within a network domain. As discussed in the Deterministic within a network domain. As discussed in the Deterministic
Networking Architecture [I-D.ietf-detnet-architecture], techniques Networking Architecture [I-D.ietf-detnet-architecture], techniques
used to provide this capability include reserving data plane used to provide this capability include reserving data plane
resources for individual (or aggregated) DetNet flows in some or all resources for individual (or aggregated) DetNet flows in some or all
skipping to change at page 5, line 15 skipping to change at page 5, line 22
slicing [I-D.dong-spring-sr-for-enhanced-vpn]. slicing [I-D.dong-spring-sr-for-enhanced-vpn].
o Provision flow identification information at each of the nodes o Provision flow identification information at each of the nodes
along the path. Flow identification may differ depending on the along the path. Flow identification may differ depending on the
location in the network and the DetNet functionality (e.g. transit location in the network and the DetNet functionality (e.g. transit
node vs. relay node). node vs. relay node).
o Monitor the performance of DetNet flows to ensure that they are o Monitor the performance of DetNet flows to ensure that they are
meeting required objectives. meeting required objectives.
3. DetNet Controller Plane Architecture 3. DetNet Control Plane Architecture
As noted in the Introduction, the DetNet control plane is responsible
for the instantiation and maintenance of flows, MPLS label allocation
and distribution, and active in-band or out-of-band signaling to
support these functions.
The following sections define three possible classes of DetNet The following sections define three possible classes of DetNet
control plane architectures: a fully distributed control plane control plane architectures: a fully distributed control plane
utilizing dynamic signaling protocols, a fully centralized SDN-like utilizing dynamic signaling protocols, a fully centralized SDN-like
control plane, and a hybrid control plane. They discuss the various control plane, and a hybrid control plane. They discuss the various
information exchanges between entities in the network in each of information exchanges between entities in the network in each of
these architectures and the advantages and disadvantages of each these architectures and the advantages and disadvantages of each
option. option.
In each of the following sections, examples are used to illustrate In each of the following sections, examples are used to illustrate
skipping to change at page 8, line 5 skipping to change at page 8, line 11
explicit route. After receiving the PATH message, the egress explicit route. After receiving the PATH message, the egress
edge node sends a RESV message with the distributed label and edge node sends a RESV message with the distributed label and
resource reservation request. resource reservation request.
There are many other variations that could be included in a hybrid There are many other variations that could be included in a hybrid
control plane. This document cannot discuss all the possible control control plane. This document cannot discuss all the possible control
plane mechanisms that could be used in hybrid configuration models. plane mechanisms that could be used in hybrid configuration models.
Every solution has its own mechanisms and corresponding parameters Every solution has its own mechanisms and corresponding parameters
that are required for it to work. that are required for it to work.
4. Control Plane for DetNet Domains 4. DetNet Control Plane Additional Details and Issues
This section discusses control plane issues that are unique to the This section discusses some additional DetNet control plane details
DetNet. and issues.
4.1. DetNet in a Traditional MPLS Domain 4.1. Explicit Paths
Explicit paths are required in DetNet to provide a stable transport
service and guarantee that DetNet service is not effected when the
network topology changes. The following features are necessary to
have explicit paths in DetNet:
o Path computation: DetNet explicit paths need to meet the SLA
(Service Level Agreement) requirements and/or resource guarantees
from the application/client, which include bandwidth, maximum end-
to-end delay, maximum end-to-end delay variation, maximum loss
ratio, etc. In an distributed system with IGP-TE, CSPF
(Constrained Shortest Path First) can be used to compute a set of
feasible paths for a DetNet service. In a system with a network
controller, a PCE (Path Computation Engine) can compute paths
satisfying the requirements of DetNet with the network information
collected from the DetNet domain.
o Path establishment: Once the path has been computed, the options
discussed in Section 3 can be used to establish the path. Also
see Section 4.4 and Section 4.6 for some additional considerations
depending on the details of the network infrastructure.
o Strict or loose paths: An explicit path is strict when every
intermediate hop is specified so that its route can't change. An
explicit path is loose when any IGP route is allowed along the
path. Generally, end-to-end SLA guarantees require a strict
explicit path in DetNet. However, when the IGP route is known to
be able to meet the SLA requirements, loose explicit paths are
also acceptable.
4.2. Resource Reservation
Network congestion could cause uncontrolled delay and/or packet loss.
DetNet flows are supposed to be protected from congestion, so
sufficient resource reservation for DetNet service is necessary.
Resources in the network are complex and hard to quantize, and may
include such entities as packet processing resources, packet
buffering, port and link bandwidth, and so on. The resources a
particular flow requires are determined by the flow's characteristics
and SLA.
o Resource Allocation: Port bandwidth is one of the basic attributes
of a network device which is easy to obtain or calculate. In
current traffic engineering implementations, network resource
allocation is synonymous with bandwidth allocation. A DetNet flow
is characterized with a traffic specification as defined in
[I-D.ietf-detnet-flow-information-model], including attributes
such as Interval, Maximum Packets Per Interval, and Maximum
Payload Size. The traffic specification describes the worst case,
rather than the average case, for the traffic, to ensure that
sufficient bandwidth and buffering resources are reserved to
satisfy the traffic specification.
o Device configuration with or without flow discrimination: The
resource allocation can be guaranteed by device configuration.
For example, an output port bandwidth reservation can be
configured as a parameter of queue management and the port
scheduling algorithm. When DetNet flows are aggregated, a group
of DetNet flows share the allocated resource in the network
device. When the DetNet flows are treated independently, the
device should maintains a mapping relationship between a DetNet
flow and its corresponding resources.
4.3. PREOF Support
DetNet path redundancy is supported via packet replication and
duplicate elimination (PREOF). A DetNet flow is replicated and goes
through multiple networks paths to avoid packet loss caused by device
or link failures. In general, current control plane mechanisms that
can be used to establish an explicit path, whether distributed or
centralized, support point-to-point (P2P) and point-to-multipoint
(P2MP) path establishment. PREOF requires the ability to compute and
establish a point-to-multipoint-to-point (P2MP2P) path. Protocol
extensions will be required to support this new feature.
4.4. DetNet in a Traditional MPLS Domain
For the purposes of this document, "traditional MPLS" is defined as For the purposes of this document, "traditional MPLS" is defined as
MPLS without the use of segment routing (see Section 4.3 for a MPLS without the use of segment routing (see Section 4.6 for a
discussion of MPLS with segment routing) or MPLS-TP [RFC5960]. discussion of MPLS with segment routing) or MPLS-TP [RFC5960].
In traditional MPLS domains, a dynamic control plane using In traditional MPLS domains, a dynamic control plane using
distributed signaling protocols is typically used for the distributed signaling protocols is typically used for the
distribution of MPLS labels used for forwarding MPLS packets. The distribution of MPLS labels used for forwarding MPLS packets. The
dynamic signaling protocols most commonly used for label distribution dynamic signaling protocols most commonly used for label distribution
are LDP [RFC5036], RSVP-TE, and BGP [RFC8277] (which enables BGP/ are LDP [RFC5036], RSVP-TE, and BGP [RFC8277] (which enables BGP/
MPLS-based Layer 3 VPNs [RFC4384] and Layer 2 VPNs [RFC7432]). MPLS-based Layer 3 VPNs [RFC4384] and Layer 2 VPNs [RFC7432]).
Any of these protocols could be used to distribute DetNet Service Any of these protocols could be used to distribute DetNet Service
skipping to change at page 9, line 5 skipping to change at page 10, line 35
PCEP, particularly when used as a part of PCE-CC, is a possible PCEP, particularly when used as a part of PCE-CC, is a possible
candidate protocol to use for centralized management of traditional candidate protocol to use for centralized management of traditional
MPLS-based DetNet domains. However, PCE path calculation algorithms MPLS-based DetNet domains. However, PCE path calculation algorithms
would need to be extended to include the location determination for would need to be extended to include the location determination for
PREOF nodes in a path, and the means to signal the necessary resource PREOF nodes in a path, and the means to signal the necessary resource
reservation and PREOF function placement information to network reservation and PREOF function placement information to network
nodes. See ((?I-D.ietf-pce-pcep-extension-for-pce-controller)) for nodes. See ((?I-D.ietf-pce-pcep-extension-for-pce-controller)) for
further discussion of PCE-CC and PCEP for centralized control of an further discussion of PCE-CC and PCEP for centralized control of an
MPLS domain. MPLS domain.
4.2. IP 4.5. IP
In a later revision of this document, this section will discuss In a later revision of this document, this section will discuss
necessary protocol extensions to existing IP routing protocols such necessary protocol extensions to existing IP routing protocols such
as IS-IS and BGP. It should be noted that a DetNet IP domain is as IS-IS and BGP. It should be noted that a DetNet IP domain is
simpler than a DetNet MPLS domain, and doesn't support PREOF, so only simpler than a DetNet MPLS domain, and doesn't support PREOF, so only
one path per flow or flow aggregate is required, with no path one path per flow or flow aggregate is required, with no path
merging. merging.
4.3. DetNet with Segment Routing (SR) 4.6. DetNet with Segment Routing (SR)
Segment Routing [RFC8402] is a scalable approach to building network Segment Routing [RFC8402] is a scalable approach to building network
domains that utilizes a combination of source routing in packet domains that utilizes a combination of source routing in packet
headers and centralized network control to compute paths through the headers and centralized network control to compute paths through the
network and distribute those paths with associated policy to network network and distribute those paths with associated policy to network
edge nodes for use in packet headers. It greatly reduces the amount edge nodes for use in packet headers. It greatly reduces the amount
of network signaling associated with distributed signaling protocols of network signaling associated with distributed signaling protocols
such as RSVP-TE, and also greatly reduces the amount of state in core such as RSVP-TE, and also greatly reduces the amount of state in core
nodes compared with that required for traditional MPLS and IP nodes compared with that required for traditional MPLS and IP
routing, as the state is now in the packets rather than in the routing, as the state is now in the packets rather than in the
skipping to change at page 10, line 24 skipping to change at page 12, line 8
for the usual link state flooding in order to establish adjacencies, for the usual link state flooding in order to establish adjacencies,
but not for DetNet flow path calculations, only for best effort but not for DetNet flow path calculations, only for best effort
traffic as usual. traffic as usual.
A similar approach for network slicing that could be leveraged for A similar approach for network slicing that could be leveraged for
DetNet is described in [I-D.dong-spring-sr-for-enhanced-vpn]. DetNet is described in [I-D.dong-spring-sr-for-enhanced-vpn].
Also, note that SR cannot currently support DetNet PREOF Also, note that SR cannot currently support DetNet PREOF
functionality without extensions. One possible approach could be to functionality without extensions. One possible approach could be to
combine SR with BIER-TE, as discussed in [I-D.ietf-bier-te-arch]. combine SR with BIER-TE, as discussed in [I-D.ietf-bier-te-arch].
Another possible approach specific to SRv6 is discussed in
[I-D.geng-detnet-dp-sol-srv6].
5. Management Plane Overview 5. Management Plane Overview
The Management Plane includes the ability to statically provision The Management Plane includes the ability to statically provision
network nodes and to use OAM to monitor DetNet performance and detect network nodes and to use OAM to monitor DetNet performance and detect
outages or other issues at the DetNet layer. outages or other issues at the DetNet layer.
5.1. Provisioning 5.1. Provisioning
Static provisioning in a Detnet network will be performed via the use Static provisioning in a Detnet network will be performed via the use
skipping to change at page 12, line 27 skipping to change at page 14, line 17
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-13 (work in progress), May 2019. detnet-architecture-13 (work in progress), May 2019.
[I-D.ietf-detnet-data-plane-framework] [I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane Bryant, S., and J. Korhonen, "DetNet Data Plane
Framework", draft-ietf-detnet-data-plane-framework-01 Framework", draft-ietf-detnet-data-plane-framework-01
(work in progress), July 2019. (work in progress), July 2019.
[I-D.ietf-detnet-flow-information-model]
Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet
Flow Information Model", draft-ietf-detnet-flow-
information-model-03 (work in progress), March 2019.
[I-D.ietf-detnet-ip] [I-D.ietf-detnet-ip]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", Bryant, S., and J. Korhonen, "DetNet Data Plane: IP",
draft-ietf-detnet-ip-01 (work in progress), July 2019. draft-ietf-detnet-ip-01 (work in progress), July 2019.
[I-D.ietf-detnet-mpls] [I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
draft-ietf-detnet-mpls-01 (work in progress), July 2019. draft-ietf-detnet-mpls-01 (work in progress), July 2019.
skipping to change at page 13, line 44 skipping to change at page 15, line 34
Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., and Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., and
Z. Li, "Segment Routing for Enhanced VPN Service", draft- Z. Li, "Segment Routing for Enhanced VPN Service", draft-
dong-spring-sr-for-enhanced-vpn-04 (work in progress), dong-spring-sr-for-enhanced-vpn-04 (work in progress),
July 2019. July 2019.
[I-D.finn-detnet-bounded-latency] [I-D.finn-detnet-bounded-latency]
Finn, N., Boudec, J., Mohammadpour, E., Zhang, J., Varga, Finn, N., Boudec, J., Mohammadpour, E., Zhang, J., Varga,
B., and J. Farkas, "DetNet Bounded Latency", draft-finn- B., and J. Farkas, "DetNet Bounded Latency", draft-finn-
detnet-bounded-latency-04 (work in progress), June 2019. detnet-bounded-latency-04 (work in progress), June 2019.
[I-D.geng-detnet-dp-sol-srv6]
Geng, X., Chen, M., and Y. Zhu, "DetNet SRv6 Data Plane
Encapsulation", draft-geng-detnet-dp-sol-srv6-01 (work in
progress), July 2019.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
Routing Header (SRH)", draft-ietf-6man-segment-routing- Routing Header (SRH)", draft-ietf-6man-segment-routing-
header-21 (work in progress), June 2019. header-21 (work in progress), June 2019.
[I-D.ietf-bier-te-arch] [I-D.ietf-bier-te-arch]
Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic
Engineering for Bit Index Explicit Replication (BIER-TE)", Engineering for Bit Index Explicit Replication (BIER-TE)",
draft-ietf-bier-te-arch-02 (work in progress), May 2019. draft-ietf-bier-te-arch-02 (work in progress), May 2019.
skipping to change at page 17, line 11 skipping to change at page 19, line 5
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>. <https://www.rfc-editor.org/info/rfc8277>.
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and the PCE Communication Architecture for Use of PCE and the PCE Communication
Protocol (PCEP) in a Network with Central Control", Protocol (PCEP) in a Network with Central Control",
RFC 8283, DOI 10.17487/RFC8283, December 2017, RFC 8283, DOI 10.17487/RFC8283, December 2017,
<https://www.rfc-editor.org/info/rfc8283>. <https://www.rfc-editor.org/info/rfc8283>.
Author's Address Authors' Addresses
Andrew G. Malis Andrew G. Malis
Futurewei Technologies Futurewei Technologies
Email: agmalis@gmail.com Email: agmalis@gmail.com
Xuesong Geng
Huawei
Email: gengxuesong@huawei.com
Mach (Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
Fengwei Qin
China Mobile
Email: qinfengwei@chinamobile.com
 End of changes. 17 change blocks. 
31 lines changed or deleted 131 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/