Re: Review of draft-ietf-mpls-residence-time-12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Robert,
once again, thank you for your thorough review and the most detailed comments. I've prepared updated version and would greatly appreciate if you review the changes and let us know whether your comments been addressed. Attached are diff and the new version.

Regards,
Greg

On Wed, Jan 11, 2017 at 7:48 AM, Robert Sparks <rjsparks@xxxxxxxxxxx> wrote:
Reviewer: Robert Sparks
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-mpls-residence-time-12
Reviewer: Robert Sparks
Review Date: 2017-01-10
IETF LC End Date: 2017-01-17
IESG Telechat date: 2017-02-02

Summary: Ready (with nits) for publication as a Proposed Standard

I have two primary comments. I expect both are rooted in the authors
and working group knowing what the document means instead of seeing
what
it says or doesn't say:

1) The document is loose with its use of 'packet', and where TTLs
appear when
they are discussed. It might be helpful to rephrase the text that
speaks
of RTM packets in terms of RTM messages that are encoded as G-ACh
messages and
not refer to packets unless you mean the whole encapsulated packet
with MPLS
header, ACH, and G-ACh message.

2) Since this new mechanic speaks in terms of fractional nanoseconds,
some
discussion of what trigger-point you intend people to use for taking
the
precise time of a packet's arrival or departure seems warranted. (The
first and
last bit of the whole encapsulated packet above are going to appear at
the
physical layer many nanoseconds apart at OC192 speeds if I've done the
math
right). It may be obvious to the folks discussing this, but it's not
obvious
from the document.  If it's _not_ obvious and variation in technique
is
expected, then some discussion about issues that might arise from
different
implementation choices would be welcome.

The rest of these are editorial nits:

It would help to pull an overview description of the difference
between
one-step and two-step much earlier in the document. I suggest in the
overview
in section 2. Otherwise, the reader really has to jump forward and
read section
7 before section 3's 5th bullet makes any sense.

In section 3, "IANA will be asked" should be made active. Say "This
document
asks IANA to" and point to the IANA consideration section. Apply
similar
treatment to the other places where you talk about future IANA
actions.

There are several places where there are missing words (typically
articles or
prepositions). You're less likely to end up with misinterpretations
during the
RFC Editor phase if you provide them before the document gets that far
in the
process. The spots I found most disruptive were these (this is not
intended to
be exhaustive):

  Section 3: "set 1 according" -> "set to 1 according"
  Section 3: "the Table 19 [IEEE..." -> "Table 19 of [IEEE..."
  Section 4.2: "Detailed discussion of ... modes in Section 7."
                        -> "Detailed discussion of ... modes appears
in Section 7."
  Section 10: "most of" -> "most of all"

In Setion 3.1 at "identity of the source port", please point into the
document
that defines this identity and its representation. I suspect this is a
pointer
into a specific section in IEEE.1588.2008].







MPLS Working Group                                             G. Mirsky
Internet-Draft                                                 ZTE Corp.
Intended status: Standards Track                              S. Ruffini
Expires: July 22, 2017                                           E. Gray
                                                                Ericsson
                                                                J. Drake
                                                        Juniper Networks
                                                               S. Bryant
                                                                  Huawei
                                                           A. Vainshtein
                                                             ECI Telecom
                                                        January 18, 2017


               Residence Time Measurement in MPLS network
                   draft-ietf-mpls-residence-time-13

Abstract

   This document specifies new Generic Associated Channel for Residence
   Time Measurement and how it can be used by time synchronization
   protocols being transported over MPLS domain.

   Residence time is the variable part of propagation delay of timing
   and synchronization messages and knowing what this delay is for each
   message allows for a more accurate determination of the delay to be
   taken into account in applying the value included in a Precision Time
   Protocol event message.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 22, 2017.






Mirsky, et al.            Expires July 22, 2017                 [Page 1]

Internet-Draft         Residence Time Measurement           January 2017


Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Conventions used in this document . . . . . . . . . . . .   3
       1.1.1.  Terminology . . . . . . . . . . . . . . . . . . . . .   3
       1.1.2.  Requirements Language . . . . . . . . . . . . . . . .   4
   2.  Residence Time Measurement  . . . . . . . . . . . . . . . . .   4
   3.  G-ACh for Residence Time Measurement  . . . . . . . . . . . .   5
     3.1.  PTP Packet Sub-TLV  . . . . . . . . . . . . . . . . . . .   6
   4.  Control Plane Theory of Operation . . . . . . . . . . . . . .   7
     4.1.  RTM Capability  . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  RTM Capability Sub-TLV  . . . . . . . . . . . . . . . . .   8
     4.3.  RTM Capability Advertisement in OSPFv2  . . . . . . . . .   9
     4.4.  RTM Capability Advertisement in OSPFv3  . . . . . . . . .   9
     4.5.  RTM Capability Advertisement in IS-IS . . . . . . . . . .   9
     4.6.  RSVP-TE Control Plane Operation to Support RTM  . . . . .  10
     4.7.  RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . .  11
       4.7.1.  RTM_SET Sub-TLVs  . . . . . . . . . . . . . . . . . .  13
   5.  Data Plane Theory of Operation  . . . . . . . . . . . . . . .  16
   6.  Applicable PTP Scenarios  . . . . . . . . . . . . . . . . . .  16
   7.  one-step Clock and two-step Clock Modes . . . . . . . . . . .  17
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     8.1.  New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . .  19
     8.2.  New RTM TLV Registry  . . . . . . . . . . . . . . . . . .  19
     8.3.  New RTM Sub-TLV Registry  . . . . . . . . . . . . . . . .  20
     8.4.  RTM Capability sub-TLV in OSPFv2  . . . . . . . . . . . .  20
     8.5.  IS-IS RTM Application ID  . . . . . . . . . . . . . . . .  21
     8.6.  RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . .  21
     8.7.  RTM_SET Attribute Flag  . . . . . . . . . . . . . . . . .  22
     8.8.  New Error Codes . . . . . . . . . . . . . . . . . . . . .  22
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  23
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23



Mirsky, et al.            Expires July 22, 2017                 [Page 2]

