draft-ietf-mpls-residence-time-06.txt		draft-ietf-mpls-residence-time-07.txt
	MPLS Working Group G. Mirsky		MPLS Working Group G. Mirsky
	Internet-Draft S. Ruffini		Internet-Draft S. Ruffini
	Intended status: Standards Track E. Gray		Intended status: Standards Track E. Gray
	Expires: September 19, 2016 Ericsson		Expires: October 9, 2016 Ericsson
	J. Drake		J. Drake
	Juniper Networks		Juniper Networks
	S. Bryant		S. Bryant
	Cisco Systems		Cisco Systems
	A. Vainshtein		A. Vainshtein
	ECI Telecom		ECI Telecom
	March 18, 2016		April 7, 2016
	Residence Time Measurement in MPLS network		Residence Time Measurement in MPLS network
	draft-ietf-mpls-residence-time-06		draft-ietf-mpls-residence-time-07
	Abstract		Abstract
	This document specifies G-ACh based Residence Time Measurement and		This document specifies G-ACh based Residence Time Measurement and
	how it can be used by time synchronization protocols being		how it can be used by time synchronization protocols being
	transported over MPLS domain.		transported over MPLS domain.
	Residence time is the variable part of propagation delay of timing		Residence time is the variable part of propagation delay of timing
	and synchronization messages and knowing what this delay is for each		and synchronization messages and knowing what this delay is for each
	message allows for a more accurate determination of the delay to be		message allows for a more accurate determination of the delay to be
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 19, 2016.		This Internet-Draft will expire on October 9, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 38 ¶		skipping to change at page 2, line 38 ¶
	3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 6		3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 6
	4. Control Plane Theory of Operation . . . . . . . . . . . . . . 7		4. Control Plane Theory of Operation . . . . . . . . . . . . . . 7
	4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7		4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7
	4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8		4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8
	4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9		4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9
	4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9		4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9
	4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 9		4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 9
	4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10		4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10
	4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11		4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11
	4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 13		4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 13
	5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 15		5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 16
	6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 16		6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 16
	7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 16		7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19		8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19
	8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19		8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19
	8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20		8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20
	8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20		8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20
	8.5. RTM Capability sub-TLV in OSPFv3 . . . . . . . . . . . . 20		8.5. RTM Capability sub-TLV in OSPFv3 . . . . . . . . . . . . 21
	8.6. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21		8.6. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21
	8.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21		8.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21
	8.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22		8.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22
	8.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 22		8.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 23
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 22		9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	11.1. Normative References . . . . . . . . . . . . . . . . . . 23		11.1. Normative References . . . . . . . . . . . . . . . . . . 24
	11.2. Informative References . . . . . . . . . . . . . . . . . 24		11.2. Informative References . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	Time synchronization protocols, e.g., Network Time Protocol version 4		Time synchronization protocols, e.g., Network Time Protocol version 4
	(NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2		(NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2
	[IEEE.1588.2008] define timing messages that can be used to		[IEEE.1588.2014] define timing messages that can be used to
	synchronize clocks across a network domain. Measurement of the		synchronize clocks across a network domain. Measurement of the
	cumulative time one of these timing messages spends transiting the		cumulative time one of these timing messages spends transiting the
	nodes on the path from ingress node to egress node is termed		nodes on the path from ingress node to egress node is termed
	Residence Time and it is used to improve the accuracy of clock		Residence Time and it is used to improve the accuracy of clock
	synchronization. (I.e., it is the sum of the difference between the		synchronization. (I.e., it is the sum of the difference between the
	time of receipt at an ingress interface and the time of transmission		time of receipt at an ingress interface and the time of transmission
	from an egress interface for each node along the path from ingress		from an egress interface for each node along the path from ingress
	node to egress node.) This document defines a new Generalized		node to egress node.) This document defines a new Generalized
	Associated Channel (G-ACh) value and an associated residence time		Associated Channel (G-ACh) value and an associated residence time
	measurement (RTM) packet that can be used in a Multi-Protocol Label		measurement (RTM) packet that can be used in a Multi-Protocol Label
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 32 ¶
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	2. Residence Time Measurement		2. Residence Time Measurement
	Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be		Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be
	used to measure one-way or two-way end-to-end propagation delay over		used to measure one-way or two-way end-to-end propagation delay over
	LSP or PW. But these measurements are insufficient for use in some		LSP or PW. But these measurements are insufficient for use in some
	applications, for example, time synchronization across a network as		applications, for example, time synchronization across a network as
	defined in the Precision Time Protocol (PTP). In PTPv2		defined in the Precision Time Protocol (PTP). In PTPv2
	[IEEE.1588.2008] residence times is accumulated in the		[IEEE.1588.2014] residence times is accumulated in the
	correctionField of the PTP event message, as defined in		correctionField of the PTP event message, as defined in
	[IEEE.1588.2008], or in the associated follow-up message (or		[IEEE.1588.2014], or in the associated follow-up message (or
	Delay_Resp message associated with the Delay_Req message) in case of		Delay_Resp message associated with the Delay_Req message) in case of
	two-step clocks (see the detailed discussion in Section 7).		two-step clocks (see the detailed discussion in Section 7).
	IEEE 1588 uses this residence time to correct the transit time from		IEEE 1588 uses this residence time to correct the transit time from
	ingress node to egress node, effectively making the transit nodes		ingress node to egress node, effectively making the transit nodes
	transparent.		transparent.
	This document proposes a mechanism that can be used as one of types		This document proposes a mechanism that can be used as one of types
	of on-path support for a clock synchronization protocol or to perform		of on-path support for a clock synchronization protocol or to perform
	one-way measurement of residence time. The proposed mechanism		one-way measurement of residence time. The proposed mechanism
	skipping to change at page 6, line 9 ¶		skipping to change at page 6, line 9 ¶
	field with its residence time measurement. Its format is IEEE		field with its residence time measurement. Its format is IEEE
	double precision and its units are nanoseconds. Note that		double precision and its units are nanoseconds. Note that
	depending on whether the timing procedure is one-step or two-step		depending on whether the timing procedure is one-step or two-step
	operation (Section 7), the residence time is either for the timing		operation (Section 7), the residence time is either for the timing
	packet carried in the Value field of this RTM packet or for an		packet carried in the Value field of this RTM packet or for an
	associated timing packet carried in the Value field of another RTM		associated timing packet carried in the Value field of another RTM
	packet.		packet.
	o The Type field identifies the type and encapsulation of a timing		o The Type field identifies the type and encapsulation of a timing
	packet carried in the Value field, e.g., NTP [RFC5905] or PTP		packet carried in the Value field, e.g., NTP [RFC5905] or PTP
	[IEEE.1588.2008]. IANA will be asked to create a sub-registry in		[IEEE.1588.2014]. IANA will be asked to create a sub-registry in
	Generic Associated Channel (G-ACh) Parameters Registry called		Generic Associated Channel (G-ACh) Parameters Registry called
	"MPLS RTM TLV Registry".		"MPLS RTM TLV Registry".
	o The Length field contains the length, in octets , of the of the		o The Length field contains the length, in octets , of the of the
	timing packet carried in the Value field.		timing packet carried in the Value field.
	o The optional Value field MAY carry a packet of the time		o The optional Value field MAY carry a packet of the time
	synchronization protocol identified by Type field. It is		synchronization protocol identified by Type field. It is
	important to note that the packet may be authenticated or		important to note that the packet may be authenticated or
	encrypted and carried over LSP edge to edge unchanged while the		encrypted and carried over LSP edge to edge unchanged while the
	skipping to change at page 7, line 13 ¶		skipping to change at page 7, line 13 ¶
	where Flags field has format		where Flags field has format
	0 1 2		0 1 2
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S| Reserved |		|S| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Flags field format of PTP Packet Sub-TLV		Figure 3: Flags field format of PTP Packet Sub-TLV
	o The Type field identifies PTP sub-TLV defined in the Table 19		o The Type field identifies PTP sub-TLV defined in the Table 19
	Values of messageType field in [IEEE.1588.2008].		Values of messageType field in [IEEE.1588.2014].
	o The Length field of the PTP sub-TLV contains the number of octets		o The Length field of the PTP sub-TLV contains the number of octets
	of the Value field and MUST be 20.		of the Value field and MUST be 20.
	o The Flags field currently defines one bit, the S-bit, that defines		o The Flags field currently defines one bit, the S-bit, that defines
	whether the current message has been processed by a 2-step node,		whether the current message has been processed by a 2-step node,
	where the flag is cleared if the message has been handled		where the flag is cleared if the message has been handled
	exclusively by 1-step nodes and there is no follow-up message, and		exclusively by 1-step nodes and there is no follow-up message, and
	set if there has been at least one 2-step node and a follow-up		set if there has been at least one 2-step node and a follow-up
	message is forthcoming.		message is forthcoming.
	o The PTPType indicates the type of PTP packet carried in the TLV.		o The PTPType indicates the type of PTP packet carried in the TLV.
	PTPType is the messageType field of the PTPv2 packet whose values		PTPType is the messageType field of the PTPv2 packet whose values
	are defined in the Table 19 [IEEE.1588.2008].		are defined in the Table 19 [IEEE.1588.2014].
	o The 10 octets long Port ID field contains the identity of the		o The 10 octets long Port ID field contains the identity of the
	source port.		source port.
	o The Sequence ID is the sequence ID of the PTP message carried in		o The Sequence ID is the sequence ID of the PTP message carried in
	the Value field of the message.		the Value field of the message.
	4. Control Plane Theory of Operation		4. Control Plane Theory of Operation
	The operation of RTM depends upon TTL expiry to deliver an RTM packet		The operation of RTM depends upon TTL expiry to deliver an RTM packet
	skipping to change at page 12, line 8 ¶		skipping to change at page 12, line 8 ¶
	4.7. RTM_SET TLV		4.7. RTM_SET TLV
	RTM capable interfaces can be recorded via RTM_SET TLV. The RTM_SET		RTM capable interfaces can be recorded via RTM_SET TLV. The RTM_SET
	sub-object format is of generic Type, Length, Value (TLV), presented		sub-object format is of generic Type, Length, Value (TLV), presented
	in Figure 6 .		in Figure 6 .
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved |		| Type | Length |I| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Value ~		~ Value ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: RTM_SET TLV format		Figure 6: RTM_SET TLV format
	Type value (TBA5) will be assigned by IANA from its Attributes TLV		Type value (TBA5) will be assigned by IANA from its Attributes TLV
	Space sub-registry.		Space sub-registry.
	The Length contains the total length of the sub-object in bytes,		The Length contains the total length of the sub-object in bytes,
	including the Type and Length fields.		including the Type and Length fields.
			The I flag MUST be set to 0 if the node identified in the Value field
			was able to find downstream RTM node and calculate distance to it.
			If the node failed to find the downstream RTM node, then the I flag
			MUST be set to 1.
	Reserved field must be zeroed on initiation and ignored on receipt.		Reserved field must be zeroed on initiation and ignored on receipt.
	The content of an RTM_SET TLV is a series of variable-length sub-		The content of an RTM_SET TLV is a series of variable-length sub-
	TLVs. Only a single RTM_SET can be present in the LSP_ATTRIBUTES		TLVs. Only a single RTM_SET can be present in the LSP_ATTRIBUTES
	object. The sub-TLVs are defined in Section 4.7.1 below.		object. The sub-TLVs are defined in Section 4.7.1 below.
	The following processing procedures apply to every RTM capable node		The following processing procedures apply to every RTM capable node
	along the LSP that in this paragraph is referred as node for sake of		along the LSP that in this paragraph is referred as node for sake of
	brevity. Each node MUST examine Resv message whether RTM_SET		brevity. Each node MUST examine Resv message whether RTM_SET
	Attribute Flag in the LSP_ATTRIBUTES object is set. If the RTM_SET		Attribute Flag in the LSP_ATTRIBUTES object is set. If the RTM_SET
	skipping to change at page 12, line 49 ¶		skipping to change at page 13, line 5 ¶
	been found the node will use the ID of the first node in the RTM_SET		been found the node will use the ID of the first node in the RTM_SET
	in conjunction with the RRO to compute the hop count to its		in conjunction with the RRO to compute the hop count to its
	downstream node with reachable RTM capable interface. If the node		downstream node with reachable RTM capable interface. If the node
	cannot find matching ID in RRO, then it MUST try to use ID of the		cannot find matching ID in RRO, then it MUST try to use ID of the
	next node in the RTM_SET until it finds the match or reaches the end		next node in the RTM_SET until it finds the match or reaches the end
	of RTM_SET TLV. If match have been found, then the calculated value		of RTM_SET TLV. If match have been found, then the calculated value
	is used by the node as TTL value in outgoing label to reach the next		is used by the node as TTL value in outgoing label to reach the next
	RTM capable node on the LSP. Otherwise, the TTL value MUST be set to		RTM capable node on the LSP. Otherwise, the TTL value MUST be set to
	255. The node MUST add RTM_SET sub-TLV with the same address it used		255. The node MUST add RTM_SET sub-TLV with the same address it used
	in RRO sub-object at the beginning of the RTM_SET TLV in associated		in RRO sub-object at the beginning of the RTM_SET TLV in associated
	outgoing Resv message before forwarding it upstream.		outgoing Resv message before forwarding it upstream. If the
			calculated TTL value been set to 255, as described above, then the I
			field in node RTM_SET TLV MUST be set to 1 before Resv message
			forwarded upstream.
			The ingress node MAY inspect values of I field in the received Resv
			message that has RTM_SET Attribute Flag in the LSP_ATTRIBUTES object
			set. Presence of the RTM_SET TLV with I field set to 1 indicates
			that not all RTM nodes along the LSP could been included in the
			calculation of the residence time. Re-signaling of the path MAY be
			performed.
	There are scenarios when some information is removed from an RRO due		There are scenarios when some information is removed from an RRO due
	to policy processing (e.g., as may happen between providers) or RRO		to policy processing (e.g., as may happen between providers) or RRO
	is limited due to size constraints . Such changes affect the core		is limited due to size constraints . Such changes affect the core
	assumption of the method to control processing of RTM packets. RTM		assumption of the method to control processing of RTM packets. RTM
	SHOULD NOT be used if it is not guaranteed that RRO contains complete		SHOULD NOT be used if it is not guaranteed that RRO contains complete
	information.		information.
	4.7.1. RTM_SET Sub-TLVs		4.7.1. RTM_SET Sub-TLVs
	skipping to change at page 17, line 18 ¶		skipping to change at page 17, line 32 ¶
	message will be forthcoming (this is necessary in order to		message will be forthcoming (this is necessary in order to
	Let any subsequent 2-step node know that there is already a		Let any subsequent 2-step node know that there is already a
	follow-up message, and		follow-up message, and
	Let the end-point know to wait for a follow-up message;		Let the end-point know to wait for a follow-up message;
	2. Create a follow-up message in which to put the RTM determined as		2. Create a follow-up message in which to put the RTM determined as
	an initial correctionField value.		an initial correctionField value.
	IEEE 1588v2 [IEEE.1588.2008] defines this behavior for PTP messages.		IEEE 1588v2 [IEEE.1588.2014] defines this behavior for PTP messages.
	Thus, for example, with reference to the PTP protocol, the PTPType		Thus, for example, with reference to the PTP protocol, the PTPType
	field identifies whether the message is a Sync message, Follow_up		field identifies whether the message is a Sync message, Follow_up
	message, Delay_Req message, or Delay_Resp message. The 10 octet long		message, Delay_Req message, or Delay_Resp message. The 10 octet long
	Port ID field contains the identity of the source port, that is, the		Port ID field contains the identity of the source port, that is, the
	specific PTP port of the boundary clock connected to the MPLS		specific PTP port of the boundary clock connected to the MPLS
	network. The Sequence ID is the sequence ID of the PTP message		network. The Sequence ID is the sequence ID of the PTP message
	carried in the Value field of the message.		carried in the Value field of the message.
	PTP messages also include a bit that indicates whether or not a		PTP messages also include a bit that indicates whether or not a
	skipping to change at page 23, line 32 ¶		skipping to change at page 24, line 19 ¶
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-ospf-ospfv3-lsa-extend]		[I-D.ietf-ospf-ospfv3-lsa-extend]
	Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3		Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
	LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09		LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09
	(work in progress), November 2015.		(work in progress), November 2015.
	[IEEE.1588.2008]		[IEEE.1588.2014]
	"Standard for a Precision Clock Synchronization Protocol		"Standard for a Precision Clock Synchronization Protocol
	for Networked Measurement and Control Systems",		for Networked Measurement and Control Systems",
	IEEE Standard 1588, March 2008.		IEEE Standard 1588, August 2014.
	[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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,		Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
	<http://www.rfc-editor.org/info/rfc3209>.		<http://www.rfc-editor.org/info/rfc3209>.
End of changes. 20 change blocks.
	25 lines changed or deleted		40 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/