draft-mirsky-mpls-residence-time-06.txt		draft-mirsky-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: November 3, 2015 Ericsson		Expires: January 4, 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
	May 2, 2015		July 3, 2015
	Residence Time Measurement in MPLS network		Residence Time Measurement in MPLS network
	draft-mirsky-mpls-residence-time-06		draft-mirsky-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 November 3, 2015.		This Internet-Draft will expire on January 4, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 34		skipping to change at page 2, line 34
	1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3		1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
	1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4		1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4
	2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4		2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4
	3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 4		3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 4
	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 . . . . . . . . . . 10		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 Object . . . . . . . . . . . . . . . . . . . . . 11
	4.7.1. RSO Sub-objects . . . . . . . . . . . . . . . . . . . 12		4.7.1. RSO Sub-objects . . . . . . . . . . . . . . . . . . . 12
	5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 14		5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 14
	6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 15		6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 15
	7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 15		7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 15
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 17		8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 17
	8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 18		8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 18
	8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 18		8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 18
	skipping to change at page 3, line 22		skipping to change at page 3, line 22
	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
	Time, can be used to improve the accuracy of clock synchronization.		Time, can be used to improve the accuracy of clock synchronization.
	This document defines new Generalized Associated Channel (G-ACh) that		This document defines new Generalized Associated Channel (G-ACh) that
	can be used in Multi-Protocol Label Switching (MPLS) network to		can be used in Multi-Protocol Label Switching (MPLS) network to
	measure Residence Time over Label Switched Path (LSP). Mechanisms		measure Residence Time over Label Switched Path (LSP). Mechanisms
	for transport of time synchronization protocol packets over MPLS are		for transport of time synchronization protocol packets over MPLS are
	out of scope in this document.		out of scope in this document.
			Though it is possible to use RTM over LSPs instantiated using LDP
			such scenarios are outside the scope of this document. The scope of
			this document is on LSPs instantiated using RSVP-TE [RFC3209] because
			the LSP's path can be determined.
	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
	ACH: Associated Channel		ACH: Associated Channel
	TTL: Time-to-Live		TTL: Time-to-Live
	skipping to change at page 7, line 25		skipping to change at page 7, line 33
	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
	from one RTM capable interface to the next along the path from		from one RTM capable interface to the next along the path from
	ingress LSR to egress LSR. This means that an LSR with RTM capable		ingress LSR to egress LSR. This means that an LSR with RTM capable
	interfaces MUST be able to compute a TTL which will cause the expiry		interfaces MUST be able to compute a TTL which will cause the expiry
	of an RTM packet at the next LSR with RTM capable interfaces.		of an RTM packet at the next LSR with RTM capable interfaces.
	However, because of Equal Cost Multipath, labels distributed by LDP
	do not necessarily instantiate a single path between a given ingress/
	egress LSR pair but rather MAY create a graph in which different
	flows will take different paths through this network. This means one
	doesn't necessarily know the path that RTM packets will take or even
	if they all take the same path. In an environment in which not all
	interfaces in an IGP domain support RTM, it is effectively impossible
	to use TTL expiry to deliver RTM packets. Hence RTM cannot be used
	for LSPs instantiated using LDP, if multi-pathing is in use and not
	all LSRs are RTM-capable. In the special but important case of
	environment in which all interfaces in an IGP domain support RTM,
	setting the TTL to 1 will always cause the expiry of an RTM packet on
	the next RTM capable downstream LSR and hence in such an environment,
	RTM can be used for LSPs instantiated using LDP.
	Also, if it is possible and desirable, multi-path forwarding may be
	disabled,at least for LSPs used for RTM.
	Generally speaking, RTM is more useful for an LSP instantiated using
	RSVP-TE [RFC3209] because the LSP's path can be determined.
	4.1. RTM Capability		4.1. RTM Capability
	Note that RTM capability of a node is with respect to the pair of		Note that RTM capability of a node is with respect to the pair of
	interfaces that will be used to forward an RTM packet. In general,		interfaces that will be used to forward an RTM packet. In general,
	the ingress interface of this pair must be able to capture the		the ingress interface of this pair must be able to capture the
	arrival time of the packet and encode it in some way such that this		arrival time of the packet and encode it in some way such that this
	information will be available to the egress interface.		information will be available to the egress interface.
	The supported modes (1-step verses 2-step) of any pair of interfaces		The supported modes (1-step verses 2-step) of any pair of interfaces
	is then determined by the capability of the egress interface. In		is then determined by the capability of the egress interface. In
	skipping to change at page 8, line 34		skipping to change at page 8, line 20
	The RTM capability used in the sub-TLV shown in Figure 4 is thus		The RTM capability used in the sub-TLV shown in Figure 4 is thus
	associated with the egress port of the node making the advertisement,		associated with the egress port of the node making the advertisement,
	while the ability of any pair of interfaces that includes this egress		while the ability of any pair of interfaces that includes this egress
	interface to support any mode of RTM depends on the ability of that		interface to support any mode of RTM depends on the ability of that
	interface to record packet arrival time in some way that can be		interface to record packet arrival time in some way that can be
	conveyed to and used by that egress interface.		conveyed to and used by that egress interface.
	When an LSR uses an IGP to carry the RTM capability sub-TLV, the sub-		When an LSR uses an IGP to carry the RTM capability sub-TLV, the sub-
	TLV MUST reflect the RTM capability (1-step or 2-step) associated		TLV MUST reflect the RTM capability (1-step or 2-step) associated
	with egress interfaces and MUST NOT propagate this sub-TLV in IGP		with egress interfaces and MUST NOT propagate this sub-TLV in IGP
	LSAs sent from an interface that does not support the same capability		LSAs sent from a router which describe a particular interface that
	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(TBA5) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 10, line 32		skipping to change at page 10, line 16
	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 (TBA6) 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
	Though RTM capability is per interface throughout this document we		Throughout this document we refer to an LSR as RTM capable LSR when
	will refer to an LSR as RTM capable LSR when:		at least one of its interfaces is RTM capable. Figure 5 provides an
			example of relationship between roles a network element may have in
			PTP over MPLS scenario and RTM capability:
	o ingress LSR's LSP interface is RTM capable;		----- ----- ----- ----- ----- ----- -----
			| A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G |
			----- ----- ----- ----- ----- ----- -----
	o transit LSR's ingress and egress interfaces for the given LSP are		Figure 5: RTM capable roles
	RTM capable;
	o egress LSR's egress interface is RTM capable.		o A is a Boundary Clock with its egress port in Master state. Node
			A transmits PTP messages;
			o B is the ingress LER for the MPLS LSP and is not RTM capable;
			o C is the first RTM capable LSR; it initializes the RTM Scratch Pad
			field and encapsulates PTP messages in the RTM ACH; the
			transmitted Scratch Pad information includes the residence time
			measured by C;
			o D is a transit LSR that is not RTM capable; it passes along the
			RTM ACH encapsulated PTP message unmodified;
			o E is the last RTM capable LSR; it updates the Correction field of
			the PTP message with the value in the Scratch Pad field of the RTM
			ACH, and removes the RTM ACH encapsulation;
			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
			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 RTM Set
	Object (RSO) [Section 4.7], which tell the egress LSR that RTM is		Object (RSO) [Section 4.7], which tell the egress LSR that RTM is
	requested for this LSP.		requested for this LSP.
	skipping to change at page 11, line 24		skipping to change at page 11, line 31
	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 RSO MAY be omitted.
	4.7. RTM_SET Object		4.7. RTM_SET Object
	RTM capable interfaces can be recorded via RTM_SET object (RSO). The		RTM capable interfaces can be recorded via RTM_SET object (RSO). The
	RTM Set Class is TBA7. This document defines one C_Type, Type TBA8		RTM Set Class is TBA7. This document defines one C_Type, Type TBA8
	RTM Set. The RTM_SET object format presented in Figure 5		RTM Set. The RTM_SET object format 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Sub-objects ~		~ Sub-objects ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: RTM Set object format		Figure 6: RTM Set object format
	The contents of a RTM_SET object are a series of variable-length data		The contents of a RTM_SET object are a series of variable-length data
	items called sub-objects. The sub-objects are defined in		items called sub-objects. The sub-objects are defined in
	Section 4.7.1 below.		Section 4.7.1 below.
	The RSO can be present in both RSVP Path and Resv messages. If a		The RSO can be present in both RSVP Path and Resv messages. If a
	Path message contains multiple RSOs, only the first RSO is		Path message contains multiple RSOs, only the first RSO is
	meaningful. Subsequent RSOs SHOULD be ignored and SHOULD NOT be		meaningful. Subsequent RSOs SHOULD be ignored and SHOULD NOT be
	propagated. Similarly, if in a Resv message multiple RSOs are		propagated. Similarly, if in a Resv message multiple RSOs are
	encountered following a FILTER_SPEC before another FILTER_SPEC is		encountered following a FILTER_SPEC before another FILTER_SPEC is
	skipping to change at page 12, line 33		skipping to change at page 12, line 35
	4.7.1.1. IPv4 Sub-object		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 6: IPv4 sub-object format		Figure 7: IPv4 sub-object 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-object in bytes,
	including the Type and Length fields. The Length is always 8.		including the Type and Length fields. The Length is always 8.
	skipping to change at page 13, line 18		skipping to change at page 13, line 19
	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 7: IPv6 sub-object format		Figure 8: IPv6 sub-object 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-object in bytes,
	including the Type and Length fields. The Length is always 20.		including the Type and Length fields. The Length is always 20.
	skipping to change at page 13, line 49		skipping to change at page 13, line 50
	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 8: IPv4 sub-object format		Figure 9: IPv4 sub-object 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-object 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
	skipping to change at page 15, line 12		skipping to change at page 15, line 14
	subsequent follow-up message, so that this value can be used to		subsequent follow-up message, so that this value can be used to
	update the correctionField in the follow-up message.		update the correctionField in the follow-up message.
	See Section 7 for further details on the difference between 1-step		See Section 7 for further details on the difference between 1-step
	and 2-step operation.		and 2-step operation.
	The last RTM-capable LSR on the LSP MAY then use the value in the		The last RTM-capable LSR on the LSP MAY then use the value in the
	Scratch Pad field to perform time correction, if there is no follow-		Scratch Pad field to perform time correction, if there is no follow-
	up message. For example, the egress LSR may be a PTP Boundary Clock		up message. For example, the egress LSR may be a PTP Boundary Clock
	synchronized to a Master Clock and will use the value in the Scratch		synchronized to a Master Clock and will use the value in the Scratch
	Pad Field to update PTP's correctionField.		Pad field to update PTP's correctionField.
	6. Applicable PTP Scenarios		6. Applicable PTP Scenarios
	The proposed approach can be directly integrated in a PTP network		The proposed approach can be directly integrated in a PTP network
	based on the IEEE 1588 delay reqest-response mechanism. The RTM		based on the IEEE 1588 delay reqest-response mechanism. The RTM
	capable LSR nodes act as end-to-end transparent clocks, and typically		capable LSR nodes act as end-to-end transparent clocks, and typically
	boundary clocks, at the edges of the MPLS network, use the value in		boundary clocks, at the edges of the MPLS network, use the value in
	the Scratch Pad field to update the correctionField of the		the Scratch Pad field to update the correctionField of the
	corresponding PTP event packet prior to performing the usual PTP		corresponding PTP event packet prior to performing the usual PTP
	processing.		processing.
	skipping to change at page 16, line 39		skipping to change at page 16, line 41
	capable node MUST wait for the RTM message with the PTP type of		capable node MUST wait for the RTM message with the PTP type of
	follow-up and matching originator and sequence number to make the		follow-up and matching originator and sequence number to make the
	corresponding residence time update to the Scratch Pad field.		corresponding residence time update to the Scratch Pad field.
	In practice an RTM operating according to two-step clock behaves like		In practice an RTM operating according to two-step clock behaves like
	a two-steps transparent clock.		a two-steps transparent clock.
	A 1-step capable RTM node MAY elect to operate in either 1-step mode		A 1-step capable RTM node MAY elect to operate in either 1-step mode
	(by making an update to the Scratch Pad field of the RTM message		(by making an update to the Scratch Pad field of the RTM message
	containing the PTP even message), or in 2-step mode (by making an		containing the PTP even message), or in 2-step mode (by making an
	update to the scratch pad of a follow-up message when its presence is		update to the Scratch Pad of a follow-up message when its presence is
	indicated), but MUST NOT do both.		indicated), but MUST NOT do both.
	Two main subcases can be identified for an RTM node operating as a		Two main subcases can be identified for an RTM node operating as a
	two-step clock:		two-step clock:
	A) If any of the previous RTM capable node or the previous PTP clock		A) If any of the previous RTM capable node or the previous PTP clock
	(e.g. the BC connected to the first LSR), is a two-step clock, the		(e.g. the BC connected to the first LSR), is a two-step clock, the
	residence time is added to the RTM packet that has been created to		residence time is added to the RTM packet that has been created to
	include the associated PTP packet (i.e. follow-up message in the		include the associated PTP packet (i.e. follow-up message in the
	downstream direction), if the local RTM-capable LSR is also operating		downstream direction), if the local RTM-capable LSR is also operating
	skipping to change at page 21, line 42		skipping to change at page 21, line 42
	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-06		LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-06
	(work in progress), February 2015.		(work in progress), February 2015.
	[I-D.ietf-ospf-prefix-link-attr]		[I-D.ietf-ospf-prefix-link-attr]
	Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,		Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
	Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute		Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
	Advertisement", draft-ietf-ospf-prefix-link-attr-04 (work		Advertisement", draft-ietf-ospf-prefix-link-attr-06 (work
	in progress), April 2015.		in progress), June 2015.
	[IEEE.1588.2008]		[IEEE.1588.2008]
	"Standard for a Precision Clock Synchronization Protocol		"Standard for a Precision Clock Synchronization Protocol
	for Networked Measurement and Control Systems", IEEE		for Networked Measurement and Control Systems", IEEE
	Standard 1588, March 2008.		Standard 1588, March 2008.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
End of changes. 21 change blocks.
	43 lines changed or deleted		51 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/