Internet-Draft         Residence Time Measurement           January 2017


     11.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     11.2.  Informative References . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Introduction

   Time synchronization protocols, e.g., Network Time Protocol version 4
   (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2
   [IEEE.1588.2008] define timing messages that can be used to
   synchronize clocks across a network domain.  Measurement of the
   cumulative time one of these timing messages spends transiting the
   nodes on the path from ingress node to egress node is termed
   Residence Time and it is used to improve the accuracy of clock
   synchronization.  (I.e., it is the sum of the difference between the
   time of receipt at an ingress interface and the time of transmission
   from an egress interface for each node along the path from ingress
   node to egress node.)  This document defines a new Generic Associated
   Channel (G-ACh) value and an associated residence time measurement
   (RTM) message that can be used in a Multi-Protocol Label Switching
   (MPLS) network to measure residence time over a Label Switched Path
   (LSP).

   Although it is possible to use RTM over an LSP instantiated using
   LDP, that is outside the scope of this document.  Rather, this
   document describes RTM over an LSP signaled using RSVP-TE [RFC3209]
   because the LSP's path can be either explicitly specified or
   determined during signaling.

   Comparison with alternative proposed solutions such as
   [I-D.ietf-tictoc-1588overmpls] is outside the scope of this document.

1.1.  Conventions used in this document

1.1.1.  Terminology

   MPLS: Multi-Protocol Label Switching

   ACH: Associated Channel

   TTL: Time-to-Live

   G-ACh: Generic Associated Channel

   GAL: Generic Associated Channel Label

   NTP: Network Time Protocol

   ppm: parts per million



Mirsky, et al.            Expires July 22, 2017                 [Page 3]

Internet-Draft         Residence Time Measurement           January 2017


   PTP: Precision Time Protocol

   BC: Boundary Clock

   LSP: Label Switched Path

   OAM: Operations, Administration, and Maintenance

   RRO: Record Route Object

   RTM: Residence Time Measurement

   IGP: Internal Gateway Protocol

1.1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

2.  Residence Time Measurement

   Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be
   used to measure one-way or two-way end-to-end propagation delay over
   LSP or PW.  But these measurements are insufficient for use in some
   applications, for example, time synchronization across a network as
   defined in the Precision Time Protocol (PTP).  In PTPv2
   [IEEE.1588.2008] residence times is accumulated in the
   correctionField of the PTP event message, as defined in
   [IEEE.1588.2008] and referred as case of one-step clocks, or in the
   associated follow-up message (or Delay_Resp message associated with
   the Delay_Req message) in case of two-step clocks (see the detailed
   discussion in Section 7).

   IEEE 1588 uses this residence time to correct the transit time from
   ingress node to egress node, effectively making the transit nodes
   transparent.

   This document proposes a mechanism that can be used as one of types
   of on-path support for a clock synchronization protocol or to perform
   one-way measurement of residence time.  The proposed mechanism
   accumulates residence time from all nodes that support this extension
   along the path of a particular LSP in Scratch Pad field of an RTM
   message Figure 1.  This value can then be used by the egress node to
   update, for example, the correctionField of the PTP event packet
   carried within the RTM message prior to performing its PTP
   processing.



Mirsky, et al.            Expires July 22, 2017                 [Page 4]

Internet-Draft         Residence Time Measurement           January 2017


3.  G-ACh for Residence Time Measurement

   RFC 5586 [RFC5586] and RFC 6423 [RFC6423] define the G-ACh to extend
   the applicability of the PW Associated Channel (ACH) [RFC5085] to
   LSPs.  G-ACh provides a mechanism to transport OAM and other control
   messages over an LSP.  Processing of these messages by selected
   transit nodes is controlled by the use of the Time-to-Live (TTL)
   value in the MPLS header of these messages.

   The message format for Residence Time Measurement (RTM) is presented
   in Figure 1

     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 0 0 1|Version|   Reserved    |           RTM G-ACh           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                        Scratch Pad                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Type               |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Value                             |
    ~                                                               ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 1: RTM G-ACh message format for Residence Time Measurement

   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 Reserved field MUST be set to 0 on transmit and ignored on
      receipt.

   o  The RTM G-ACh field, value (TBA1) to be allocated by IANA,
      identifies the packet as such.

   o  The Scratch Pad field is 8 octets in length.  It is used to
      accumulate the residence time spent in each RTM capable node
      transited by the packet on its path from ingress node to egress
      node.  The first RTM-capable node MUST initialize the Scratch Pad
      field with its residence time measurement.  Its format is IEEE
      double precision and its units are nanoseconds.  Note that
      depending on whether the timing procedure is one-step or two-step
      operation (Section 7), the residence time is either for the timing
      packet carried in the Value field of this RTM message or for an



Mirsky, et al.            Expires July 22, 2017                 [Page 5]

Internet-Draft         Residence Time Measurement           January 2017


      associated timing packet carried in the Value field of another RTM
      message.

   o  The Type field identifies the type and encapsulation of a timing
      packet carried in the Value field, e.g., NTP [RFC5905] or PTP
      [IEEE.1588.2008].  This document asks IANA to create a sub-
      registry in Generic Associated Channel (G-ACh) Parameters Registry
      called "MPLS RTM TLV Registry" Section 8.2.

   o  The Length field contains the length, in octets, of the of the
      timing packet carried in the Value field.

   o  The optional Value field MAY carry a packet of the time
      synchronization protocol identified by Type field.  It is
      important to note that the packet may be authenticated or
      encrypted and carried over LSP edge to edge unchanged while the
      residence time is accumulated in the Scratch Pad field.

   o  The TLV MUST be included in the RTM message, even if the length of
      the Value field is zero.

3.1.  PTP Packet Sub-TLV

   Figure 2 presents format of a PTP sub-TLV that MUST be included in
   the Value field of an RTM message preceding the carried timing packet
   when the timing packet is PTP.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Type              |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Flags                         |PTPType|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Port ID                            |
    |                                                               |
    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |           Sequence ID         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2: PTP Sub-TLV format

   where Flags field has format








Mirsky, et al.            Expires July 22, 2017                 [Page 6]

Internet-Draft         Residence Time Measurement           January 2017


     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |S|                      Reserved                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 3: Flags field format of PTP Packet Sub-TLV

   o  The Type field identifies PTP packet sub-TLV and is set to 1
      according to Section 8.3.

   o  The Length field of the PTP sub-TLV contains the number of octets
      of the Value field and MUST be 20.

   o  The Flags field currently defines one bit, the S-bit, that defines
      whether the current message has been processed by a two-step node,
      where the flag is cleared if the message has been handled
      exclusively by one-step nodes and there is no follow-up message,
      and set if there has been at least one two-step node and a follow-
      up message is forthcoming.

   o  The PTPType indicates the type of PTP packet carried in the TLV.
      PTPType is the messageType field of the PTPv2 packet whose values
      are defined in Table 19 of [IEEE.1588.2008].

   o  The 10 octets long Port ID field contains the identity of the
      source port.

   o  The Sequence ID is the sequence ID of the PTP message carried in
      the Value field of the message.

4.  Control Plane Theory of Operation

   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
   ingress node to egress node.  This means that a node with RTM capable
   interfaces MUST be able to compute a TTL which will cause the expiry
   of an RTM packet at the next node with RTM capable interfaces.

4.1.  RTM Capability

   Note that the RTM capability of a node is with respect to the pair of
   interfaces that will be used to forward an RTM packet.  In general,
   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
   information will be available to the egress interface.





Mirsky, et al.            Expires July 22, 2017                 [Page 7]

Internet-Draft         Residence Time Measurement           January 2017


   The supported modes (one-step or two-step) of any pair of interfaces
   is then determined by the capability of the egress interface.  For
   both modes, the egress interface implementation MUST be able to
   determine the precise departure time of the same packet and determine
   from this, and the arrival time information from the corresponding
   ingress interface, the difference representing the residence time for
   the packet.

   An interface with the ability to do this and update the associated
   Scratch Pad in real-time (i.e. while the packet is being forwarded)
   is said to be one-step capable.

   Hence while both ingress and egress interfaces are required to
   support RTM for the pair to be RTM-capable, it is the egress
   interface that determines whether or not the node is one-step or two-
   step capable with respect to the interface-pair.

   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,
   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 record packet arrival time in some way that can be
   conveyed to and used by that egress interface.

   When a node uses an IGP to carry the RTM capability sub-TLV, the sub-
   TLV MUST reflect the RTM capability (one-step or two-step) associated
   with egress interfaces.

4.2.  RTM Capability Sub-TLV

   The format for the RTM Capabilities sub-TLV is presented in Figure 4

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Type             |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | RTM |                       Reserved                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 4: RTM Capability sub-TLV

   o  Type value (TBA2) will be assigned by IANA from appropriate
      registry for OSPFv2 Section 8.4.

   o  Length MUST be set to 4.





Mirsky, et al.            Expires July 22, 2017                 [Page 8]

Internet-Draft         Residence Time Measurement           January 2017


   o  RTM (capability) - is a three-bit long bit-map field with values
      defined as follows:

      *  0b001 - one-step RTM supported;

      *  0b010 - two-step RTM supported;

      *  0b100 - reserved.

   o  Reserved field must be set to all zeroes on transmit and ignored
      on receipt.

   [RFC4202] explains that the Interface Switching Capability Descriptor
   describes switching capability of an interface.  For bi-directional
   links, the switching capabilities of an interface are defined to be
   the same in either direction.  I.e., for data entering the node
   through that interface and for data leaving the node through that
   interface.  That principle SHOULD be applied when a node advertises
   RTM Capability.

   A node that supports RTM MUST be able to act in two-step mode and MAY
   also support one-step RTM mode.  Detailed discussion of one-step and
   two-step RTM modes appears in Section 7.

4.3.  RTM Capability Advertisement in OSPFv2

   The capability to support RTM on a particular link (interface) is
   advertised in the OSPFv2 Extended Link Opaque LSA described in
   Section 3 [RFC7684] via the RTM Capability sub-TLV.

   Its Type value will be assigned by IANA from the OSPF Extended Link
   TLV Sub-TLVs registry Section 8.4, that will be created per [RFC7684]
   request.

4.4.  RTM Capability Advertisement in OSPFv3

   The capability to support RTM on a particular link (interface) can be
   advertised in OSPFv3 using LSA extensions as described in
   [I-D.ietf-ospf-ospfv3-lsa-extend].  Exact use of OSPFv3 LSA
   extensions is for further study.

4.5.  RTM Capability Advertisement in IS-IS

   The capability to support RTM on a particular link (interface) is
   advertised in the GENINFO TLV described in [RFC6823] via the RTM
   Capability sub-TLV.

   With respect to the Flags field of the GENINFO TLV:



Mirsky, et al.            Expires July 22, 2017                 [Page 9]

Internet-Draft         Residence Time Measurement           January 2017


   o  The S bit MUST be cleared to prevent the RTM Capability sub-TLV
      from leaking between levels.

   o  The D bit of the Flags field MUST be cleared as required by
      [RFC6823].

   o  The I bit and the V bit MUST be set accordingly depending on
      whether RTM capability being advertised is for an IPv4 or an IPv6
      interface.

   Application ID (TBA3) will be assigned from the Application
   Identifiers for TLV 251 IANA registry Section 8.5.  The RTM
   Capability sub-TLV MUST be included in GENINFO TLV in Application
   Specific Information.

4.6.  RSVP-TE Control Plane Operation to Support RTM

   Throughout this document we refer to a node as RTM capable node when
   at least one of its interfaces is RTM capable.  Figure 5 provides an
   example of roles a node may have with respect to RTM capability:

    -----     -----     -----     -----     -----     -----     -----
    | A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G |
    -----     -----     -----     -----     -----     -----     -----

                        Figure 5: RTM capable roles

   o  A is a Boundary Clock (BC) with its egress port in Master state.
      Node A transmits IP encapsulated timing packets whose destination
      IP address is G.

   o  B is the ingress LER for the MPLS LSP and is the first RTM capable
      node.  It creates RTM packets and in each it places a timing
      packet, possibly encrypted, in the Value field and initializes the
      Scratch Pad field with its residence time measurement

   o  C is a transit node that is not RTM capable.  It forwards RTM
      packets without modification.

   o  D is RTM capable transit node.  It updates the Scratch Pad field
      of the RTM packet without updating the timing packet.

   o  E is a transit node that is not RTM capable.  It forwards RTM
      packets without modification.

   o  F is the egress LER and the last RTM capable node.  It processes
      the timing packet carried in the Value field using the value in
      the Scratch Pad field.  It updates the Correction field of the PTP



Mirsky, et al.            Expires July 22, 2017                [Page 10]

Internet-Draft         Residence Time Measurement           January 2017


      message with the value in the Scratch Pad field of the RTM ACH,
      and removes the RTM ACH encapsulation.

   o  G is a Boundary Clock with its ingress port in Slave state.  Node
      G receives PTP messages.

   An ingress node that is configured to perform RTM along a path
   through an MPLS network to an egress node verifies that the selected
   egress node has an interface that supports RTM via the egress node's
   advertisement of the RTM Capability sub-TLV.  In the Path message
   that the ingress node uses to instantiate the LSP to that egress node
   it places LSP_ATTRIBUTES Object [RFC5420] with RTM_SET Attribute Flag
   set Section 8.7 which indicates to the egress node that RTM is
   requested for this LSP.  RTM_SET Attribute Flag SHOULD NOT be set in
   the LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it is known
   that all nodes support RTM, because a node that does not recognize
   RTM_SET Attribute Flag would reject the Path message.

   If egress node receives Path message with RTM_SET Attribute Flag in
   LSP_ATTRIBUTES object, it MUST include initialized RRO [RFC3209] and
   LSP_ATTRIBUTES object where RTM_SET Attribute Flag is set and RTM_SET
   TLV Section 4.7 is initialized.  When Resv message received by
   ingress node the RTM_SET TLV will contain an ordered list, from
   egress node to ingress node, of the RTM capable node along the LSP's
   path.

   After the ingress node receives the Resv, it MAY begin sending RTM
   packets on the LSP's path.  Each RTM packet has its Scratch Pad field
   initialized and its TTL set to expire on the closest downstream RTM
   capable node.

   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
   support RTM.  In this case the RTM_SET TLV and LSP_ATTRIBUTES Object
   MAY be omitted.

4.7.  RTM_SET TLV

   RTM capable interfaces can be recorded via RTM_SET TLV.  The RTM_SET
   sub-object format is of generic Type, Length, Value (TLV), presented
   in Figure 6 .










Mirsky, et al.            Expires July 22, 2017                [Page 11]

Internet-Draft         Residence Time Measurement           January 2017


    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type    |     Length    |I|         Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                             Value                           ~
    |                                                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 6: RTM_SET TLV format

   Type value (TBA4) will be assigned by IANA from its Attributes TLV
   Space sub-registry Section 8.6.

   The Length contains the total length of the sub-object in bytes,
   including the Type and Length fields.

   The I bit flag indicates whether the downstream RTM capable node
   along the LSP is present in the RRO.

   Reserved field must be zeroed on initiation and ignored on receipt.

   The content of an RTM_SET TLV is a series of variable-length sub-
   TLVs.  Only a single RTM_SET can be present in the LSP_ATTRIBUTES
   object.  The sub-TLVs are defined in Section 4.7.1 below.

   The following processing procedures apply to every RTM capable node
   along the LSP that in this paragraph is referred as node for sake of
   brevity.  Each node MUST examine Resv message whether RTM_SET
   Attribute Flag in the LSP_ATTRIBUTES object is set.  If the RTM_SET
   flag set, the node MUST inspect the LSP_ATTRIBUTES object for
   presence of RTM_SET TLV.  If more than one found, then the LSP setup
   MUST fail with generation of the ResvErr message with Error Code
   Duplicate TLV Section 8.8 and Error Value that contains Type value in
   its 8 least significant bits.  If no RTM_SET TLV has been found, then
   the LSP setup MUST fail with generation of the ResvErr message with
   Error Code RTM_SET TLV Absent Section 8.8.  If one RTM_SET TLV has
   been found the node will use the ID of the first node in the RTM_SET
   in conjunction with the RRO to compute the hop count to its
   downstream node with reachable RTM capable interface.  If the node
   cannot find matching ID in RRO, then it MUST try to use ID of the
   next node in the RTM_SET until it finds the match or reaches the end
   of RTM_SET TLV.  If match has been found, the calculated value is
   used by the node as TTL value in outgoing label to reach the next RTM
   capable node on the LSP.  Otherwise, the TTL value MUST be set to
   255.  The node MUST add RTM_SET sub-TLV with the same address it used
   in RRO sub-object at the beginning of the RTM_SET TLV in associated
   outgoing Resv message before forwarding it upstream.  If the



Mirsky, et al.            Expires July 22, 2017                [Page 12]

Internet-Draft         Residence Time Measurement           January 2017


   calculated TTL value been set to 255, as described above, then the I
   flag in node RTM_SET TLV MUST be set to 1 before Resv message
   forwarded upstream.  Otherwise, the I flag MUST be cleared (0).

   The ingress node MAY inspect the I bit flag received in each RTM_SET
   TLV contained in the LSP_ATTRIBUTES object of a received Resv
   message.  Presence of the RTM_SET TLV with I bit field set to 1
   indicates that some RTM nodes along the LSP could be included in the
   calculation of the residence time.  An ingress node MAY choose to
   resignal the LSP to include all RTM nodes or simply notify the user
   via a management interface.

   There are scenarios when some information is removed from an RRO due
   to policy processing (e.g., as may happen between providers) or RRO
   is limited due to size constraints .  Such changes affect the core
   assumption of the method to control processing of RTM packets.  RTM
   SHOULD NOT be used if it is not guaranteed that RRO contains complete
   information.

4.7.1.  RTM_SET Sub-TLVs

   The RTM Set sub-object contains an ordered list, from egress node to
   ingress node, of the RTM capable nodes along the LSP's path.

   The contents of a RTM_SET sub-object are a series of variable-length
   sub-TLVs.  Each sub-TLV has its own Length field.  The Length
   contains the total length of the sub-TLV in bytes, including the Type
   and Length fields.  The Length MUST always be a multiple of 4, and at
   least 8 (smallest IPv4 sub-object).

   Sub-TLVs are organized as a last-in-first-out stack.  The first -out
   sub-TLV relative to the beginning of RTM_SET TLV is considered the
   top.  The last-out sub-TLV is considered the bottom.  When a new sub-
   TLV is added, it is always added to the top.  Only a single RTM_SET
   sub-TLV with the given Value field MUST be present in the RTM_SET
   TLV.  If more than one sub-TLV is found the LSP setup MUST fail with
   the generation of a ResvErr message with the Error Code "Duplicate
   sub-TLV" Section 8.8 and Error Value contains 16-bit value composed
   of (Type of TLV, Type of sub-TLV).

   Three kinds of sub-TLVs for RTM_SET are currently defined.

4.7.1.1.  IPv4 Sub-TLV








Mirsky, et al.            Expires July 22, 2017                [Page 13]

Internet-Draft         Residence Time Measurement           January 2017


    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type     |     Length    |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       IPv4 address                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 7: IPv4 sub-TLV format

   Type

      0x01 IPv4 address

   Length

      The Length contains the total length of the sub-TLV in bytes,
      including the Type and Length fields.  The Length is always 8.

   IPv4 address

      A 32-bit unicast host address.

   Reserved

      Zeroed on initiation and ignored on receipt.

4.7.1.2.  IPv6 Sub-TLV

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type     |     Length    |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                             |
    |                         IPv6 address                        |
    |                                                             |
    |                                                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 8: IPv6 sub-TLV format

   Type

      0x02 IPv6 address

   Length




Mirsky, et al.            Expires July 22, 2017                [Page 14]

Internet-Draft         Residence Time Measurement           January 2017


      The Length contains the total length of the sub-TLV in bytes,
      including the Type and Length fields.  The Length is always 20.

   IPv6 address

      A 128-bit unicast host address.

   Reserved

      Zeroed on initiation and ignored on receipt.

4.7.1.3.  Unnumbered Interface Sub-TLV

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type     |     Length    |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Node ID                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Interface ID                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 9: IPv4 sub-TLV format

   Type

      0x03 Unnumbered interface

   Length

      The Length contains the total length of the sub-TLV in bytes,
      including the Type and Length fields.  The Length is always 12.

   Node ID

      The Node ID interpreted as Router ID as discussed in the Section 2
      [RFC3477].

   Interface ID

      The identifier assigned to the link by the node specified by the
      Node ID.

   Reserved

      Zeroed on initiation and ignored on receipt.




Mirsky, et al.            Expires July 22, 2017                [Page 15]

Internet-Draft         Residence Time Measurement           January 2017


5.  Data Plane Theory of Operation

   After instantiating an LSP for a path using RSVP-TE [RFC3209] as
   described in Section 4.6, ingress node MAY begin sending RTM packets
   to the first downstream RTM capable node on that path.  Each RTM
   packet has its Scratch Pad field initialized and its TTL set to
   expire on the next downstream RTM-capable node.  Each RTM-capable
   node on the explicit path receives an RTM packet and records the time
   at which it receives that packet at its ingress interface as well as
   the time at which it transmits that packet from its egress interface;
   this should be done as close to the physical layer as possible to
   ensure precise accuracy in time determination.  The RTM-capable node
   determines the difference between those two times; for one-step
   operation, this difference is determined just prior to or while
   sending the packet, and the RTM-capable egress interface adds it to
   the value in the Scratch Pad field of the message in progress.  Note,
   for the purpose of calculating a residence time, a common free
   running clock synchronizing all the involved interfaces may be
   sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond
   error for residence time on the order of 1 millisecond.

   For two-step operation, the difference between packet arrival time
   (at an ingress interface) and subsequent departure time (from an
   egress interface) is determined at some later time prior to sending a
   subsequent follow-up message, so that this value can be used to
   update the correctionField in the follow-up message.

   See Section 7 for further details on the difference between one-step
   and two-step operation.

   The last RTM-capable node on the LSP MAY then use the value in the
   Scratch Pad field to perform time correction, if there is no follow-
   up message.  For example, the egress node may be a PTP Boundary Clock
   synchronized to a Master Clock and will use the value in the Scratch
   Pad field to update PTP's correctionField.

6.  Applicable PTP Scenarios

   The proposed approach can be directly integrated in a PTP network
   based on the IEEE 1588 delay request-response mechanism.  The RTM
   capable node nodes act as end-to-end transparent clocks, and
   typically boundary clocks, at the edges of the MPLS network, use the
   value in the Scratch Pad field to update the correctionField of the
   corresponding PTP event packet prior to performing the usual PTP
   processing.






Mirsky, et al.            Expires July 22, 2017                [Page 16]

Internet-Draft         Residence Time Measurement           January 2017


7.  one-step Clock and two-step Clock Modes

   one-step mode refers to the mode of operation where an egress
   interface updates the correctionField value of an original event
   message. two-step mode refers to the mode of operation where this
   update is made in a subsequent follow-up message.

   Processing of the follow-up message, if present, requires the
   downstream end-point to wait for the arrival of the follow-up message
   in order to combine correctionField values from both the original
   (event) message and the subsequent (follow-up) message.  In a similar
   fashion, each two-step node needs to wait for the related follow-up
   message, if there is one, in order to update that follow-up message
   (as opposed to creating a new one.  Hence the first node that uses
   two-step mode MUST do two things:

   1.  Mark the original event message to indicate that a follow-up
       message will be forthcoming.  This is necessary in order to

          Let any subsequent two-step node know that there is already a
          follow-up message, and

          Let the end-point know to wait for a follow-up message;

   2.  Create a follow-up message in which to put the RTM determined as
       an initial correctionField value.

   IEEE 1588v2 [IEEE.1588.2008] defines this behavior for PTP messages.

   Thus, for example, with reference to the PTP protocol, the PTPType
   field identifies whether the message is a Sync message, Follow_up
   message, Delay_Req message, or Delay_Resp message.  The 10 octet long
   Port ID field contains the identity of the source port
   [IEEE.1588.2008], that is, the specific PTP port of the boundary
   clock connected to the MPLS network.  The Sequence ID is the sequence
   ID of the PTP message carried in the Value field of the message.

   PTP messages also include a bit that indicates whether or not a
   follow-up message will be coming.  This bit, once it is set by a two-
   step mode device, MUST stay set accordingly until the original and
   follow-up messages are combined by an end-point (such as a Boundary
   Clock).

   Thus, an RTM packet, containing residence time information relating
   to an earlier packet, also contains information identifying that
   earlier packet.





Mirsky, et al.            Expires July 22, 2017                [Page 17]

Internet-Draft         Residence Time Measurement           January 2017


   For compatibility with PTP, RTM (when used for PTP packets) must
   behave in a similar fashion.  To do this, a two-step RTM capable
   egress interface will need to examine the S-bit in the Flags field of
   the PTP sub-TLV (for RTM messages that indicate they are for PTP) and
   - if it is clear (set to zero), it MUST set it and create a follow-up
   PTP Type RTM message.  If the S bit is already set, then the RTM
   capable node MUST wait for the RTM message with the PTP type of
   follow-up and matching originator and sequence number to make the
   corresponding residence time update to the Scratch Pad field.

   In practice an RTM operating according to two-step clock behaves like
   a two-steps transparent clock.

   A one-step capable RTM node MAY elect to operate in either one-step
   mode (by making an update to the Scratch Pad field of the RTM message
   containing the PTP even message), or in two-step mode (by making an
   update to the Scratch Pad of a follow-up message when its presence is
   indicated), but MUST NOT do both.

   Two main subcases can be identified for an RTM node operating as a
   two-step clock:

   A) If any of the previous RTM capable node or the previous PTP clock
   (e.g. the BC connected to the first node), is a two-step clock, the
   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
   downstream direction), if the local RTM-capable node is also
   operating as a two-step clock.  This RTM packet carries the related
   accumulated residence time and the appropriate values of the Sequence
   Id and Port Id (the same identifiers carried in the packet processed)
   and the Two-step Flag set to 1.

   Note that the fact that an upstream RTM-capable node operating in the
   two-step mode has created a follow-up message does not require any
   subsequent RTM capable node to also operate in the two-step mode, as
   long as that RTM-capable node forwards the follow-up message on the
   same LSP on which it forwards the corresponding previous message.

   A one-step capable RTM node MAY elect to update the RTM follow-up
   message as if it were operating in two-step mode, however, it MUST
   NOT update both messages.

   A PTP event packet (sync) is carried in the RTM packet in order for
   an RTM node to identify that residence time measurement must be
   performed on that specific packet.






