draft-ietf-roll-rpl-observations-06.txt		draft-ietf-roll-rpl-observations-07.txt
	ROLL R. Jadhav, Ed.		ROLL R.A. Jadhav, Ed.
	Internet-Draft		Internet-Draft
	Intended status: Standards Track R. Sahoo		Intended status: Standards Track R.N. Sahoo
	Expires: December 5, 2021 Juniper		Expires: 2 June 2022 Juniper
	Y. Wu		Y. Wu
	Huawei		Huawei
	June 3, 2021		29 November 2021
	RPL Observations		RPL Observations
	draft-ietf-roll-rpl-observations-06		draft-ietf-roll-rpl-observations-07
	Abstract		Abstract
	This document describes RPL protocol design issues, various		This document describes RPL protocol design issues, various
	observations and possible consequences of the design and		observations and possible consequences of the design and
	implementation choices.		implementation choices.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 December 5, 2021.		This Internet-Draft will expire on 2 June 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Requirements Language and Terminology . . . . . . . . . . 3		2.1. Requirements Language and Terminology . . . . . . . . . . 3
	3. DTSN increment in storing MOP . . . . . . . . . . . . . . . . 4		3. DTSN increment in storing MOP . . . . . . . . . . . . . . . . 4
	3.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 5
	4. DAO retransmission and use of DAO-ACK in storing MOP . . . . 5		4. DAO retransmission and use of DAO-ACK in storing MOP . . . . 5
	4.1. Significance of bidirectional Path establishment		4.1. Significance of bidirectional Path establishment indication
	indication and relevance of DAO-ACK . . . . . . . . . . . 6		and relevance of DAO-ACK . . . . . . . . . . . . . . . . 6
	4.2. Problems with hop-by-hop DAO-ACK . . . . . . . . . . . . 6		4.2. Problems with hop-by-hop DAO-ACK . . . . . . . . . . . . 6
	4.3. Problems with end-to-end DAO-ACK . . . . . . . . . . . . 6		4.3. Problems with end-to-end DAO-ACK . . . . . . . . . . . . 6
	4.4. Deliberations . . . . . . . . . . . . . . . . . . . . . . 6		4.4. Deliberations . . . . . . . . . . . . . . . . . . . . . . 6
	4.5. Implementation Notes . . . . . . . . . . . . . . . . . . 7		4.5. Implementation Notes . . . . . . . . . . . . . . . . . . 7
	5. Interpreting Trickle Timer . . . . . . . . . . . . . . . . . 7		5. Interpreting Trickle Timer . . . . . . . . . . . . . . . . . 7
	6. Handling resource unavailability . . . . . . . . . . . . . . 8		6. Handling resource unavailability . . . . . . . . . . . . . . 8
	6.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8		6.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8
	7. Handling aggregated targets . . . . . . . . . . . . . . . . . 9		7. Handling aggregated targets . . . . . . . . . . . . . . . . . 9
	7.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 9		7.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 9
	8. RPL Transit Information in DAO . . . . . . . . . . . . . . . 9		8. RPL Transit Information in DAO . . . . . . . . . . . . . . . 9
	8.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 10		8.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 10
	9. Upgrades or Extensions to RPL protocol . . . . . . . . . . . 10		9. Upgrades or Extensions to RPL protocol . . . . . . . . . . . 10
	10. Path Control bits handling . . . . . . . . . . . . . . . . . 10		10. Path Control bits handling . . . . . . . . . . . . . . . . . 10
	11. Asymmetric Links and RPL . . . . . . . . . . . . . . . . . . 11		11. Asymmetric Links and RPL . . . . . . . . . . . . . . . . . . 11
	12. Adjacencies probing with RPL . . . . . . . . . . . . . . . . 11		12. Adjacencies probing with RPL . . . . . . . . . . . . . . . . 12
	12.1. Deliberations . . . . . . . . . . . . . . . . . . . . . 12		12.1. Deliberations . . . . . . . . . . . . . . . . . . . . . 12
	13. Control Options eliding mechanism in RPL . . . . . . . . . . 12		13. Control Options eliding mechanism in RPL . . . . . . . . . . 12
	14. Managing persistent variables across node reboots . . . . . . 12		14. Managing persistent variables across node reboots . . . . . . 12
	14.1. Persistent storage and RPL state information . . . . . . 12		14.1. Persistent storage and RPL state information . . . . . . 13
	14.2. Lollipop Counters . . . . . . . . . . . . . . . . . . . 13		14.2. Lollipop Counters . . . . . . . . . . . . . . . . . . . 13
	14.3. RPL State variables . . . . . . . . . . . . . . . . . . 14		14.3. RPL State variables . . . . . . . . . . . . . . . . . . 14
	14.3.1. DODAG Version . . . . . . . . . . . . . . . . . . . 14		14.3.1. DODAG Version . . . . . . . . . . . . . . . . . . . 15
	14.3.2. DTSN field in DIO . . . . . . . . . . . . . . . . . 14		14.3.2. DTSN field in DIO . . . . . . . . . . . . . . . . . 15
	14.3.3. PathSequence . . . . . . . . . . . . . . . . . . . . 15		14.3.3. PathSequence . . . . . . . . . . . . . . . . . . . . 15
	14.4. State variables update frequency . . . . . . . . . . . . 15		14.4. State variables update frequency . . . . . . . . . . . . 16
	14.5. Deliberations . . . . . . . . . . . . . . . . . . . . . 15		14.5. Deliberations . . . . . . . . . . . . . . . . . . . . . 16
	14.6. Implementation Notes . . . . . . . . . . . . . . . . . . 16		14.6. Implementation Notes . . . . . . . . . . . . . . . . . . 16
	15. Capabilities and its role in RPL . . . . . . . . . . . . . . 16		15. Capabilities and its role in RPL . . . . . . . . . . . . . . 17
	15.1. Handshaking node capabilities . . . . . . . . . . . . . 16		15.1. Handshaking node capabilities . . . . . . . . . . . . . 17
	15.2. How do Capabilities differ from MOP and Configuration		15.2. How do Capabilities differ from MOP and Configuration
	Option? . . . . . . . . . . . . . . . . . . . . . . . . 17		Option? . . . . . . . . . . . . . . . . . . . . . . . . 17
	15.3. Deliberations . . . . . . . . . . . . . . . . . . . . . 17		15.3. Deliberations . . . . . . . . . . . . . . . . . . . . . 17
	16. Backward Compatibility issues with RPL Options . . . . . . . 17		16. Backward Compatibility issues with RPL Options . . . . . . . 18
	17. RPL under-specification . . . . . . . . . . . . . . . . . . . 17		17. RPL under-specification . . . . . . . . . . . . . . . . . . . 18
	18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	20. Security Considerations . . . . . . . . . . . . . . . . . . . 18		20. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	21. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		21. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	21.1. Normative References . . . . . . . . . . . . . . . . . . 18		21.1. Normative References . . . . . . . . . . . . . . . . . . 19
	21.2. Informative References . . . . . . . . . . . . . . . . . 19		21.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 19		Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Motivation		1. Motivation
	The primary motivation for this draft is to enlist different issues		The primary motivation for this draft is to enlist different issues
	with RPL operation and invoke a discussion within the working group.		with RPL operation and invoke a discussion within the working group.
	This draft by itself is not intended for RFC tracks but as a WG		This draft by itself is not intended for RFC tracks but as a WG
	discussion track. This draft may in turn result in other work items		discussion track. This draft may in turn result in other work items
	taken up by the WG which may improvise on the issues mentioned		taken up by the WG which may improvise on the issues mentioned
	herewith.		herewith.
	skipping to change at page 5, line 49 ¶		skipping to change at page 5, line 47 ¶
	upstream. In other words, the parent node accepts the		upstream. In other words, the parent node accepts the
	responsibilty of sending the DAO upstream till the point it is		responsibilty of sending the DAO upstream till the point it is
	ACKed the moment it responds back with its own ACK to the child.		ACKed the moment it responds back with its own ACK to the child.
	1-> 3->		1-> 3->
	DAO DAO		DAO DAO
	(TgtNode)--------(6LR)-------(root)		(TgtNode)--------(6LR)-------(root)
	ACK ACK		ACK ACK
	<-2 <-4		<-2 <-4
	Figure 2: Hop-by-hop DAO-ACK		Figure 2: Hop-by-hop DAO-ACK
	1-> 2->		1-> 2->
	DAO DAO		DAO DAO
	(TgtNode)--------(6LR)-------(root)		(TgtNode)--------(6LR)-------(root)
	ACK ACK		ACK ACK
	<-4 <-3		<-4 <-3
	Figure 3: End-to-End DAO-ACK		Figure 3: End-to-End DAO-ACK
	4.1. Significance of bidirectional Path establishment indication and		4.1. Significance of bidirectional Path establishment indication and
	relevance of DAO-ACK		relevance of DAO-ACK
	Lot of application traffic patterns requires that the bidirectional		Lot of application traffic patterns requires that the bidirectional
	path be established between the target node and the root. A typical		path be established between the target node and the root. A typical
	example is that COAP request with ACK bit set would require an		example is that COAP request with ACK bit set would require an
	acknowledgement from the end receiver and thus warrants bidirectional		acknowledgement from the end receiver and thus warrants bidirectional
	path establishment. It is imperative that the target node first		path establishment. It is imperative that the target node first
	ascertains whether such a bidirectional path is established before		ascertains whether such a bidirectional path is established before
	skipping to change at page 7, line 41 ¶		skipping to change at page 7, line 43 ¶
	Trickle algorithm defines a mechanism to reset the timer. Trickle		Trickle algorithm defines a mechanism to reset the timer. Trickle
	timer reset is unlike regular periodic timers wherein the timer is		timer reset is unlike regular periodic timers wherein the timer is
	simply reset to start again. Reset of trickle timer implies		simply reset to start again. Reset of trickle timer implies
	resetting the trickle back to Imin and starting with a new interval		resetting the trickle back to Imin and starting with a new interval
	as mentioned in Section 4.2 of [RFC6206].		as mentioned in Section 4.2 of [RFC6206].
	|----|--------|----------------|------------------------------| . . . .		|----|--------|----------------|------------------------------| . . . .
	Imin I2 I3 I4 I5		Imin I2 I3 I4 I5
	Figure 4: Trickle Timer Operation		Figure 4: Trickle Timer Operation
	The above figure shows an example of trickle intervals. An interval		The above figure shows an example of trickle intervals. An interval
	is double that of the previous interval size. Section 4.2. of		is double that of the previous interval size. Section 4.2. of
	[RFC6206] states that,		[RFC6206] states that,
	"If Trickle hears a transmission that is "inconsistent" and I is		"If Trickle hears a transmission that is "inconsistent" and I is
	greater than Imin, it resets the Trickle timer. To reset the timer,		greater than Imin, it resets the Trickle timer. To reset the timer,
	Trickle sets I to Imin and starts a new interval as in step 2. If I		Trickle sets I to Imin and starts a new interval as in step 2. If I
	is equal to Imin when Trickle hears an "inconsistent" transmission,		is equal to Imin when Trickle hears an "inconsistent" transmission,
	Trickle does nothing. Trickle can also reset its timer in response		Trickle does nothing. Trickle can also reset its timer in response
	skipping to change at page 14, line 5 ¶		skipping to change at page 14, line 11 ¶
	this seqcnt and node B uses this seqcnt to determine whether the		this seqcnt and node B uses this seqcnt to determine whether the
	information node A sent in the packet is latest. Now lets assume,		information node A sent in the packet is latest. Now lets assume,
	the counter value reaches 250 after some operations on Node A, and		the counter value reaches 250 after some operations on Node A, and
	node B keeps receiving updated seqcnt from node A. Now consider that		node B keeps receiving updated seqcnt from node A. Now consider that
	node A reboots, and since it reinitializes the seqcnt value to 240		node A reboots, and since it reinitializes the seqcnt value to 240
	and sends the information to node B (who has seqcnt of 250 stored on		and sends the information to node B (who has seqcnt of 250 stored on
	behalf of node A). As per section 7.2. of [RFC6550], when node B		behalf of node A). As per section 7.2. of [RFC6550], when node B
	receives this packet it will consider the information to be old		receives this packet it will consider the information to be old
	(since 240 < 250).		(since 240 < 250).
	+-----+-----+----------+		+=====+=====+==========+
	| A | B | Output |		| A | B | Output |
	+-----+-----+----------+		+=====+=====+==========+
	| 240 | 240 | A<B, old |		| 240 | 240 | A<B, old |
	| 240 | 241 | A<B, old |		+-----+-----+----------+
	| 240 | :: | A<B, old |		| 240 | 241 | A<B, old |
	| 240 | 256 | A<B, old |		+-----+-----+----------+
	| 240 | 0 | A<B, new |		| 240 | :: | A<B, old |
	| 240 | 1 | A>B, new |		+-----+-----+----------+
	| 240 | :: | A>B, new |		| 240 | 256 | A<B, old |
	| 240 | 127 | A>B, new |		+-----+-----+----------+
	+-----+-----+----------+		| 240 | 0 | A<B, new |
			+-----+-----+----------+
			| 240 | 1 | A>B, new |
			+-----+-----+----------+
			| 240 | :: | A>B, new |
			+-----+-----+----------+
			| 240 | 127 | A>B, new |
			+-----+-----+----------+
	Default values for lollipop counters considered from [RFC6550]		Table 1: Example
	Section 7.2.		lollipop counter
			operation
	Table 1: Example lollipop counter operation		Default values for lollipop counters considered from [RFC6550]
			Section 7.2.
	Based on this figure, there is dead zone (240 to 0) in which if A		Based on this figure, there is dead zone (240 to 0) in which if A
	operates after reboot then the seqcnt will always be considered		operates after reboot then the seqcnt will always be considered
	smaller. Thus node A needs to maintain the seqcnt in persistent		smaller. Thus node A needs to maintain the seqcnt in persistent
	storage and reuse this on reboot.		storage and reuse this on reboot.
	14.3. RPL State variables		14.3. RPL State variables
	The impact of loss of RPL state information differs depending upon		The impact of loss of RPL state information differs depending upon
	the node type (6LN/6LR/6LBR). Following sections explain different		the node type (6LN/6LR/6LBR). Following sections explain different
	skipping to change at page 15, line 30 ¶		skipping to change at page 16, line 7 ¶
	Target option. A node whichs owns a target address can associate a		Target option. A node whichs owns a target address can associate a
	PathSequence in the DAO message to denote freshness of the target		PathSequence in the DAO message to denote freshness of the target
	information. This is especially useful when a node uses multiple		information. This is especially useful when a node uses multiple
	paths or multiple parents to advertise its reachability.		paths or multiple parents to advertise its reachability.
	Loss of PathSequence information maintained on the target node can		Loss of PathSequence information maintained on the target node can
	result in routing adjacencies been lost on 6LRs/6LBR/6BBR.		result in routing adjacencies been lost on 6LRs/6LBR/6BBR.
	14.4. State variables update frequency		14.4. State variables update frequency
	+--------------------+-------------------+------------------------+		+====================+===================+========================+
	| State variable | Update frequency | Impacts node type |		| State variable | Update frequency | Impacts node type |
	+--------------------+-------------------+------------------------+		+====================+===================+========================+
	| DODAGVersionNumber | Low | 6LBR, 6LR(local DODAG) |		| DODAGVersionNumber | Low | 6LBR, 6LR(local DODAG) |
			+--------------------+-------------------+------------------------+
	| DTSN | High(SM),Low(NSM) | 6LBR, 6LR |		| DTSN | High(SM),Low(NSM) | 6LBR, 6LR |
			+--------------------+-------------------+------------------------+
	| PathSequence | High(SM),Low(NSM) | 6LR, 6LN |		| PathSequence | High(SM),Low(NSM) | 6LR, 6LN |
	+--------------------+-------------------+------------------------+		+--------------------+-------------------+------------------------+
	Low=<5 per day, High=>5 per day; SM=Storing MOP, NSM=Non-Storing MOP		Table 2: RPL State variables
	Table 2: RPL State variables		Low=<5 per day, High=>5 per day; SM=Storing MOP, NSM=Non-Storing MOP
	14.5. Deliberations		14.5. Deliberations
	(1) Is it possible that RPL removes the use of persistent storage		(1) Is it possible that RPL removes the use of persistent storage
	for maintaining state information?		for maintaining state information?
	(2) In most cases, the node reboots will happen very rarely. Thus		(2) In most cases, the node reboots will happen very rarely. Thus
	doing a persistent storage book-keeping for handling node reboot		doing a persistent storage book-keeping for handling node reboot
	might not make sense. Is it possible to consider signaling		might not make sense. Is it possible to consider signaling
	(especially after the node reboots) so as to avoid maintaining		(especially after the node reboots) so as to avoid maintaining
	skipping to change at page 19, line 16 ¶		skipping to change at page 19, line 45 ¶
	Bormann, "Neighbor Discovery Optimization for IPv6 over		Bormann, "Neighbor Discovery Optimization for IPv6 over
	Low-Power Wireless Personal Area Networks (6LoWPANs)",		Low-Power Wireless Personal Area Networks (6LoWPANs)",
	RFC 6775, DOI 10.17487/RFC6775, November 2012,		RFC 6775, DOI 10.17487/RFC6775, November 2012,
	<https://www.rfc-editor.org/info/rfc6775>.		<https://www.rfc-editor.org/info/rfc6775>.
	21.2. Informative References		21.2. Informative References
	[I-D.clausen-lln-rpl-experiences]		[I-D.clausen-lln-rpl-experiences]
	Clausen, T., Verdiere, A. C. D., Yi, J., Herberg, U., and		Clausen, T., Verdiere, A. C. D., Yi, J., Herberg, U., and
	Y. Igarashi, "Observations on RPL: IPv6 Routing Protocol		Y. Igarashi, "Observations on RPL: IPv6 Routing Protocol
	for Low power and Lossy Networks", draft-clausen-lln-rpl-		for Low power and Lossy Networks", Work in Progress,
	experiences-11 (work in progress), March 2018.		Internet-Draft, draft-clausen-lln-rpl-experiences-11, 27
			March 2018, <https://www.ietf.org/archive/id/draft-
			clausen-lln-rpl-experiences-11.txt>.
	[I-D.ietf-intarea-adhoc-wireless-com]		[I-D.ietf-intarea-adhoc-wireless-com]
	Baccelli, E. and C. E. Perkins, "Multi-hop Ad Hoc Wireless		Baccelli, E. and C. E. Perkins, "Multi-hop Ad Hoc Wireless
	Communication", draft-ietf-intarea-adhoc-wireless-com-02		Communication", Work in Progress, Internet-Draft, draft-
	(work in progress), July 2016.		ietf-intarea-adhoc-wireless-com-02, 20 July 2016,
			<https://www.ietf.org/archive/id/draft-ietf-intarea-adhoc-
			wireless-com-02.txt>.
	[I-D.ietf-roll-aodv-rpl]		[I-D.ietf-roll-aodv-rpl]
	Anamalamudi, S., Zhang, M., Perkins, C. E., Anand, S., and		Anamalamudi, S., Perkins, C. E., Anand, S., and B. Liu,
	B. Liu, "Supporting Asymmetric Links in Low Power		"Supporting Asymmetric Links in Low Power Networks: AODV-
	Networks: AODV-RPL", draft-ietf-roll-aodv-rpl-10 (work in		RPL", Work in Progress, Internet-Draft, draft-ietf-roll-
	progress), April 2021.		aodv-rpl-11, 16 September 2021,
			<https://www.ietf.org/archive/id/draft-ietf-roll-aodv-rpl-
			11.txt>.
	[Perlman83]		[Perlman83]
	Perlman, R., "Fault-Tolerant Broadcast of Routing		Perlman, R., "Fault-Tolerant Broadcast of Routing
	Information", North-Holland Computer Networks, Vol.7,		Information", North-Holland Computer Networks, Vol.7,
	December 1983.		December 1983.
	Appendix A. Additional Stuff		Appendix A. Additional Stuff
	Authors' Addresses		Authors' Addresses
	Rahul Arvind Jadhav (editor)		Rahul Arvind Jadhav (editor)
	Marathahalli		Marathahalli
	Bangalore, Karnataka 560037		Bangalore 560037
			Karnataka
	India		India
	Email: rahul.ietf@gmail.com		Email: rahul.ietf@gmail.com
	Rabi Narayan Sahoo		Rabi Narayan Sahoo
	Juniper		Juniper
	Whitefield		Whitefield
	Bangalore, Karnataka 560037		Bangalore 560037
			Karnataka
	India		India
	Email: rabinarayans0828@gmail.com		Email: rabinarayans0828@gmail.com
	Yuefeng Wu		Yuefeng Wu
	Huawei		Huawei
	No.101, Software Avenue, Yuhuatai District,		No.101, Software Avenue, Yuhuatai District,
	Nanjing, Jiangsu 210012		Nanjing
			Jiangsu, 210012
	China		China
	Phone: +86-15251896569		Phone: +86-15251896569
	Email: wuyuefeng@huawei.com		Email: wuyuefeng@huawei.com
End of changes. 34 change blocks.
	65 lines changed or deleted		85 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/