draft-ietf-mpls-residence-time-01.txt		draft-ietf-mpls-residence-time-02.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: July 31, 2016 Ericsson		Expires: August 13, 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
	January 28, 2016		February 10, 2016
	Residence Time Measurement in MPLS network		Residence Time Measurement in MPLS network
	draft-ietf-mpls-residence-time-01		draft-ietf-mpls-residence-time-02
	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 July 31, 2016.		This Internet-Draft will expire on August 13, 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 36		skipping to change at page 2, line 36
	2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4		2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4
	3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 5		3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 5
	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 Object . . . . . . . . . . . . . . . . . . . . . 11		4.7. RTM_SET Sub-object . . . . . . . . . . . . . . . . . . . 11
	4.7.1. RSO Sub-objects . . . . . . . . . . . . . . . . . . . 12		4.7.1. RSSO Sub-TLVs . . . . . . . . . . . . . . . . . . . . 12
	5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 15		5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 15
	6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 15		6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 15
	7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 16		7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 18		8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 18
	8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 18		8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 18
	8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 19		8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 19
	8.4. RTM Capability sub-TLV . . . . . . . . . . . . . . . . . 19		8.4. RTM Capability sub-TLV . . . . . . . . . . . . . . . . . 19
	8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 20		8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 20
	8.6. RTM_SET Object RSVP Class Number, Class Type and Sub-		8.6. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 20
	object Types . . . . . . . . . . . . . . . . . . . . . . 20
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 21		9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	11.1. Normative References . . . . . . . . . . . . . . . . . . 22		11.1. Normative References . . . . . . . . . . . . . . . . . . 21
	11.2. Informative References . . . . . . . . . . . . . . . . . 23		11.2. Informative References . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	Time synchronization protocols, Network Time Protocol version 4		Time synchronization protocols, 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] can be used to synchronize clocks across network		[IEEE.1588.2008] can be used to synchronize clocks across network
	domain. Measurement of the time a PTP event message spends		domain. Measurement of the time a PTP event message spends
	traversing a node (using precise times of receipt at an ingress		traversing a node (using precise times of receipt at an ingress
	interface and transmission at an egress interface), called Residence		interface and transmission at an egress interface), called Residence
	skipping to change at page 3, line 25		skipping to change at page 3, line 25
	Time, is one of on-path support types defined in [IEEE.1588.2008] and		Time, is one of on-path support types defined in [IEEE.1588.2008] and
	can be used to improve the accuracy of clock synchronization. This		can be used to improve the accuracy of clock synchronization. This
	document defines new Generalized Associated Channel (G-ACh) that can		document defines new Generalized Associated Channel (G-ACh) that can
	be used in Multi-Protocol Label Switching (MPLS) network to measure		be used in Multi-Protocol Label Switching (MPLS) network to measure
	Residence Time over Label Switched Path (LSP). Mechanisms for		Residence Time over Label Switched Path (LSP). Mechanisms for
	transport of time synchronization protocol packets over MPLS are out		transport of time synchronization protocol packets over MPLS are out
	of scope in this document.		of scope in this document.
	Though it is possible to use RTM over LSPs instantiated using LDP		Though it is possible to use RTM over LSPs instantiated using LDP
	such scenarios are outside the scope of this document. The scope of		such scenarios are outside the scope of this document. The scope of
	this document is on LSPs instantiated using RSVP-TE [RFC3209] because		this document is on Traffic Engineered LSPs because the LSP's path
	the LSP's path can be determined.		can be either explicitly specified or, at the minimum, can be
			determined when signaling. Such LSP can be instantiated either by
			using RSVP-TE [RFC3209] or Path Computation Element [RFC4655]. The
			PCE-based scenario is for further study and is outside the scope of
			this document.
	[I-D.ietf-tictoc-1588overmpls] describes alternative method of on-		[I-D.ietf-tictoc-1588overmpls] describes alternative method of on-
	path support for timing distribution protocols. Comparison of		path support for timing distribution protocols. Comparison of
	proposed solutions is outside the scope of this document.		proposed solutions is outside the scope of this document.
	1.1. Conventions used in this document		1.1. Conventions used in this document
	1.1.1. Terminology		1.1.1. Terminology
	MPLS: Multi-Protocol Label Switching		MPLS: Multi-Protocol Label Switching
	skipping to change at page 3, line 49		skipping to change at page 4, line 4
	TTL: Time-to-Live		TTL: Time-to-Live
	G-ACh: Generic Associated Channel		G-ACh: Generic Associated Channel
	GAL: Generic Associated Channel Label		GAL: Generic Associated Channel Label
	NTP: Network Time Protocol		NTP: Network Time Protocol
	ppm: parts per million		ppm: parts per million
	PTP: Precision Time Protocol		PTP: Precision Time Protocol
	LSP: Label Switched Path		LSP: Label Switched Path
	LSR: Label Switching Router		LSR: Label Switching Router
	OAM: Operations, Administration, and Maintenance		OAM: Operations, Administration, and Maintenance
	RRO: Record Route Object		RRO: Record Route Object
	RSO: RTM Set Object		RSSO: RTM Set Sub-object
	RTM: Residence Time Measurement		RTM: Residence Time Measurement
	IGP: Internal Gateway Protocol		IGP: Internal Gateway Protocol
	1.1.2. Requirements Language		1.1.2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	skipping to change at page 5, line 42		skipping to change at page 5, line 42
	Figure 1: RTM G-ACh packet format for Residence Time Measurement		Figure 1: RTM G-ACh packet format for Residence Time Measurement
	o First four octets are defined as G-ACh Header in [RFC5586]		o First four octets are defined as G-ACh Header in [RFC5586]
	o The Version field is set to 0, as defined in RFC 4385 [RFC4385].		o The Version field is set to 0, as defined in RFC 4385 [RFC4385].
	o The Reserved field MUST be set to 0 on transmit and ignored on		o The Reserved field MUST be set to 0 on transmit and ignored on
	receipt.		receipt.
	o The RTM G-ACh field, value to be allocated by IANA, identifies the		o The RTM G-ACh field, value (TBA1) to be allocated by IANA,
	packet as such.		identifies the packet as such.
	o The Scratch Pad field is 8 octets in length. The first RTM-		o The Scratch Pad field is 8 octets in length. The first RTM-
	capable LSR MUST initialize the Scratch Pad field, it SHOULD set		capable LSR MUST initialize the Scratch Pad field, it SHOULD set
	it to zero value. The Scratch Pad is used to accumulate the		it to zero value. The Scratch Pad is used to accumulate the
	residence time spent in each RTM capable LSR transited by the		residence time spent in each RTM capable LSR transited by the
	packet on its path from ingress LSR to egress LSR. Its format is		packet on its path from ingress LSR to egress LSR. Its format is
	IEEE double precision and its units are nanoseconds. Note:		IEEE double precision and its units are nanoseconds. Note:
	depending on one-step or two-step operation (Section 7), the		depending on one-step or two-step operation (Section 7), the
	residence time might be related to the same packet carried in the		residence time might be related to the same packet carried in the
	Value field or to a packet carried in a different RTM packet.		Value field or to a packet carried in a different RTM packet.
	skipping to change at page 8, line 42		skipping to change at page 8, line 42
	LSAs sent from a router which describe a particular interface that		LSAs sent from a router which describe a particular interface that
	does not support the same capability for RTM messages it receives.		does not support the same capability for RTM messages it receives.
	4.2. RTM Capability Sub-TLV		4.2. RTM Capability Sub-TLV
	The format for the RTM Capabilities sub-TLV is presented in Figure 4		The format for the RTM Capabilities sub-TLV is presented in Figure 4
	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(TBA5) | Length |		| Type(TBA2) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RTM | Reserved |		| RTM | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: RTM Capability sub-TLV		Figure 4: RTM Capability sub-TLV
	o Type value will be assigned by IANA from appropriate registries.		o Type value (TBA2) will be assigned by IANA from appropriate
			registries.
	o Length MUST be set to 4.		o Length MUST be set to 4.
	o RTM (capability) - is a three-bit long bit-map field with values		o RTM (capability) - is a three-bit long bit-map field with values
	defined as follows:		defined as follows:
	* 0b001 - one-step RTM supported;		* 0b001 - one-step RTM supported;
	* 0b010 - two-step RTM supported;		* 0b010 - two-step RTM supported;
	skipping to change at page 10, line 19		skipping to change at page 10, line 19
	o The S bit MUST be cleared to prevent the RTM Capability sub-TLV		o The S bit MUST be cleared to prevent the RTM Capability sub-TLV
	from leaking between levels.		from leaking between levels.
	o The D bit of the Flags field MUST be cleared as required by		o The D bit of the Flags field MUST be cleared as required by
	[RFC6823].		[RFC6823].
	o The I bit and the V bit MUST be set accordingly depending on		o The I bit and the V bit MUST be set accordingly depending on
	whether RTM capability being advertised for IPv4 or IPv6 interface		whether RTM capability being advertised for IPv4 or IPv6 interface
	of the node.		of the node.
	Application ID (TBA6) will be assigned from the Application		Application ID (TBA3) will be assigned from the Application
	Identifiers for TLV 251 IANA registry. The RTM Capability sub-TLV,		Identifiers for TLV 251 IANA registry. The RTM Capability sub-TLV,
	presented in Figure 4, MUST be included in GENINFO TLV in Application		presented in Figure 4, MUST be included in GENINFO TLV in Application
	Specific Information.		Specific Information.
	4.6. RSVP-TE Control Plane Operation to Support RTM		4.6. RSVP-TE Control Plane Operation to Support RTM
	Throughout this document we refer to an LSR as RTM capable LSR when		Throughout this document we refer to an LSR as RTM capable LSR when
	at least one of its interfaces is RTM capable. Figure 5 provides an		at least one of its interfaces is RTM capable. Figure 5 provides an
	example of relationship between roles a network element may have in		example of relationship between roles a network element may have in
	PTP over MPLS scenario and RTM capability:		PTP over MPLS scenario and RTM capability:
	skipping to change at page 11, line 19		skipping to change at page 11, line 19
	o F is the egress LER for the MPLS LSP and is not RTM capable;		o F is the egress LER for the MPLS LSP and is not RTM capable;
	o G is a Boundary Clock with its ingress port in Slave state. Node		o G is a Boundary Clock with its ingress port in Slave state. Node
	G receives PTP messages.		G receives PTP messages.
	An ingress LSR that is configured to perform RTM along a path through		An ingress LSR that is configured to perform RTM along a path through
	an MPLS network to an egress LSR verifies that the selected egress		an MPLS network to an egress LSR verifies that the selected egress
	LSR has an interface that supports RTM via the egress LSR's		LSR has an interface that supports RTM via the egress LSR's
	advertisement of the RTM Capability sub-TLV. In the Path message		advertisement of the RTM Capability sub-TLV. In the Path message
	that the ingress LSR uses to instantiate the LSP to that egress LSR		that the ingress LSR uses to instantiate the LSP to that egress LSR
	it places initialized Record Route Object (RRO) [RFC3209] and RTM Set		it places initialized Record Route Object (RRO) [RFC3209] and
	Object (RSO) [Section 4.7], which tell the egress LSR that RTM is		LSP_ATTRIBUTES Object [RFC5420] with RTM Set Sub-object (RSSO)
	requested for this LSP.		[Section 4.7], which indicates to the egress LSR that RTM is
			requested for this LSP. RSSO SHOULD NOT be included into the
			LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it is known that
			all LSRs support RSSO, because then LSR that does not recognize RSSO
			would reject the Path message.
	In the Resv message that the egress LSR sends in response to the		In the Resv message that the egress LSR sends in response to the
	received Path message, it includes initialized RRO and RSO. The RSO		received Path message, it includes initialized RRO and RSSO. The
	contains an ordered list, from egress LSR to ingress LSR, of the RTM		RSSO contains an ordered list, from egress LSR to ingress LSR, of the
	capable LSRs along the LSP's path. Each such LSR will use the ID of		RTM capable LSRs along the LSP's path. Each such LSR will use the ID
	the first LSR in the RSO in conjunction with the RRO to compute the		of the first LSR in the RSSO in conjunction with the RRO to compute
	hop count to its downstream LSR with reachable RTM capable interface.		the hop count to its downstream LSR with reachable RTM capable
	It will also insert its ID at the beginning of the RTM Set Object		interface. It will also insert its ID at the beginning of the RSSO
	before forwarding the Resv upstream.		before forwarding the Resv message upstream.
	After the ingress LSR receives the Resv, it MAY begin sending RTM		After the ingress LSR receives the Resv, it MAY begin sending RTM
	packets to the first RTM capable LSR on the LSP's path. Each RTM		packets to the first RTM capable LSR on the LSP's path. Each RTM
	packet has its Scratch Pad field initialized and its TTL set to		packet has its Scratch Pad field initialized and its TTL set to
	expire on that first subsequent RTM capable LSR.		expire on that first subsequent RTM capable LSR.
	It should be noted that RTM can also be used for LSPs instantiated		It should be noted that RTM can also be used for LSPs instantiated
	using [RFC3209] in an environment in which all interfaces in an IGP		using [RFC3209] in an environment in which all interfaces in an IGP
	support RTM. In this case the RSO MAY be omitted.		support RTM. In this case the RSSO and LSP_ATTRIBUTES Object MAY be
			omitted.
	4.7. RTM_SET Object		4.7. RTM_SET Sub-object
	RTM capable interfaces can be recorded via RTM_SET object (RSO). The		RTM capable interfaces can be recorded via RTM_SET sub-object (RSSO).
	RTM Set Class is TBA7. This document defines one C_Type, Type TBA8		The RTM Set Class is TBA7. This document defines one C_Type, Type
	RTM Set. The RTM_SET object format presented in Figure 6		TBA8 RTM Set. The RTM_SET sub-object format is of generic Type,
			Length, Value (TLV), presented 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 |
	~ Sub-objects ~		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ Value ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: RTM Set object format		Figure 6: RTM Set Sub-object format
	The contents of a RTM_SET object are a series of variable-length data		Type value (TBA4) will be assigned by IANA from its Attributes TLV
	items called sub-objects. The sub-objects are defined in		Space sub-registry.
	Section 4.7.1 below.
	The RSO can be present in both RSVP Path and Resv messages. If a		The Length contains the total length of the sub-object in bytes,
	Path message contains multiple RSOs, only the first RSO is		including the Type and Length fields.
	meaningful. Subsequent RSOs SHOULD be ignored and SHOULD NOT be
	propagated. Similarly, if in a Resv message multiple RSOs are		Reserved field must be zeroed on transmit and ignored on receipt.
			The content of an RSSO is a series of variable-length sub-TLVs. The
			sub-TLVs are defined in Section 4.7.1 below.
			The RSSO can be present in both RSVP Path and Resv messages. If a
			Path message contains multiple RSSOs, only the first RSSO is
			meaningful. Subsequent RSSOs SHOULD be ignored and SHOULD NOT be
			propagated. Similarly, if in a Resv message multiple RSSOs are
	encountered following a FILTER_SPEC before another FILTER_SPEC is		encountered following a FILTER_SPEC before another FILTER_SPEC is
	encountered, only the first RSO is meaningful. Subsequent RSOs		encountered, only the first RSSO is meaningful. Subsequent RSSOs
	SHOULD be ignored and SHOULD NOT be propagated.		SHOULD be ignored and SHOULD NOT be propagated.
	4.7.1. RSO Sub-objects		4.7.1. RSSO Sub-TLVs
	The RTM Set object contains an ordered list, from egress LSR to		The RTM Set sub-object contains an ordered list, from egress LSR to
	ingress LSR, of the RTM capable LSRs along the LSP's path.		ingress LSR, of the RTM capable LSRs along the LSP's path.
	The contents of a RTM_SET object are a series of variable-length data		The contents of a RTM_SET sub-object are a series of variable-length
	items called sub-objects. Each sub-object has its own Length field.		sub-TLVs. Each sub-TLV has its own Length field. The Length
	The length contains the total length of the sub-object in bytes,		contains the total length of the sub-TLV in bytes, including the Type
	including the Type and Length fields. The length MUST always be a		and Length fields. The Length MUST always be a multiple of 4, and at
	multiple of 4, and at least 8 (smallest IPv4 sub-object).		least 8 (smallest IPv4 sub-object).
	Sub-objects are organized as a last-in-first-out stack. The first		Sub-TLVs are organized as a last-in-first-out stack. The first -out
	-out sub-object relative to the beginning of RSO is considered the		sub-TLV relative to the beginning of RSSO is considered the top. The
	top. The last-out sub-object is considered the bottom. When a new		last-out sub-TLV is considered the bottom. When a new sub-TLV is
	sub-object is added, it is always added to the top.		added, it is always added to the top.
	Three kinds of sub-objects for RSO are currently defined.		Three kinds of sub-TLVs for RSSO are currently defined.
			4.7.1.1. IPv4 Sub-TLV
	4.7.1.1. IPv4 Sub-object
	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 | Flags |		| Type | Length | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 address |		| IPv4 address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7: IPv4 sub-object format		Figure 7: IPv4 sub-TLV format
	Type		Type
	0x01 IPv4 address		0x01 IPv4 address
	Length		Length
	The Length contains the total length of the sub-object in bytes,		The Length contains the total length of the sub-TLV in bytes,
	including the Type and Length fields. The Length is always 8.		including the Type and Length fields. The Length is always 8.
	IPv4 address		IPv4 address
	A 32-bit unicast host address.		A 32-bit unicast host address.
	Flags		Flags
	TBD		TBD
	4.7.1.2. IPv6 Sub-object		4.7.1.2. IPv6 Sub-TLV
	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 | Flags |		| Type | Length | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| IPv6 address |		| IPv6 address |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 8: IPv6 sub-object format		Figure 8: IPv6 sub-TLV format
	Type		Type
	0x02 IPv6 address		0x02 IPv6 address
	Length		Length
	The Length contains the total length of the sub-object in bytes,
			The Length contains the total length of the sub-TLV in bytes,
	including the Type and Length fields. The Length is always 20.		including the Type and Length fields. The Length is always 20.
	IPv6 address		IPv6 address
	A 128-bit unicast host address.		A 128-bit unicast host address.
	Flags		Flags
	TBD		TBD
	4.7.1.3. Unnumbered Interface Sub-object		4.7.1.3. Unnumbered Interface Sub-TLV
	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 | Flags |		| Type | Length | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Router ID |		| Router ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface ID |		| Interface ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 9: IPv4 sub-object format		Figure 9: IPv4 sub-TLV format
	Type		Type
	0x03 Unnumbered interface		0x03 Unnumbered interface
	Length		Length
	The Length contains the total length of the sub-object in bytes,		The Length contains the total length of the sub-TLV in bytes,
	including the Type and Length fields. The Length is always 12.		including the Type and Length fields. The Length is always 12.
	Router ID		Router ID
	The Router ID interpreted as discussed in the Section 2 of RFC		The Router ID interpreted as discussed in the Section 2 of RFC
	3447 [RFC3477].		3447 [RFC3477].
	Interface ID		Interface ID
	The identifier assigned to the link by the LSR specified by the		The identifier assigned to the link by the LSR specified by the
	skipping to change at page 20, line 18		skipping to change at page 20, line 18
	Application Identifiers for TLV 251 registry as follows:		Application Identifiers for TLV 251 registry as follows:
	+-------+-------------+---------------+		+-------+-------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+-------------+---------------+		+-------+-------------+---------------+
	| TBA3 | RTM | This document |		| TBA3 | RTM | This document |
	+-------+-------------+---------------+		+-------+-------------+---------------+
	Table 5: IS-IS RTM Application ID		Table 5: IS-IS RTM Application ID
	8.6. RTM_SET Object RSVP Class Number, Class Type and Sub-object Types		8.6. RTM_SET Sub-object RSVP Type and sub-TLVs
	IANA is requested to assign a new Class Number for RTM_SET object as
	follows:
	+-------+----------------+---------------+
	| Value | Description | Reference |
	+-------+----------------+---------------+
	| TBA4 | RTM_SET object | This document |
	+-------+----------------+---------------+
	Table 6: RTM_SET object Class
	IANA is requested to assign a new Class Type for RTM_SET object as		IANA is requested to assign a new Type for RTM_SET sub-object from
	follows:		Attributes TLV Space sub-registry as follows:
	+-------+-------------+---------------+		+----+------------+-----------+----------------+---------+----------+
	| Value | Description | Reference |		| Ty | Name | Allowed | Allowed on LSP | Allowed | Referenc |
	+-------+-------------+---------------+		| pe | | on LSP_AT | _REQUIRED_ATTR | on LSP | e |
	| TBA5 | RTM Set | This document |		| | | TRIBUTES | IBUTES | Hop Att | |
	+-------+-------------+---------------+		| | | | | ributes | |
			+----+------------+-----------+----------------+---------+----------+
			| TB | RTM_SET | Yes | No | No | This |
			| A4 | sub-object | | | | document |
			+----+------------+-----------+----------------+---------+----------+
	Table 7: RTM_SET object Class Type		Table 6: RTM_SET Sub-object Type
	IANA requested to create new sub-registry for sub-object types of		IANA requested to create new sub-registry for sub-TLV types of
	RTM_SET object as follows:		RTM_SET sub-object as follows:
	+-----------+----------------------+-------------------------+		+-----------+----------------------+-------------------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-----------+----------------------+-------------------------+		+-----------+----------------------+-------------------------+
	| 0 | Reserved | |		| 0 | Reserved | |
	| 1 | IPv4 address | This document |		| 1 | IPv4 address | This document |
	| 2 | IPv6 address | This document |		| 2 | IPv6 address | This document |
	| 3 | Unnumbered interface | This document |		| 3 | Unnumbered interface | This document |
	| 4-127 | Reserved | IETF Consensus |		| 4-127 | Reserved | IETF Consensus |
	| 128 - 191 | Reserved | First Come First Served |		| 128 - 191 | Reserved | First Come First Served |
	| 192 - 255 | Reserved | Private Use |		| 192 - 255 | Reserved | Private Use |
	+-----------+----------------------+-------------------------+		+-----------+----------------------+-------------------------+
	Table 8: RTM_SET object sub-object types		Table 7: RTM_SET object sub-object types
	9. Security Considerations		9. Security Considerations
	Routers that support Residence Time Measurement are subject to the		Routers that support Residence Time Measurement are subject to the
	same security considerations as defined in [RFC5586] .		same security considerations as defined in [RFC5586] .
	In addition - particularly as applied to use related to PTP - there		In addition - particularly as applied to use related to PTP - there
	is a presumed trust model that depends on the existence of a trusted		is a presumed trust model that depends on the existence of a trusted
	relationship of at least all PTP-aware nodes on the path traversed by		relationship of at least all PTP-aware nodes on the path traversed by
	PTP messages. This is necessary as these nodes are expected to		PTP messages. This is necessary as these nodes are expected to
	skipping to change at page 22, line 49		skipping to change at page 22, line 35
	[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,		[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
	"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for		"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
	Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,		Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
	February 2006, <http://www.rfc-editor.org/info/rfc4385>.		February 2006, <http://www.rfc-editor.org/info/rfc4385>.
	[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual		[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
	Circuit Connectivity Verification (VCCV): A Control		Circuit Connectivity Verification (VCCV): A Control
	Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,		Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
	December 2007, <http://www.rfc-editor.org/info/rfc5085>.		December 2007, <http://www.rfc-editor.org/info/rfc5085>.
			[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
			Ayyangarps, "Encoding of Attributes for MPLS LSP
			Establishment Using Resource Reservation Protocol Traffic
			Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
			February 2009, <http://www.rfc-editor.org/info/rfc5420>.
	[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,		[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
	"MPLS Generic Associated Channel", RFC 5586,		"MPLS Generic Associated Channel", RFC 5586,
	DOI 10.17487/RFC5586, June 2009,		DOI 10.17487/RFC5586, June 2009,
	<http://www.rfc-editor.org/info/rfc5586>.		<http://www.rfc-editor.org/info/rfc5586>.
	[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,		[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
	"Network Time Protocol Version 4: Protocol and Algorithms		"Network Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,		Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
	<http://www.rfc-editor.org/info/rfc5905>.		<http://www.rfc-editor.org/info/rfc5905>.
	skipping to change at page 23, line 39		skipping to change at page 23, line 34
	Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.		Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
	Montini, "Transporting Timing messages over MPLS		Montini, "Transporting Timing messages over MPLS
	Networks", draft-ietf-tictoc-1588overmpls-07 (work in		Networks", draft-ietf-tictoc-1588overmpls-07 (work in
	progress), October 2015.		progress), October 2015.
	[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions		[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
	in Support of Generalized Multi-Protocol Label Switching		in Support of Generalized Multi-Protocol Label Switching
	(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,		(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
	<http://www.rfc-editor.org/info/rfc4202>.		<http://www.rfc-editor.org/info/rfc4202>.
			[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
			Element (PCE)-Based Architecture", RFC 4655,
			DOI 10.17487/RFC4655, August 2006,
			<http://www.rfc-editor.org/info/rfc4655>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<http://www.rfc-editor.org/info/rfc5226>.
	[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay		[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
	Measurement for MPLS Networks", RFC 6374,		Measurement for MPLS Networks", RFC 6374,
	DOI 10.17487/RFC6374, September 2011,		DOI 10.17487/RFC6374, September 2011,
	<http://www.rfc-editor.org/info/rfc6374>.		<http://www.rfc-editor.org/info/rfc6374>.
End of changes. 48 change blocks.
	90 lines changed or deleted		115 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/