Mirsky, et al.            Expires July 22, 2017                [Page 18]

Internet-Draft         Residence Time Measurement           January 2017


   To handle the residence time of the Delay request message on the
   upstream direction, an RTM packet must be created to carry the
   residence time on the associated downstream Delay Resp message.

   The last RTM node of the MPLS network in addition to update the
   correctionField of the associated PTP packet, must also properly
   handle the two-step flag of the PTP packets.

   B) When the PTP network connected to the MPLS and RTM node, operates
   in one-step clock mode, the associated RTM packet must be created by
   the RTM node itself.  The associated RTM packet including the PTP
   event packet needs now to indicate that a follow up message will be
   coming.

   The last RTM node of the LSP, if it receives an RTM message with a
   PTP payload indicating a follow-up message will be forthcoming, must
   generate a follow-up message and properly set the two-step flag of
   the PTP packets.

8.  IANA Considerations

8.1.  New RTM G-ACh

   IANA is requested to reserve a new G-ACh as follows:

          +-------+----------------------------+---------------+
          | Value |        Description         | Reference     |
          +-------+----------------------------+---------------+
          | TBA1  | Residence Time Measurement | This document |
          +-------+----------------------------+---------------+

                  Table 1: New Residence Time Measurement

8.2.  New RTM TLV Registry

   IANA is requested to create sub-registry in Generic Associated
   Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry".
   All code points in the range 0 through 127 in this registry shall be
   allocated according to the "IETF Review" procedure as specified in
   [RFC5226] . Code points in the range 128 through 191 in this registry
   shall be allocated according to the "First Come First Served"
   procedure as specified in [RFC5226].  This document defines the
   following new values RTM TLV type s:








