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/