Mirsky, et al.            Expires July 22, 2017                [Page 19]

Internet-Draft         Residence Time Measurement           January 2017


       +-----------+-------------------------------+---------------+
       | Value     |          Description          | Reference     |
       +-----------+-------------------------------+---------------+
       | 0         |            Reserved           | This document |
       | 1         |           No payload          | This document |
       | 2         | PTPv2, Ethernet encapsulation | This document |
       | 3         |   PTPv2, IPv4 Encapsulation   | This document |
       | 4         |   PTPv2, IPv6 Encapsulation   | This document |
       | 5         |              NTP              | This document |
       | 6-127     |           Unassigned          |               |
       | 128 - 191 |           Unassigned          |               |
       | 192 - 254 |          Private Use          | This document |
       | 255       |            Reserved           | This document |
       +-----------+-------------------------------+---------------+

                           Table 2: RTM TLV Type

8.3.  New RTM Sub-TLV Registry

   IANA is requested to create sub-registry in MPLS RTM TLV Registry,
   requested in Section 8.2, called "MPLS RTM Sub-TLV Registry".  All
   code points in the range 0 through 127 in this registry shall be
   allocated according to the "IETF Review" procedure as specified in
   [RFC5226].  Code points in the range 128 through 191 in this registry
   shall be allocated according to the "First Come First Served"
   procedure as specified in [RFC5226].  This document defines the
   following new values RTM sub-TLV types:

                +-----------+-------------+---------------+
                | Value     | Description | Reference     |
                +-----------+-------------+---------------+
                | 0         |   Reserved  | This document |
                | 1         |     PTP     | This document |
                | 2-127     |  Unassigned |               |
                | 128 - 191 |  Unassigned |               |
                | 192 - 254 | Private Use | This document |
                | 255       |   Reserved  | This document |
                +-----------+-------------+---------------+

                         Table 3: RTM Sub-TLV Type

8.4.  RTM Capability sub-TLV in OSPFv2

   IANA is requested to assign a new type for RTM Capability sub-TLV
   from OSPFv2 Extended Link TLV Sub-TLVs registry as follows:






Mirsky, et al.            Expires July 22, 2017                [Page 20]

Internet-Draft         Residence Time Measurement           January 2017


                +-------+----------------+---------------+
                | Value |  Description   | Reference     |
                +-------+----------------+---------------+
                | TBA2  | RTM Capability | This document |
                +-------+----------------+---------------+

                      Table 4: RTM Capability sub-TLV

8.5.  IS-IS RTM Application ID

   IANA is requested to assign a new Application ID for RTM from the
   Application Identifiers for TLV 251 registry as follows:

                  +-------+-------------+---------------+
                  | Value | Description | Reference     |
                  +-------+-------------+---------------+
                  | TBA3  |     RTM     | This document |
                  +-------+-------------+---------------+

                     Table 5: IS-IS RTM Application ID

8.6.  RTM_SET Sub-object RSVP Type and sub-TLVs

   IANA is requested to assign a new Type for RTM_SET sub-object from
   Attributes TLV Space sub-registry as follows:

   +-----+------------+-----------+---------------+---------+----------+
   | Typ |    Name    |  Allowed  | Allowed  on   | Allowed | Referenc |
   | e   |            | on  LSP_A | LSP_REQUIRED_ |  on LSP | e        |
   |     |            | TTRIBUTES |   ATTRIBUTES  | Hop Att |          |
   |     |            |           |               | ributes |          |
   +-----+------------+-----------+---------------+---------+----------+
   | TBA |  RTM_SET   |    Yes    |       No      |    No   | This     |
   | 4   | sub-object |           |               |         | document |
   +-----+------------+-----------+---------------+---------+----------+

                     Table 6: RTM_SET Sub-object Type

   IANA requested to create new sub-registry for sub-TLV types of
   RTM_SET sub-object.  All code points in the range 0 through 127 in
   this registry shall be allocated according to the "IETF Review"
   procedure as specified in [RFC5226] . Code points in the range 128
   through 191 in this registry shall be allocated according to the
   "First Come First Served" procedure as specified in [RFC5226].  This
   document defines the following new values of RTM_SET object sub-
   object types:





Mirsky, et al.            Expires July 22, 2017                [Page 21]

Internet-Draft         Residence Time Measurement           January 2017


           +-----------+----------------------+---------------+
           | Value     |     Description      | Reference     |
           +-----------+----------------------+---------------+
           | 0         |       Reserved       | This document |
           | 1         |     IPv4 address     | This document |
           | 2         |     IPv6 address     | This document |
           | 3         | Unnumbered interface | This document |
           | 4-127     |      Unassigned      |               |
           | 128 - 191 |      Unassigned      |               |
           | 192 - 254 |     Private Use      | This document |
           | 255       |       Reserved       | This document |
           +-----------+----------------------+---------------+

                 Table 7: RTM_SET object sub-object types

8.7.  RTM_SET Attribute Flag

   IANA is requested to assign new flag from Attribute Flags registry

   +-----+--------+-----------+------------+-----+-----+---------------+
   | Bit |  Name  | Attribute | Attribute  | RRO | ERO | Reference     |
   | No  |        |   Flags   | Flags Resv |     |     |               |
   |     |        |    Path   |            |     |     |               |
   +-----+--------+-----------+------------+-----+-----+---------------+
   | TBA | RTM_SE |    Yes    |    Yes     |  No |  No | This document |
   | 5   |   T    |           |            |     |     |               |
   +-----+--------+-----------+------------+-----+-----+---------------+

                      Table 8: RTM_SET Attribute Flag

8.8.  New Error Codes

   IANA is requested to assign new Error Codes from Error Codes and
   Globally-Defined Error Value Sub-Codes registry

            +------------+--------------------+---------------+
            | Error Code |      Meaning       | Reference     |
            +------------+--------------------+---------------+
            | TBA6       |   Duplicate TLV    | This document |
            | TBA7       | Duplicate sub-TLV  | This document |
            | TBA8       | RTM_SET TLV Absent | This document |
            +------------+--------------------+---------------+

                         Table 9: New Error Codes







Mirsky, et al.            Expires July 22, 2017                [Page 22]

Internet-Draft         Residence Time Measurement           January 2017


9.  Security Considerations

   Routers that support Residence Time Measurement are subject to the
   same security considerations as defined in [RFC5586] .

   In addition - particularly as applied to use related to PTP - there
   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
   PTP messages.  This is necessary as these nodes are expected to
   correctly modify specific content of the data in PTP messages and
   proper operation of the protocol depends on this ability.

   As a result, the content of the PTP-related data in RTM messages that
   will be modified by intermediate nodes cannot be authenticated, and
   the additional information that must be accessible for proper
   operation of PTP one-step and two-step modes MUST be accessible to
   intermediate nodes (i.e. - MUST NOT be encrypted in a manner that
   makes this data inaccessible).

   While it is possible for a supposed compromised node to intercept and
   modify the G-ACh content, this is an issue that exists for nodes in
   general - for any and all data that may be carried over an LSP - and
   is therefore the basis for an additional presumed trust model
   associated with existing LSPs and nodes.

   The ability for potentially authenticating and/or encrypting RTM and
   PTP data that is not needed by intermediate RTM/PTP-capable nodes is
   for further study.

   Security requirements of time protocols are provided in RFC 7384
   [RFC7384].

10.  Acknowledgments

   Authors want to thank Loa Andersson, Lou Berger and Acee Lindem for
   their thorough reviews, thoughtful comments and, most of all,
   patience.

11.  References

11.1.  Normative References

   [IEEE.1588.2008]
              "Standard for a Precision Clock Synchronization Protocol
              for Networked Measurement and Control Systems",
              IEEE Standard 1588, July 2008.





Mirsky, et al.            Expires July 22, 2017                [Page 23]

Internet-Draft         Residence Time Measurement           January 2017


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <http://www.rfc-editor.org/info/rfc3209>.

   [RFC3477]  Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
              in Resource ReSerVation Protocol - Traffic Engineering
              (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003,
              <http://www.rfc-editor.org/info/rfc3477>.

   [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
              Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
              February 2006, <http://www.rfc-editor.org/info/rfc4385>.

   [RFC5085]  Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
              Circuit Connectivity Verification (VCCV): A Control
              Channel for Pseudowires", RFC 5085, DOI 10.17487/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.,
              "MPLS Generic Associated Channel", RFC 5586,
              DOI 10.17487/RFC5586, June 2009,
              <http://www.rfc-editor.org/info/rfc5586>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <http://www.rfc-editor.org/info/rfc5905>.

   [RFC6423]  Li, H., Martini, L., He, J., and F. Huang, "Using the
              Generic Associated Channel Label for Pseudowire in the
              MPLS Transport Profile (MPLS-TP)", RFC 6423,
              DOI 10.17487/RFC6423, November 2011,
              <http://www.rfc-editor.org/info/rfc6423>.





Mirsky, et al.            Expires July 22, 2017                [Page 24]

Internet-Draft         Residence Time Measurement           January 2017


   [RFC6823]  Ginsberg, L., Previdi, S., and M. Shand, "Advertising
              Generic Information in IS-IS", RFC 6823,
              DOI 10.17487/RFC6823, December 2012,
              <http://www.rfc-editor.org/info/rfc6823>.

   [RFC7684]  Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
              Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
              Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
              2015, <http://www.rfc-editor.org/info/rfc7684>.

11.2.  Informative References

   [I-D.ietf-ospf-ospfv3-lsa-extend]
              Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
              LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-13
              (work in progress), October 2016.

   [I-D.ietf-tictoc-1588overmpls]
              Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
              Montini, "Transporting Timing messages over MPLS
              Networks", draft-ietf-tictoc-1588overmpls-07 (work in
              progress), October 2015.

   [RFC4202]  Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
              in Support of Generalized Multi-Protocol Label Switching
              (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
              <http://www.rfc-editor.org/info/rfc4202>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <http://www.rfc-editor.org/info/rfc6374>.

   [RFC7384]  Mizrahi, T., "Security Requirements of Time Protocols in
              Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
              October 2014, <http://www.rfc-editor.org/info/rfc7384>.

Authors' Addresses

   Greg Mirsky
   ZTE Corp.

   Email: gregimirsky@xxxxxxxxx



Mirsky, et al.            Expires July 22, 2017                [Page 25]

Internet-Draft         Residence Time Measurement           January 2017


   Stefano Ruffini
   Ericsson

   Email: stefano.ruffini@xxxxxxxxxxxx


   Eric Gray
   Ericsson

   Email: eric.gray@xxxxxxxxxxxx


   John Drake
   Juniper Networks

   Email: jdrake@xxxxxxxxxxx


   Stewart Bryant
   Huawei

   Email: stewart.bryant@xxxxxxxxx


   Alexander Vainshtein
   ECI Telecom

   Email: Alexander.Vainshtein@xxxxxxxxxxx























Mirsky, et al.            Expires July 22, 2017                [Page 26]
Title: Diff: draft-ietf-mpls-residence-time-12.txt - draft-ietf-mpls-residence-time-13.txt
< draft-ietf-mpls-residence-time-12.txt   draft-ietf-mpls-residence-time-13.txt >
MPLS Working Group G. Mirsky MPLS Working Group G. Mirsky
Internet-Draft Independent Internet-Draft ZTE Corp.
Intended status: Standards Track S. Ruffini Intended status: Standards Track S. Ruffini
Expires: June 16, 2017 E. Gray Expires: July 22, 2017 E. Gray
Ericsson Ericsson
J. Drake J. Drake
Juniper Networks Juniper Networks
S. Bryant S. Bryant
Independent Huawei
A. Vainshtein A. Vainshtein
ECI Telecom ECI Telecom
December 13, 2016 January 18, 2017
Residence Time Measurement in MPLS network Residence Time Measurement in MPLS network
draft-ietf-mpls-residence-time-12 draft-ietf-mpls-residence-time-13
Abstract Abstract
This document specifies G-ACh based Residence Time Measurement and This document specifies new Generic Associated Channel for Residence
how it can be used by time synchronization protocols being Time Measurement and how it can be used by time synchronization
transported over MPLS domain. protocols being 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
taken into account in applying the value included in a PTP event taken into account in applying the value included in a Precision Time
message. Protocol event message.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 16, 2017. This Internet-Draft will expire on July 22, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 40 skipping to change at page 2, line 40
4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7
4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8
4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9 4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9
4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9 4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9
4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 9 4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 9
4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10 4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10
4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11 4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11
4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 13 4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 13
5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 16 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 16
6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 16 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 16
7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 17 7. one-step Clock and two-step Clock Modes . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19 8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19
8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19 8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19
8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20 8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20
8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20 8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20
8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21 8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21
8.6. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21 8.6. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21
8.7. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22 8.7. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22
8.8. New Error Codes . . . . . . . . . . . . . . . . . . . . . 22 8.8. New Error Codes . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 3, line 22 skipping to change at page 3, line 22
[IEEE.1588.2008] define timing messages that can be used to [IEEE.1588.2008] define timing messages that can be used to
synchronize clocks across a network domain. Measurement of the synchronize clocks across a network domain. Measurement of the
cumulative time one of these timing messages spends transiting the cumulative time one of these timing messages spends transiting the
nodes on the path from ingress node to egress node is termed nodes on the path from ingress node to egress node is termed
Residence Time and it is used to improve the accuracy of clock Residence Time and it is used to improve the accuracy of clock
synchronization. (I.e., it is the sum of the difference between the synchronization. (I.e., it is the sum of the difference between the
time of receipt at an ingress interface and the time of transmission time of receipt at an ingress interface and the time of transmission
from an egress interface for each node along the path from ingress from an egress interface for each node along the path from ingress
node to egress node.) This document defines a new Generic Associated node to egress node.) This document defines a new Generic Associated
Channel (G-ACh) value and an associated residence time measurement Channel (G-ACh) value and an associated residence time measurement
(RTM) packet that can be used in a Multi-Protocol Label Switching (RTM) message that can be used in a Multi-Protocol Label Switching
(MPLS) network to measure residence time over a Label Switched Path (MPLS) network to measure residence time over a Label Switched Path
(LSP). (LSP).
Although it is possible to use RTM over an LSP instantiated using Although it is possible to use RTM over an LSP instantiated using
LDP, that is outside the scope of this document. Rather, this LDP, that is outside the scope of this document. Rather, this
document describes RTM over an LSP signaled using RSVP-TE [RFC3209] document describes RTM over an LSP signaled using RSVP-TE [RFC3209]
because the LSP's path can be either explicitly specified or because the LSP's path can be either explicitly specified or
determined during signaling. determined during signaling.
Comparison with alternative proposed solutions such as Comparison with alternative proposed solutions such as
skipping to change at page 4, line 34 skipping to change at page 4, line 34
2. Residence Time Measurement 2. Residence Time Measurement
Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be
used to measure one-way or two-way end-to-end propagation delay over used to measure one-way or two-way end-to-end propagation delay over
LSP or PW. But these measurements are insufficient for use in some LSP or PW. But these measurements are insufficient for use in some
applications, for example, time synchronization across a network as applications, for example, time synchronization across a network as
defined in the Precision Time Protocol (PTP). In PTPv2 defined in the Precision Time Protocol (PTP). In PTPv2
[IEEE.1588.2008] residence times is accumulated in the [IEEE.1588.2008] residence times is accumulated in the
correctionField of the PTP event message, as defined in correctionField of the PTP event message, as defined in
[IEEE.1588.2008], or in the associated follow-up message (or [IEEE.1588.2008] and referred as case of one-step clocks, or in the
Delay_Resp message associated with the Delay_Req message) in case of associated follow-up message (or Delay_Resp message associated with
two-step clocks (see the detailed discussion in Section 7). the Delay_Req message) in case of two-step clocks (see the detailed
discussion in Section 7).
IEEE 1588 uses this residence time to correct the transit time from IEEE 1588 uses this residence time to correct the transit time from
ingress node to egress node, effectively making the transit nodes ingress node to egress node, effectively making the transit nodes
transparent. transparent.
This document proposes a mechanism that can be used as one of types This document proposes a mechanism that can be used as one of types
of on-path support for a clock synchronization protocol or to perform of on-path support for a clock synchronization protocol or to perform
one-way measurement of residence time. The proposed mechanism one-way measurement of residence time. The proposed mechanism
accumulates residence time from all nodes that support this extension accumulates residence time from all nodes that support this extension
along the path of a particular LSP in Scratch Pad field of an RTM along the path of a particular LSP in Scratch Pad field of an RTM
packet Figure 1. This value can then be used by the egress node to message Figure 1. This value can then be used by the egress node to
update, for example, the correctionField of the PTP event packet update, for example, the correctionField of the PTP event packet
carried within the RTM packet prior to performing its PTP processing. carried within the RTM message prior to performing its PTP
processing.
3. G-ACh for Residence Time Measurement 3. G-ACh for Residence Time Measurement
RFC 5586 [RFC5586] and RFC 6423 [RFC6423] define the G-ACh to extend RFC 5586 [RFC5586] and RFC 6423 [RFC6423] define the G-ACh to extend
the applicability of the PW Associated Channel (ACH) [RFC5085] to the applicability of the PW Associated Channel (ACH) [RFC5085] to
LSPs. G-ACh provides a mechanism to transport OAM and other control LSPs. G-ACh provides a mechanism to transport OAM and other control
messages over an LSP. Processing of these messages by selected messages over an LSP. Processing of these messages by selected
transit nodes is controlled by the use of the Time-to-Live (TTL) transit nodes is controlled by the use of the Time-to-Live (TTL)
value in the MPLS header of these messages. value in the MPLS header of these messages.
The packet format for Residence Time Measurement (RTM) is presented The message format for Residence Time Measurement (RTM) is presented
in Figure 1 in Figure 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | RTM G-ACh | |0 0 0 1|Version| Reserved | RTM G-ACh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Scratch Pad | | Scratch Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTM G-ACh packet format for Residence Time Measurement Figure 1: RTM G-ACh message 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 (TBA1) to be allocated by IANA, o The RTM G-ACh field, value (TBA1) to be allocated by IANA,
identifies the packet as such. identifies the packet as such.
o The Scratch Pad field is 8 octets in length. It is used to o The Scratch Pad field is 8 octets in length. It is used to
accumulate the residence time spent in each RTM capable node accumulate the residence time spent in each RTM capable node
transited by the packet on its path from ingress node to egress transited by the packet on its path from ingress node to egress
node. The first RTM-capable node MUST initialize the Scratch Pad node. The first RTM-capable node MUST initialize the Scratch Pad
field with its residence time measurement. Its format is IEEE field with its residence time measurement. Its format is IEEE
double precision and its units are nanoseconds. Note that double precision and its units are nanoseconds. Note that
depending on whether the timing procedure is one-step or two-step depending on whether the timing procedure is one-step or two-step
operation (Section 7), the residence time is either for the timing operation (Section 7), the residence time is either for the timing
packet carried in the Value field of this RTM packet or for an packet carried in the Value field of this RTM message or for an
associated timing packet carried in the Value field of another RTM associated timing packet carried in the Value field of another RTM
packet. message.
o The Type field identifies the type and encapsulation of a timing o The Type field identifies the type and encapsulation of a timing
packet carried in the Value field, e.g., NTP [RFC5905] or PTP packet carried in the Value field, e.g., NTP [RFC5905] or PTP
[IEEE.1588.2008]. IANA will be asked to create a sub-registry in [IEEE.1588.2008]. This document asks IANA to create a sub-
Generic Associated Channel (G-ACh) Parameters Registry called registry in Generic Associated Channel (G-ACh) Parameters Registry
"MPLS RTM TLV Registry". called "MPLS RTM TLV Registry" Section 8.2.
o The Length field contains the length, in octets , of the of the o The Length field contains the length, in octets, of the of the
timing packet carried in the Value field. timing packet carried in the Value field.
o The optional Value field MAY carry a packet of the time o The optional Value field MAY carry a packet of the time
synchronization protocol identified by Type field. It is synchronization protocol identified by Type field. It is
important to note that the packet may be authenticated or important to note that the packet may be authenticated or
encrypted and carried over LSP edge to edge unchanged while the encrypted and carried over LSP edge to edge unchanged while the
residence time is accumulated in the Scratch Pad field. residence time is accumulated in the Scratch Pad field.
o The TLV MUST be included in the RTM message, even if the length of o The TLV MUST be included in the RTM message, even if the length of
the Value field is zero. the Value field is zero.
3.1. PTP Packet Sub-TLV 3.1. PTP Packet Sub-TLV
Figure 2 presents format of a PTP sub-TLV that MUST be included in Figure 2 presents format of a PTP sub-TLV that MUST be included in
the Value field of an RTM packet preceding the carried timing packet the Value field of an RTM message preceding the carried timing packet
when the timing packet is PTP. when the timing packet is PTP.
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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |PTPType| | Flags |PTPType|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID | | Port ID |
skipping to change at page 7, line 12 skipping to change at page 7, line 12
where Flags field has format where Flags field has format
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flags field format of PTP Packet Sub-TLV Figure 3: Flags field format of PTP Packet Sub-TLV
o The Type field identifies PTP packet sub-TLV and is set 1 o The Type field identifies PTP packet sub-TLV and is set to 1
according to Section 8.3. according to Section 8.3.
o The Length field of the PTP sub-TLV contains the number of octets o The Length field of the PTP sub-TLV contains the number of octets
of the Value field and MUST be 20. of the Value field and MUST be 20.
o The Flags field currently defines one bit, the S-bit, that defines o The Flags field currently defines one bit, the S-bit, that defines
whether the current message has been processed by a 2-step node, whether the current message has been processed by a two-step node,
where the flag is cleared if the message has been handled where the flag is cleared if the message has been handled
exclusively by 1-step nodes and there is no follow-up message, and exclusively by one-step nodes and there is no follow-up message,
set if there has been at least one 2-step node and a follow-up and set if there has been at least one two-step node and a follow-
message is forthcoming. up message is forthcoming.
o The PTPType indicates the type of PTP packet carried in the TLV. o The PTPType indicates the type of PTP packet carried in the TLV.
PTPType is the messageType field of the PTPv2 packet whose values PTPType is the messageType field of the PTPv2 packet whose values
are defined in the Table 19 [IEEE.1588.2008]. are defined in Table 19 of [IEEE.1588.2008].
o The 10 octets long Port ID field contains the identity of the o The 10 octets long Port ID field contains the identity of the
source port. source port.
o The Sequence ID is the sequence ID of the PTP message carried in o The Sequence ID is the sequence ID of the PTP message carried in
the Value field of the message. the Value field of the message.
4. Control Plane Theory of Operation 4. Control Plane Theory of Operation
The operation of RTM depends upon TTL expiry to deliver an RTM packet The operation of RTM depends upon TTL expiry to deliver an RTM packet
skipping to change at page 8, line 5 skipping to change at page 8, line 5
of an RTM packet at the next node with RTM capable interfaces. of an RTM packet at the next node with RTM capable interfaces.
4.1. RTM Capability 4.1. RTM Capability
Note that the RTM capability of a node is with respect to the pair of Note that the 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 (one-step or two-step) of any pair of interfaces
is then determined by the capability of the egress interface. For is then determined by the capability of the egress interface. For
both modes, the egress interface implementation MUST be able to both modes, the egress interface implementation MUST be able to
determine the precise departure time of the same packet and determine determine the precise departure time of the same packet and determine
from this, and the arrival time information from the corresponding from this, and the arrival time information from the corresponding
ingress interface, the difference representing the residence time for ingress interface, the difference representing the residence time for
the packet. the packet.
An interface with the ability to do this and update the associated An interface with the ability to do this and update the associated
Scratch Pad in real-time (i.e. while the packet is being forwarded) Scratch Pad in real-time (i.e. while the packet is being forwarded)
is said to be 1-step capable. is said to be one-step capable.
Hence while both ingress and egress interfaces are required to Hence while both ingress and egress interfaces are required to
support RTM for the pair to be RTM-capable, it is the egress support RTM for the pair to be RTM-capable, it is the egress
interface that determines whether or not the node is 1-step or 2-step interface that determines whether or not the node is one-step or two-
capable with respect to the interface-pair. step capable with respect to the interface-pair.
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 a node uses an IGP to carry the RTM capability sub-TLV, the sub- When a node 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 (one-step or two-step) associated
with egress interfaces. with egress interfaces.
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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTM | Reserved | | RTM | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RTM Capability sub-TLV Figure 4: RTM Capability sub-TLV
o Type value (TBA2) will be assigned by IANA from appropriate o Type value (TBA2) will be assigned by IANA from appropriate
registry for OSPFv2. registry for OSPFv2 Section 8.4.
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 9, line 27 skipping to change at page 9, line 27
[RFC4202] explains that the Interface Switching Capability Descriptor [RFC4202] explains that the Interface Switching Capability Descriptor
describes switching capability of an interface. For bi-directional describes switching capability of an interface. For bi-directional
links, the switching capabilities of an interface are defined to be links, the switching capabilities of an interface are defined to be
the same in either direction. I.e., for data entering the node the same in either direction. I.e., for data entering the node
through that interface and for data leaving the node through that through that interface and for data leaving the node through that
interface. That principle SHOULD be applied when a node advertises interface. That principle SHOULD be applied when a node advertises
RTM Capability. RTM Capability.
A node that supports RTM MUST be able to act in two-step mode and MAY A node that supports RTM MUST be able to act in two-step mode and MAY
also support one-step RTM mode. Detailed discussion of one-step and also support one-step RTM mode. Detailed discussion of one-step and
two-step RTM modes in Section 7. two-step RTM modes appears in Section 7.
4.3. RTM Capability Advertisement in OSPFv2 4.3. RTM Capability Advertisement in OSPFv2
The capability to support RTM on a particular link (interface) is The capability to support RTM on a particular link (interface) is
advertised in the OSPFv2 Extended Link Opaque LSA described in advertised in the OSPFv2 Extended Link Opaque LSA described in
Section 3 [RFC7684] via the RTM Capability sub-TLV. Section 3 [RFC7684] via the RTM Capability sub-TLV.
Its Type value will be assigned by IANA from the OSPF Extended Link Its Type value will be assigned by IANA from the OSPF Extended Link
TLV Sub-TLVs registry that will be created per [RFC7684] request. TLV Sub-TLVs registry Section 8.4, that will be created per [RFC7684]
request.
4.4. RTM Capability Advertisement in OSPFv3 4.4. RTM Capability Advertisement in OSPFv3
The capability to support RTM on a particular link (interface) can be The capability to support RTM on a particular link (interface) can be
advertised in OSPFv3 using LSA extensions as described in advertised in OSPFv3 using LSA extensions as described in
[I-D.ietf-ospf-ospfv3-lsa-extend]. Exact use of OSPFv3 LSA [I-D.ietf-ospf-ospfv3-lsa-extend]. Exact use of OSPFv3 LSA
extensions is for further study. extensions is for further study.
4.5. RTM Capability Advertisement in IS-IS 4.5. RTM Capability Advertisement in IS-IS
skipping to change at page 10, line 16 skipping to change at page 10, line 16
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 is for an IPv4 or an IPv6 whether RTM capability being advertised is for an IPv4 or an IPv6
interface. interface.
Application ID (TBA3) 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 Section 8.5. The RTM
MUST be included in GENINFO TLV in Application Specific Information. Capability sub-TLV MUST be included in GENINFO TLV in Application
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 a node as RTM capable node when Throughout this document we refer to a node as RTM capable node 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 roles a node may have with respect to RTM capability: example of roles a node may have with respect to RTM capability:
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
| A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G | | A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G |
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
skipping to change at page 10, line 43 skipping to change at page 10, line 44
IP address is G. IP address is G.
o B is the ingress LER for the MPLS LSP and is the first RTM capable o B is the ingress LER for the MPLS LSP and is the first RTM capable
node. It creates RTM packets and in each it places a timing node. It creates RTM packets and in each it places a timing
packet, possibly encrypted, in the Value field and initializes the packet, possibly encrypted, in the Value field and initializes the
Scratch Pad field with its residence time measurement Scratch Pad field with its residence time measurement
o C is a transit node that is not RTM capable. It forwards RTM o C is a transit node that is not RTM capable. It forwards RTM
packets without modification. packets without modification.
o D is RTM capable transit node. It updates the Scratch Pad filed o D is RTM capable transit node. It updates the Scratch Pad field
of the RTM packet without updating of the timing packet. of the RTM packet without updating the timing packet.
o E is a transit node that is not RTM capable. It forwards RTM o E is a transit node that is not RTM capable. It forwards RTM
packets without modification. packets without modification.
o F is the egress LER and the last RTM capable node. It processes o F is the egress LER and the last RTM capable node. It processes
the timing packet carried in the Value field using the value in the timing packet carried in the Value field using the value in
the Scratch Pad field. It updates the Correction field of the PTP the Scratch Pad field. It updates the Correction field of the PTP
message with the value in the Scratch Pad field of the RTM ACH, message with the value in the Scratch Pad field of the RTM ACH,
and removes the RTM ACH encapsulation. and removes the RTM ACH encapsulation.
skipping to change at page 12, line 17 skipping to change at page 12, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |I| Reserved | | Type | Length |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RTM_SET TLV format Figure 6: RTM_SET TLV format
Type value (TBA4) will be assigned by IANA from its Attributes TLV Type value (TBA4) will be assigned by IANA from its Attributes TLV
Space sub-registry. Space sub-registry Section 8.6.
The Length contains the total length of the sub-object in bytes, The Length contains the total length of the sub-object in bytes,
including the Type and Length fields. including the Type and Length fields.
The I bit flag indicates whether the downstream RTM capable node The I bit flag indicates whether the downstream RTM capable node
along the LSP is present in the RRO. along the LSP is present in the RRO.
Reserved field must be zeroed on initiation and ignored on receipt. Reserved field must be zeroed on initiation and ignored on receipt.
The content of an RTM_SET TLV is a series of variable-length sub- The content of an RTM_SET TLV is a series of variable-length sub-
skipping to change at page 16, line 17 skipping to change at page 16, line 17
After instantiating an LSP for a path using RSVP-TE [RFC3209] as After instantiating an LSP for a path using RSVP-TE [RFC3209] as
described in Section 4.6, ingress node MAY begin sending RTM packets described in Section 4.6, ingress node MAY begin sending RTM packets
to the first downstream RTM capable node on that path. Each RTM to the first downstream RTM capable node on that 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 the next downstream RTM-capable node. Each RTM-capable expire on the next downstream RTM-capable node. Each RTM-capable
node on the explicit path receives an RTM packet and records the time node on the explicit path receives an RTM packet and records the time
at which it receives that packet at its ingress interface as well as at which it receives that packet at its ingress interface as well as
the time at which it transmits that packet from its egress interface; the time at which it transmits that packet from its egress interface;
this should be done as close to the physical layer as possible to this should be done as close to the physical layer as possible to
ensure precise accuracy in time determination. The RTM-capable node ensure precise accuracy in time determination. The RTM-capable node
determines the difference between those two times; for 1-step determines the difference between those two times; for one-step
operation, this difference is determined just prior to or while operation, this difference is determined just prior to or while
sending the packet, and the RTM-capable egress interface adds it to sending the packet, and the RTM-capable egress interface adds it to
the value in the Scratch Pad field of the message in progress. Note, the value in the Scratch Pad field of the message in progress. Note,
for the purpose of calculating a residence time, a common free for the purpose of calculating a residence time, a common free
running clock synchronizing all the involved interfaces may be running clock synchronizing all the involved interfaces may be
sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond
error for residence time on the order of 1 millisecond. error for residence time on the order of 1 millisecond.
For 2-step operation, the difference between packet arrival time (at For two-step operation, the difference between packet arrival time
an ingress interface) and subsequent departure time (from an egress (at an ingress interface) and subsequent departure time (from an
interface) is determined at some later time prior to sending a egress interface) is determined at some later time prior to sending a
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 one-step
and 2-step operation. and two-step operation.
The last RTM-capable node on the LSP MAY then use the value in the The last RTM-capable node 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 node may be a PTP Boundary Clock up message. For example, the egress node 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 request-response mechanism. The RTM based on the IEEE 1588 delay request-response mechanism. The RTM
capable node nodes act as end-to-end transparent clocks, and capable node nodes act as end-to-end transparent clocks, and
typically boundary clocks, at the edges of the MPLS network, use the typically boundary clocks, at the edges of the MPLS network, use the
value in the Scratch Pad field to update the correctionField of the value in 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.
7. One-step Clock and Two-step Clock Modes 7. one-step Clock and two-step Clock Modes
One-step mode refers to the mode of operation where an egress one-step mode refers to the mode of operation where an egress
interface updates the correctionField value of an original event interface updates the correctionField value of an original event
message. Two-step mode refers to the mode of operation where this message. two-step mode refers to the mode of operation where this
update is made in a subsequent follow-up message. update is made in a subsequent follow-up message.
Processing of the follow-up message, if present, requires the Processing of the follow-up message, if present, requires the
downstream end-point to wait for the arrival of the follow-up message downstream end-point to wait for the arrival of the follow-up message
in order to combine correctionField values from both the original in order to combine correctionField values from both the original
(event) message and the subsequent (follow-up) message. In a similar (event) message and the subsequent (follow-up) message. In a similar
fashion, each 2-step node needs to wait for the related follow-up fashion, each two-step node needs to wait for the related follow-up
message, if there is one, in order to update that follow-up message message, if there is one, in order to update that follow-up message
(as opposed to creating a new one. Hence the first node that uses (as opposed to creating a new one. Hence the first node that uses
2-step mode MUST do two things: two-step mode MUST do two things:
1. Mark the original event message to indicate that a follow-up 1. Mark the original event message to indicate that a follow-up
message will be forthcoming (this is necessary in order to message will be forthcoming. This is necessary in order to
Let any subsequent 2-step node know that there is already a Let any subsequent two-step node know that there is already a
follow-up message, and follow-up message, and
Let the end-point know to wait for a follow-up message; Let the end-point know to wait for a follow-up message;
2. Create a follow-up message in which to put the RTM determined as 2. Create a follow-up message in which to put the RTM determined as
an initial correctionField value. an initial correctionField value.
IEEE 1588v2 [IEEE.1588.2008] defines this behavior for PTP messages. IEEE 1588v2 [IEEE.1588.2008] defines this behavior for PTP messages.
Thus, for example, with reference to the PTP protocol, the PTPType Thus, for example, with reference to the PTP protocol, the PTPType
field identifies whether the message is a Sync message, Follow_up field identifies whether the message is a Sync message, Follow_up
message, Delay_Req message, or Delay_Resp message. The 10 octet long message, Delay_Req message, or Delay_Resp message. The 10 octet long
Port ID field contains the identity of the source port, that is, the Port ID field contains the identity of the source port
specific PTP port of the boundary clock connected to the MPLS [IEEE.1588.2008], that is, the specific PTP port of the boundary
network. The Sequence ID is the sequence ID of the PTP message clock connected to the MPLS network. The Sequence ID is the sequence
carried in the Value field of the message. ID of the PTP message carried in the Value field of the message.
PTP messages also include a bit that indicates whether or not a PTP messages also include a bit that indicates whether or not a
follow-up message will be coming. This bit, once it is set by a follow-up message will be coming. This bit, once it is set by a two-
2-step mode device, MUST stay set accordingly until the original and step mode device, MUST stay set accordingly until the original and
follow-up messages are combined by an end-point (such as a Boundary follow-up messages are combined by an end-point (such as a Boundary
Clock). Clock).
Thus, an RTM packet, containing residence time information relating Thus, an RTM packet, containing residence time information relating
to an earlier packet, also contains information identifying that to an earlier packet, also contains information identifying that
earlier packet. earlier packet.
For compatibility with PTP, RTM (when used for PTP packets) must For compatibility with PTP, RTM (when used for PTP packets) must
behave in a similar fashion. To do this, a 2-step RTM capable egress behave in a similar fashion. To do this, a two-step RTM capable
interface will need to examine the S-bit in the Flags field of the egress interface will need to examine the S-bit in the Flags field of
PTP sub-TLV (for RTM messages that indicate they are for PTP) and - the PTP sub-TLV (for RTM messages that indicate they are for PTP) and
if it is clear (set to zero), it MUST set it and create a follow-up - if it is clear (set to zero), it MUST set it and create a follow-up
PTP Type RTM message. If the S bit is already set, then the RTM PTP Type RTM message. If the S bit is already set, then the RTM
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 one-step capable RTM node MAY elect to operate in either one-step
(by making an update to the Scratch Pad field of the RTM message mode (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 two-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 node), is a two-step clock, the (e.g. the BC connected to the first node), 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 node is also downstream direction), if the local RTM-capable node is also
operating as a two-step clock. This RTM packet carries the related operating as a two-step clock. This RTM packet carries the related
accumulated residence time and the appropriate values of the Sequence accumulated residence time and the appropriate values of the Sequence
Id and Port Id (the same identifiers carried in the packet processed) Id and Port Id (the same identifiers carried in the packet processed)
and the Two-step Flag set to 1. and the Two-step Flag set to 1.
Note that the fact that an upstream RTM-capable node operating in the Note that the fact that an upstream RTM-capable node operating in the
two-step mode has created a follow-up message does not require any two-step mode has created a follow-up message does not require any
subsequent RTM capable node to also operate in the 2-step mode, as subsequent RTM capable node to also operate in the two-step mode, as
long as that RTM-capable node forwards the follow-up message on the long as that RTM-capable node forwards the follow-up message on the
same LSP on which it forwards the corresponding previous message. same LSP on which it forwards the corresponding previous message.
A one-step capable RTM node MAY elect to update the RTM follow-up A one-step capable RTM node MAY elect to update the RTM follow-up
message as if it were operating in two-step mode, however, it MUST message as if it were operating in two-step mode, however, it MUST
NOT update both messages. NOT update both messages.
A PTP event packet (sync) is carried in the RTM packet in order for A PTP event packet (sync) is carried in the RTM packet in order for
an RTM node to identify that residence time measurement must be an RTM node to identify that residence time measurement must be
performed on that specific packet. performed on that specific packet.
skipping to change at page 20, line 28 skipping to change at page 20, line 28
+-----------+-------------------------------+---------------+ +-----------+-------------------------------+---------------+
Table 2: RTM TLV Type Table 2: RTM TLV Type
8.3. New RTM Sub-TLV Registry 8.3. New RTM Sub-TLV Registry
IANA is requested to create sub-registry in MPLS RTM TLV Registry, IANA is requested to create sub-registry in MPLS RTM TLV Registry,
requested in Section 8.2, called "MPLS RTM Sub-TLV Registry". All requested in Section 8.2, called "MPLS RTM Sub-TLV Registry". All
code points in the range 0 through 127 in this registry shall be code points in the range 0 through 127 in this registry shall be
allocated according to the "IETF Review" procedure as specified in allocated according to the "IETF Review" procedure as specified in
[RFC5226] . Code points in the range 128 through 191 in this registry [RFC5226]. Code points in the range 128 through 191 in this registry
shall be allocated according to the "First Come First Served" shall be allocated according to the "First Come First Served"
procedure as specified in [RFC5226]. . This document defines the procedure as specified in [RFC5226]. This document defines the
following new values RTM sub-TLV types: following new values RTM sub-TLV types:
+-----------+-------------+---------------+ +-----------+-------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-----------+-------------+---------------+ +-----------+-------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| 1 | PTP | This document | | 1 | PTP | This document |
| 2-127 | Unassigned | | | 2-127 | Unassigned | |
| 128 - 191 | Unassigned | | | 128 - 191 | Unassigned | |
| 192 - 254 | Private Use | This document | | 192 - 254 | Private Use | This document |
skipping to change at page 23, line 20 skipping to change at page 23, line 20
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
correctly modify specific content of the data in PTP messages and correctly modify specific content of the data in PTP messages and
proper operation of the protocol depends on this ability. proper operation of the protocol depends on this ability.
As a result, the content of the PTP-related data in RTM messages that As a result, the content of the PTP-related data in RTM messages that
will be modified by intermediate nodes cannot be authenticated, and will be modified by intermediate nodes cannot be authenticated, and
the additional information that must be accessible for proper the additional information that must be accessible for proper
operation of PTP 1-step and 2-step modes MUST be accessible to operation of PTP one-step and two-step modes MUST be accessible to
intermediate nodes (i.e. - MUST NOT be encrypted in a manner that intermediate nodes (i.e. - MUST NOT be encrypted in a manner that
makes this data inaccessible). makes this data inaccessible).
While it is possible for a supposed compromised node to intercept and While it is possible for a supposed compromised node to intercept and
modify the G-ACh content, this is an issue that exists for nodes in modify the G-ACh content, this is an issue that exists for nodes in
general - for any and all data that may be carried over an LSP - and general - for any and all data that may be carried over an LSP - and
is therefore the basis for an additional presumed trust model is therefore the basis for an additional presumed trust model
associated with existing LSPs and nodes. associated with existing LSPs and nodes.
The ability for potentially authenticating and/or encrypting RTM and The ability for potentially authenticating and/or encrypting RTM and
PTP data that is not needed by intermediate RTM/PTP-capable nodes is PTP data that is not needed by intermediate RTM/PTP-capable nodes is
for further study. for further study.
Security requirements of time protocols are provided in RFC 7384 Security requirements of time protocols are provided in RFC 7384
[RFC7384]. [RFC7384].
10. Acknowledgments 10. Acknowledgments
Authors want to thank Loa Andersson, Lou Berger and Acee Lindem for Authors want to thank Loa Andersson, Lou Berger and Acee Lindem for
their thorough reviews, thoughtful comments and, most of, patience. their thorough reviews, thoughtful comments and, most of all,
patience.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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", for Networked Measurement and Control Systems",
IEEE Standard 1588, July 2008. IEEE Standard 1588, July 2008.
skipping to change at page 25, line 50 skipping to change at page 25, line 50
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>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>. October 2014, <http://www.rfc-editor.org/info/rfc7384>.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
Independent ZTE Corp.
Email: gregimirsky@xxxxxxxxx Email: gregimirsky@xxxxxxxxx
Stefano Ruffini Stefano Ruffini
Ericsson Ericsson
Email: stefano.ruffini@xxxxxxxxxxxx Email: stefano.ruffini@xxxxxxxxxxxx
Eric Gray Eric Gray
Ericsson Ericsson
Email: eric.gray@xxxxxxxxxxxx Email: eric.gray@xxxxxxxxxxxx
John Drake John Drake
Juniper Networks Juniper Networks
Email: jdrake@xxxxxxxxxxx Email: jdrake@xxxxxxxxxxx
Stewart Bryant Stewart Bryant
Independent Huawei
Email: stewart.bryant@xxxxxxxxx Email: stewart.bryant@xxxxxxxxx
Alexander Vainshtein Alexander Vainshtein
ECI Telecom ECI Telecom
Email: Alexander.Vainshtein@xxxxxxxxxxx Email: Alexander.Vainshtein@xxxxxxxxxxx
 End of changes. 56 change blocks. 
80 lines changed or deleted 85 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]