wdiff draft-ietf-mpls-residence-time-12.txt draft-ietf-mpls-residence-time-13.txt

MPLS Working Group G. Mirsky
Internet-Draft Independent ZTE Corp.
Intended status: Standards Track S. Ruffini
Expires: June 16, August 3, 2017 E. Gray
Ericsson
J. Drake
Juniper Networks
S. Bryant
Independent
Huawei
A. Vainshtein
ECI Telecom
December 13, 2016
January 30, 2017

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

Abstract

This document specifies G-ACh based a new Generic Associated Channel for
Residence Time Measurement and describes how it can be used by time
synchronization protocols being
transported over within a 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 PTP 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 June 16, August 3, 2017.

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
2.1. One-step Clock and Two-step Clock Modes . . . . . . . . . 5
2.1.1. RTM with Two-step Upstream PTP Clock . . . . . . . . 6
2.1.2. RTM with One-step Upstream PTP Clock . . . . . . . . 7
3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 5 7
3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 6 9
4. Control Plane Theory of Operation . . . . . . . . . . . . . . 7 10
4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7 10
4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8 11
4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9 11
4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9 12
4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 9 12
4.6. RTM Capability Advertisement in BGP-LS . . . . . . . . . 13
4.7. RSVP-TE Control Plane Operation to Support RTM . . . . . 10
4.7. 13
4.8. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11
4.7.1. 15
4.8.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 13 16
5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 16 19
6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 16 19
7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. 20
7.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19
8.2. 20
7.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19
8.3. 20
7.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20
8.4. 21
7.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20
8.5. 21
7.5. IS-IS RTM Application ID Capability sub-TLV for TLV 22 . . . . . . . . . 21
7.6. RTM Capability TLV in BGP-LS . . . . . . . . . . . 21
8.6. . . . 22
7.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21
8.7. 22
7.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22
8.8. 23
7.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 22
9. 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. 24
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
11.2. 24
10.2. Informative References . . . . . . . . . . . . . . . . . 25 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 27

1. Introduction

Time synchronization protocols, e.g., Network Time Protocol version 4
(NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2
[IEEE.1588.2008]
[IEEE.1588.2008], define timing messages that can be used to
synchronize clocks across a network domain. Measurement of the
cumulative time that 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 Residence Time 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 network
path from an ingress node to an egress node.) This document defines
a new Generic Associated Channel (G-ACh) value and an associated
residence time measurement (RTM) packet message that can be used in a Multi-Protocol 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

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

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

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

BGP-LS: Border Gateway Protocol - Link State

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]
[IEEE.1588.2008], residence times time is accumulated in the
correctionField of the PTP event message, as defined in
[IEEE.1588.2008],
[IEEE.1588.2008] and referred to as using a one-step clock, or in the
associated follow-up message (or Delay_Resp message associated with
the Delay_Req message) in case of message), referred to as using a two-step clocks clock (see
the detailed discussion in Section 7). 2.1).

IEEE 1588 uses this residence time to correct for the transit time from
ingress node to egress node, times
of nodes on an LSP, effectively making the transit nodes transparent.

This document proposes a mechanism that can be used as one of types type 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 the Scratch Pad field of an RTM
packet Figure 1.
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 packet message prior to performing its PTP
processing.

3. G-ACh for Residence Time Measurement

RFC 5586 [RFC5586]

2.1. One-step Clock and RFC 6423 [RFC6423] define the G-ACh Two-step Clock Modes

One-step mode refers to extend the applicability mode of operation where an egress
interface updates the PW Associated Channel (ACH) [RFC5085] correctionField value of an original event
message. Two-step mode refers to
LSPs. G-ACh provides the mode of operation where this
update is made in a mechanism to transport OAM and other control
messages over an LSP. subsequent follow-up message.

Processing of these messages by selected
transit nodes is controlled by the use follow-up message, if present, requires the
downstream end-point to wait for the arrival of the Time-to-Live (TTL)
value follow-up message
in order to combine correctionField values from both the MPLS header of these messages.

The packet format original
(event) message and the subsequent (follow-up) message. In a similar
fashion, each two-step node needs to wait for Residence Time Measurement (RTM) the related follow-up
message, if there is presented one, 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 packet 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) order to be allocated by IANA,
identifies the packet as such.

o The Scratch Pad field is 8 octets in length. It is used update that follow-up message
(as opposed to
accumulate the residence time spent in each RTM capable node
transited by creating a new one. Hence the packet on its path from ingress node to egress
node. The first RTM-capable node that uses
two-step mode MUST initialize do two things:

1. Mark the Scratch Pad
field with its residence time measurement. Its format is IEEE
double precision and its units are nanoseconds. Note original event message to indicate that
depending on whether the timing procedure a follow-up
message will be forthcoming. This is one-step or necessary in order to

Let any subsequent two-step
operation (Section 7), the residence time node know that there is either for already a
follow-up message, and

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

2. Create a follow-up message in which to put the Value field of this RTM packet or for determined as
an
associated timing packet carried in initial correctionField value.

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

Thus, for example, with reference to the Value field of another RTM
packet.

o The Type PTP protocol, the PTPType
field identifies whether the type and encapsulation of message is a timing
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
Generic Associated Channel (G-ACh) Parameters Registry called
"MPLS RTM TLV Registry".

o Sync message, Follow_up
message, Delay_Req message, or Delay_Resp message. The Length 10 octet long
Port ID field contains the length, in octets , identity of the source port
[IEEE.1588.2008], that is, the specific PTP port of the
timing packet boundary
clock connected to the MPLS network. The Sequence ID is the sequence
ID of the PTP message 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 message.

PTP messages also include a bit that the packet may be authenticated indicates whether or
encrypted and carried over LSP edge to edge unchanged while the
residence time not a
follow-up message will be coming. This bit, once it is accumulated in the Scratch Pad field.

o The TLV set by a two-
step mode device, MUST be included in stay set accordingly until the original and
follow-up messages are combined by an end-point (such as a Boundary
Clock).

Thus, an RTM message, even if the length of
the Value field is zero.

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

For compatibility with PTP, RTM (when used for PTP Packet Sub-TLV

Figure 2 presents format packets) must
behave in a similar fashion. Without loss of generality should note
that handling of Sync event messages and handling of Delay_Req/
Delay_Resp event messages that cross a two-step RTM node is
different. Following outlines handling of PTP sub-TLV that MUST be included in Sync event message by
the Value field two-step RTM node. Details of an handling Delay_Resp/Delay_Req PTP
event messages by the two-step RTM packet preceding node are in Section 2.1.1. To do
this, a two-step RTM capable egress interface will need to examine
the carried timing packet
when S-bit in 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
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 the PTP Packet Sub-TLV

o The Type field identifies PTP packet sub-TLV (for RTM messages
that indicate they are for PTP) and - if it is set 1
according clear (set to Section 8.3.

o The Length field of the zero),
it MUST set it and create a follow-up PTP sub-TLV contains Type RTM message. If the number of octets
of S
bit is already set, then the Value field and RTM capable node MUST be 20.

o The Flags field currently defines one bit, the S-bit, that defines
whether wait for the current RTM
message has been processed by a 2-step node,
where the flag is cleared if with the message has been handled
exclusively by 1-step nodes and there is no PTP type of follow-up message, and
set if there has been at least one 2-step node matching originator and a follow-up
message is forthcoming.

o The PTPType indicates the type of PTP packet carried in the TLV.
PTPType is
sequence number to make the messageType field of corresponding residence time update to
the PTPv2 packet whose values
are defined Scratch Pad field. The wait period MUST be reasonably bound.

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 Table 19 [IEEE.1588.2008].

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

o The Sequence ID is the sequence ID of RTM message
containing the PTP message carried event message), or in
the Value field of the message.

4. Control Plane Theory of Operation

The operation of RTM depends upon TTL expiry to deliver two-step mode (by making an RTM packet
from one RTM capable interface
update to the next along the path from
ingress node to egress node. This means that Scratch Pad of a node with RTM capable
interfaces follow-up message when its presence is
indicated), but MUST be able to compute a TTL which will cause the expiry
of NOT do both.

Two main subcases identified for an RTM packet at the next node operating as a two-step
clock described in the following sub-sections.

2.1.1. RTM with Two-step Upstream PTP Clock

If any of the previous RTM capable interfaces.

4.1. RTM Capability

Note that nodes or the RTM capability of previous PTP clock
(e.g. the BC connected to the first node), is a node two-step clock, the
residence time is with respect added 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.

The supported modes (1-step verses 2-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 has been created to
determine the precise departure time of
include the same associated PTP packet and determine
from this, and the arrival time information from (i.e. follow-up message in the corresponding
ingress interface,
downstream direction), if the difference representing local RTM-capable node is also
operating as a two-step clock. This RTM packet carries the related
accumulated residence time for and the packet.

An interface with appropriate values of the ability to do this Sequence
Id and update the associated
Scratch Pad Port Id (the same identifiers carried in real-time (i.e. while the packet is being forwarded)
is said to be 1-step capable.

Hence while both ingress processed)
and egress interfaces are required to
support RTM for the pair Two-step Flag set to be RTM-capable, it is the egress
interface 1.

Note that determines whether or not the fact that an upstream RTM-capable node is 1-step or 2-step
capable with respect to the interface-pair.

The RTM capability used operating in the sub-TLV shown
two-step mode has created a follow-up message does not require any
subsequent RTM capable node to also operate in Figure 4 is thus
associated with the egress port of the two-step mode, as
long as that RTM-capable node making forwards the advertisement,
while follow-up message on the ability of any pair of interfaces that includes this egress
interface to support any mode of RTM depends
same LSP on which it forwards the ability of that
interface corresponding previous message.

A one-step capable RTM node MAY elect to record 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 arrival time (sync) is carried in some way the RTM packet in order for
an RTM node to identify that can residence time measurement must be
conveyed to and used by
performed on that egress interface.

When a node uses specific packet.

To handle the residence time of the Delay_Req message on the upstream
direction, an IGP RTM packet must be created to carry the residence time
on the associated downstream Delay_Resp message.

The last RTM capability sub-TLV, node of the sub-
TLV MUST reflect MPLS network, in addition to updating the
correctionField of the RTM capability (1-step or 2-step) associated
with egress interfaces.

4.2. PTP packet, must also properly
handle the two-step flag of the PTP packets.

2.1.2. RTM Capability Sub-TLV

The format for with One-step Upstream PTP Clock

When the PTP network connected to the MPLS and RTM Capabilities sub-TLV is presented node, operates in Figure 4

Figure 4:
one-step clock mode, the associated RTM Capability sub-TLV

o Type value (TBA2) will packet must be assigned created by IANA from appropriate
registry for OSPFv2.

o Length MUST be set to 4.

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

* 0b001 - one-step the
RTM supported;

* 0b010 - two-step node itself. The associated RTM supported;

* 0b100 - reserved.

o Reserved field must be set packet including the PTP event
packet needs now to all zeroes on transmit and ignored
on receipt.

[RFC4202] explains indicate that a follow up message will be coming.

The egress RTM-capable node of the Interface Switching Capability Descriptor
describes switching capability LSP will be removing RTM
encapsulation and, in case of an interface. For bi-directional
links, two-step clock mode being indicated,
will generate PTP messages as appropriate (according to the switching capabilities
[IEEE.1588.2008]). In this case, the common header of an interface are defined the PTP packet
carrying the synchronization message would have to be
the same modified in either direction. I.e., for data entering the node
through that interface and for data leaving the node through
twoStepFlag field indicating that
interface. That principle SHOULD be applied when there is now a node advertises
RTM Capability.

A node that supports RTM MUST be able follow up message
associated to act in two-step mode that.

3. G-ACh for Residence Time Measurement

RFC 5586 [RFC5586] and MAY
also support one-step RTM mode. Detailed discussion RFC 6423 [RFC6423] define the G-ACh to extend
the applicability of one-step and
two-step RTM modes in Section 7.

4.3. RTM Capability Advertisement in OSPFv2

The capability the PW Associated Channel (ACH) [RFC5085] to support RTM on
LSPs. G-ACh provides a particular link (interface) mechanism to transport OAM and other control
messages over an LSP. Processing of these messages by selected
transit nodes is
advertised controlled by the use of the Time-to-Live (TTL)
value in the OSPFv2 Extended Link Opaque LSA described MPLS header of these messages.

The message format for Residence Time Measurement (RTM) is presented
in
Section Figure 1
0 1 2 3 [RFC7684] via the
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 Capability sub-TLV.

Its G-ACh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Scratch Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type value will be assigned by IANA from the OSPF Extended Link
TLV Sub-TLVs registry that will be created per [RFC7684] request.

4.4. | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

o First four octets are defined as G-ACh Header in OSPFv3 [RFC5586]

o The capability Version field is set to support RTM on a particular link (interface) can be
advertised in OSPFv3 using LSA extensions 0, 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 defined in IS-IS RFC 4385 [RFC4385].

o The capability Reserved field MUST be set to support RTM 0 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: transmit and ignored on
receipt.

o The S bit MUST be cleared RTM G-ACh field, value (TBA1) to prevent be allocated by IANA,
identifies the RTM Capability sub-TLV
from leaking between levels. packet as such.

o The D bit of the Flags Scratch Pad 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. The RTM Capability sub-TLV
MUST be included in GENINFO TLV 8 octets in Application Specific Information.

4.6. RSVP-TE Control Plane Operation to Support RTM

Throughout this document we refer length. It is used to a node as
accumulate the residence time spent in each RTM capable node when
at least one of
transited by the packet on its interfaces is RTM capable. Figure 5 provides an
example of roles a path from ingress 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) egress
node. The first RTM-capable node MUST initialize the Scratch Pad
field with its egress port in Master state.
Node A transmits IP encapsulated timing packets whose destination
IP address residence time measurement. Its format is G.

o B IEEE
double precision and its units are nanoseconds. Note that
depending on whether the timing procedure is one-step or two-step
operation (Section 2.1), the ingress LER residence time is either for the MPLS LSP and is
timing packet carried in the first RTM capable
node. It creates Value field of this RTM packets and in each it places a message or
for an associated timing
packet, possibly encrypted, packet carried 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 of
another RTM
packets without modification. message.

o D is RTM capable transit node. It updates The Type field identifies the Scratch Pad filed type and encapsulation of the RTM a timing
packet without updating of carried in the timing packet.

o E is Value field, e.g., NTP [RFC5905] or PTP
[IEEE.1588.2008]. This document asks IANA to create a transit node that is not RTM capable. It forwards sub-
registry in Generic Associated Channel (G-ACh) Parameters Registry
called "MPLS RTM
packets without modification. TLV Registry" Section 7.2.

o F is The Length field contains the egress LER and length, in octets, of the last RTM capable node. It processes of the
timing packet carried in the Value field.

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

o The TLV MUST be included in the RTM ACH,
and removes message, even if the RTM ACH encapsulation.

o G length of
the Value field is a Boundary Clock with its ingress port in Slave state. Node
G receives zero.

3.1. PTP messages.

An ingress node that is configured to perform RTM along Packet Sub-TLV

Figure 2 presents format of a path
through an MPLS network to an egress node verifies PTP sub-TLV that MUST be included in
the selected
egress node has Value field of an interface that supports RTM via message preceding the egress node's
advertisement of the RTM Capability sub-TLV. In the Path message
that carried timing packet
when the ingress node uses timing packet is PTP.

Figure 2: PTP Sub-TLV format

where Flags field has format

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 instantiate the LSP 1
according to that egress node
it places LSP_ATTRIBUTES Object [RFC5420] with RTM_SET Attribute Flag
set Section 8.7 which indicates to 7.3.

o The Length field of the egress node that RTM is
requested for this LSP. RTM_SET Attribute Flag SHOULD NOT PTP sub-TLV contains the number of octets
of the Value field and MUST be set in 20.

o The Flags field currently defines one bit, the LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it is known
that all nodes support RTM, because a node S-bit, that does not recognize
RTM_SET Attribute Flag would reject defines
whether the Path message.

If egress node receives Path current message with RTM_SET Attribute Flag in
LSP_ATTRIBUTES object, it MUST include initialized RRO [RFC3209] and
LSP_ATTRIBUTES object has been processed by a two-step node,
where RTM_SET Attribute Flag 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 RTM_SET
TLV Section 4.7 a follow-
up message is initialized. When Resv 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 received by
ingress node carried in
the RTM_SET TLV will contain an ordered list, from
egress node to ingress node, 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 node along interface to the LSP's
path.

After next along the path from
ingress node receives the Resv, it MAY begin sending to egress node. This means that a node with RTM
packets on capable
interfaces MUST be able to compute a TTL which will cause the LSP's path. Each expiry
of an RTM packet has its Scratch Pad field
initialized and its TTL set to expire on at the closest downstream next node with RTM capable node.

It should be noted interfaces.

4.1. RTM Capability

Note that the RTM can also capability of a node is with respect to the pair of
interfaces that will be used for LSPs instantiated
using [RFC3209] in an environment in which all interfaces in to forward an IGP
support RTM. RTM packet. In this case general,
the RTM_SET TLV and LSP_ATTRIBUTES Object
MAY be omitted.

4.7. RTM_SET TLV

RTM capable interfaces can ingress interface of this pair must be recorded via RTM_SET TLV. The RTM_SET
sub-object format is able to capture the
arrival time of generic Type, Length, Value (TLV), presented the packet and encode it in Figure 6 .

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) some way such that this
information will be assigned by IANA from its Attributes TLV
Space sub-registry. available to the egress interface of a node.

The Length contains supported mode (one-step or two-step) of any pair of interfaces
is determined by the total length capability of the sub-object in bytes,
including egress interface. For both
modes, the Type egress interface implementation MUST be able to determine
the precise departure time of the same packet and determine from
this, and Length fields.

The I bit flag indicates whether the downstream RTM capable node
along arrival time information from the LSP is present 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 RRO.

Reserved field must packet is being forwarded)
is said to be zeroed on initiation one-step capable.

Hence while both ingress 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 egress interfaces are defined in Section 4.7.1 below.

The following processing procedures apply required to every
support 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 pair to be RTM-capable, it is set. If the RTM_SET
flag set, egress
interface that determines whether or not 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 is one-step or two-
step capable with generation of respect to the ResvErr message with Error Code
Duplicate TLV Section 8.8 and Error Value that contains Type value interface-pair.

The RTM capability used 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 sub-TLV shown in Figure 4 and Figure 5
is thus a non-routing related capability associated with
Error Code RTM_SET TLV Absent Section 8.8. If one RTM_SET TLV has
been found the
interface being advertised based on its egress capability. The
ability of any pair of interfaces on a node will use that includes this egress
interface to support any mode of RTM depends on the ID ability of the first
ingress interface of a node in the RTM_SET
in conjunction with the RRO to compute the hop count record packet arrival time and convey
it 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 egress interface on the node.

When a node as TTL value in outgoing label uses an IGP to reach support the next RTM
capable node on capability advertisement,
the LSP. Otherwise, IGP 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 MUST reflect the RTM_SET TLV in RTM capability (one-step or two-
step) associated
outgoing Resv message before forwarding it upstream. If with the
calculated TTL value been set advertised interface. Changes of RTM
capability are unlikely to 255, as described above, then the I
flag in node RTM_SET TLV MUST be set frequent and would result, for example,
from operator's decision to 1 before Resv message
forwarded upstream. Otherwise, the I flag MUST be cleared (0).

The ingress node MAY inspect include or exclude a particular port from
RTM processing or switch between RTM modes.

4.2. RTM Capability Sub-TLV

[RFC4202] explains that the I bit flag received in each RTM_SET
TLV contained in Interface Switching Capability Descriptor
describes the LSP_ATTRIBUTES object of a received Resv
message. Presence switching capability of an interface. For bi-
directional links, the RTM_SET TLV with I bit field set switching capabilities of an interface are
defined to 1
indicates that some RTM nodes along the LSP could be included in the
calculation of same in either direction. I.e., for data entering
the residence time. An ingress node MAY choose to
resignal the LSP to include all RTM nodes or simply notify through that interface and for data leaving the user
via a management node through
that 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 That principle SHOULD NOT be used if it is not guaranteed that RRO contains complete
information.

4.7.1. RTM_SET Sub-TLVs

The applied when a node
advertises RTM Set sub-object contains an ordered list, from egress Capability.

A node that supports RTM MUST be able to
ingress node, of the act in two-step mode and MAY
also support one-step RTM capable nodes along the LSP's path.

The contents of a RTM_SET sub-object are a series mode. Detailed discussion of variable-length
sub-TLVs. Each sub-TLV has its own Length field. one-step and
two-step RTM modes is contained in Section 2.1.

4.3. RTM Capability Advertisement in OSPFv2

The Length
contains the total length of format for the RTM Capability sub-TLV in bytes, including the OSPF 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
and | Length fields. The |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTM | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: RTM Capability sub-TLV in OSPFv2

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

o Length MUST always be set to 4.

o RTM (capability) - is a multiple of 4, and at
least 8 (smallest IPv4 sub-object).

Sub-TLVs are organized three-bit long bit-map field with values
defined as a last-in-first-out stack. 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.

The first -out
sub-TLV relative capability to the beginning of RTM_SET TLV support RTM on a particular link (interface) is considered
advertised in the
top. The last-out sub-TLV is considered OSPFv2 Extended Link Opaque LSA described in
Section 3 [RFC7684] via the bottom. When a new sub- RTM Capability sub-TLV.

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

4.4. RTM Capability Advertisement in OSPFv3

The capability to the top. Only support RTM on a single RTM_SET
sub-TLV with the given Value field MUST particular link (interface) can be present
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 format for the RTM_SET
TLV. If more than one RTM Capabilities 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 presented in Figure 5

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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: IPv4 sub-TLV format

Type

0x01 IPv4 address

Length

The Length contains the total length of the 5: RTM Capability sub-TLV in bytes,
including for the Extended IS Reachability TLV

o Type value (TBA3) will be assigned by IANA from the Sub-TLVs for
TLVs 22, 23, 141, 222, and 223 registry for IS-IS Section 7.5.

o Length fields. The Length is always 8.

IPv4 address

A 32-bit unicast host address. MUST be set to 2.

o RTM (capability) - as defined in Section 4.3.

o Reserved

Zeroed field must be set to all zeroes on initiation transmit 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

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

4.6. RTM Capability Advertisement in BGP-LS

The format for the RTM Capabilities TLV is as presented in Figure 4.

Type

0x02 IPv6 address

Length value TBA9 will be assigned by IANA from the BGP-LS Node
Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs
sub-registry Section 7.6.

Length, RTM, and Reserved fields as defined in Section 4.3.

The Length contains RTM Capability will be advertised in BGP-LS as a Link Attribute
TLV associated with the Link NLRI as described in section 3.3.2 of
[RFC7752].

4.7. 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 6 provides an
example of roles a node may have with respect to RTM capability:

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

Figure 6: 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 removes the
RTM ACH encapsulation and processes the timing packet carried in
the Value field using the value in the Scratch Pad field. In
particular, the value in the Scratch Pad field of the RTM ACH is
used in updating the Correction field of the PTP message(s). The
LER should also include its own residence time before creating the
outgoing PTP packets. The details of this process depend on
whether or not the node F is itself operating as one-step or two-
step clock.

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 MUST verify 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 the LSP_ATTRIBUTES Object [RFC5420] with
RTM_SET Attribute Flag set, as described in Section 7.8, 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 an egress node receives a 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.8 is initialized. When the Resv message is
received by the ingress node the RTM_SET TLV will contain an ordered
list, from egress node to ingress node, of the RTM capable nodes
along the LSP's path.

After the total length of ingress node receives the sub-TLV 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 bytes,
including an environment in which all interfaces in an IGP
support RTM. In this case the Type RTM_SET TLV and Length fields. LSP_ATTRIBUTES Object
MAY be omitted.

4.8. RTM_SET TLV

RTM capable interfaces can be recorded via RTM_SET TLV. The Length RTM_SET
sub-object format 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 of generic Type, Length, Value (TLV), presented
in Figure 7 .

Figure 9: IPv4 sub-TLV 7: RTM_SET TLV format

Type

0x03 Unnumbered interface

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

The Length contains the total length of the sub-TLV sub-object 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 I bit flag indicates whether the downstream RTM capable node specified by
along the
Node ID. LSP is present in the RRO.

Reserved

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

5. Data Plane Theory

The content of Operation

After instantiating an LSP for RTM_SET TLV is a path using RSVP-TE [RFC3209] as
described 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.6, ingress node MAY begin sending RTM packets 4.8.1 below.

The following processing procedures apply to the first downstream every RTM capable node on that path. Each
along the LSP. In this paragraph, an RTM
packet has its Scratch Pad field initialized and its TTL set capable node is referred to
expire on the next downstream RTM-capable node.
as a node for sake of brevity. Each RTM-capable node on MUST examine Resv message
for whether the explicit path receives an RTM packet and records RTM_SET Attribute Flag in the time
at which it receives that packet at its ingress interface as well as LSP_ATTRIBUTES object
is set. If the time at which it transmits that packet from its egress interface;
this should be done as close to RTM_SET flag is set, the physical layer as possible to
ensure precise accuracy in time determination. The RTM-capable node
determines MUST inspect the difference between those two times;
LSP_ATTRIBUTES object for 1-step
operation, this difference presence of RTM_SET TLV. If more than one
is determined just prior to or while
sending found, then the packet, LSP setup MUST fail with generation of the ResvErr
message with Error Code Duplicate TLV (Section 7.9) and Error Value
that contains Type value in its 8 least significant bits. If no
RTM_SET TLV has been found, then the RTM-capable egress interface adds it LSP setup MUST fail with
generation of the ResvErr message with Error Code RTM_SET TLV Absent
Section 7.9. 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 value node cannot find a matching ID in RRO,
then it MUST try to use the Scratch Pad field ID of the message next node in progress. Note,
for the purpose of calculating a residence time, a common free
running clock synchronizing all RTM_SET until
it finds the involved interfaces may be
sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond
error for residence time on match or reaches the order end of 1 millisecond.

For 2-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 RTM_SET TLV. If a
subsequent follow-up message, so that this match
has been found, the calculated value can be is used to
update the correctionField in the follow-up message.

See Section 7 for further details on by the difference between 1-step
and 2-step operation.

The last RTM-capable node on the LSP MAY then use as the TTL
value in the
Scratch Pad field outgoing label to perform time correction, if there is no follow-
up message. For example, reach the egress next RTM capable node may on the
LSP. Otherwise, the TTL value MUST be a PTP Boundary Clock
synchronized set to a Master Clock and will use 255. The node MUST add
RTM_SET sub-TLV with the value same address it used in RRO sub-object at
the beginning of the RTM_SET TLV in the Scratch
Pad field associated outgoing Resv
message before forwarding it upstream. If the calculated TTL value
been set to update PTP's correctionField.

6. Applicable PTP Scenarios

The proposed approach can 255, as described above, then the I flag in node RTM_SET
TLV MUST be directly integrated in a PTP network
based on set to 1 before Resv message forwarded upstream.
Otherwise, the IEEE 1588 delay request-response mechanism. I flag MUST be cleared (0).

The RTM
capable ingress node nodes act as end-to-end transparent clocks, and
typically boundary clocks, at the edges of the MPLS network, use MAY inspect the
value I bit flag received in each RTM_SET
TLV contained in the Scratch Pad LSP_ATTRIBUTES object of a received Resv
message. Presence of the RTM_SET TLV with I bit field set to update 1
indicates that some RTM nodes along the correctionField LSP could be included in the
calculation of the
corresponding PTP event packet prior residence time. An ingress node MAY choose to performing
resignal the usual PTP
processing.

7. One-step Clock and Two-step Clock Modes

One-step mode refers LSP to include all RTM nodes or simply notify the mode of operation where an egress
interface updates the correctionField value of user
via a management interface.

There are scenarios when some information is removed from an original event
message. Two-step mode refers RRO due
to policy processing (e.g., as may happen between providers) or RRO
is limited due to size constraints . Such changes affect the mode core
assumption of operation where this
update is made in a subsequent follow-up message.

Processing method and processing of the follow-up message, RTM packets. RTM SHOULD
NOT be used if present, requires it is not guaranteed that the
downstream end-point RRO contains complete
information.

4.8.1. RTM_SET Sub-TLVs

The RTM Set sub-object contains an ordered list, from egress node to wait for
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 arrival total length of the follow-up message sub-TLV in order to combine correctionField values from both bytes, including the original
(event) message Type
and the subsequent (follow-up) message. In Length fields. The Length MUST always be a similar
fashion, each 2-step node needs 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 wait for the related follow-up
message, if there beginning of RTM_SET TLV is one, in order to update that follow-up message
(as opposed to creating a new one. Hence considered the first node that uses
2-step mode MUST do two things:

1. Mark
top. The last-out sub-TLV is considered the original event message to indicate that bottom. When a follow-up
message will be forthcoming (this new sub-
TLV is necessary in order to

Let any subsequent 2-step node know that there added, it 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 always added to put the RTM determined as
an initial correctionField value.

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

Thus, for example, top. Only a single RTM_SET
sub-TLV with reference to the PTP protocol, the PTPType given Value field identifies whether MUST be present in the message RTM_SET
TLV. If more than one sub-TLV is found the LSP setup MUST fail with
the generation of a Sync message, Follow_up
message, Delay_Req message, or Delay_Resp message. The 10 octet long
Port ID field ResvErr message with the Error Code "Duplicate
sub-TLV" Section 7.9 and Error Value contains the identity 16-bit value composed
of the source port, that is, the
specific PTP port (Type of the boundary clock connected to the MPLS
network. TLV, Type of sub-TLV).

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

4.8.1.1. IPv4 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: IPv4 sub-TLV format

Type

0x01 IPv4 address

Length

The Sequence ID is Length contains the sequence ID total length of the PTP message
carried sub-TLV in bytes,
including 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 Type and Length fields. The Length is set by a
2-step mode device, MUST stay set accordingly until the original always 8.

IPv4 address

A 32-bit unicast host address.

Reserved

Zeroed on initiation 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 ignored on receipt.

4.8.1.2. IPv6 Sub-TLV

Figure 9: IPv6 sub-TLV format

Type

0x02 IPv6 address

Length

The Length contains information identifying that
earlier packet.

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
interface will need to examine the S-bit in the Flags field total length of the
PTP sub-TLV (for RTM messages that indicate they are for PTP) in bytes,
including the Type and -
if it Length fields. The Length is clear (set to zero), it MUST set it always 20.

IPv6 address

A 128-bit unicast host address.

Reserved

Zeroed on initiation and create a follow-up
PTP ignored on receipt.

4.8.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 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 1-step capable RTM node MAY elect to operate in either 1-step mode
(by making an update to the Scratch Pad field of | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: IPv4 sub-TLV format

Type

0x03 Unnumbered interface

Length

The Length contains the RTM message
containing total length of the PTP even message), or sub-TLV in 2-step mode (by making an
update to bytes,
including the Scratch Pad of a follow-up message when its presence Type and Length fields. The Length is
indicated), but MUST NOT do both.

Two main subcases can be identified for an RTM node operating always 12.

Node ID

The Node ID interpreted as a
two-step clock:

A) If any of Router ID as discussed in the previous RTM capable node or Section 2
[RFC3477].

Interface ID

The identifier assigned to the previous PTP clock
(e.g. link by the BC connected to node specified by the first node), is
Node ID.

Reserved
Zeroed on initiation and ignored on receipt.

5. Data Plane Theory of Operation

After instantiating an LSP for a two-step clock, the
residence time is added to path using RSVP-TE [RFC3209] as
described in Section 4.7, the ingress node MAY begin sending RTM packet that has been created
packets to
include the associated PTP packet (i.e. follow-up message in the first downstream direction), if the local RTM-capable RTM capable node is also
operating as a two-step clock. This on that path. Each
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) has its Scratch Pad field initialized and the Two-step Flag its TTL set to 1.

Note that
expire on the fact that an upstream next downstream RTM-capable node. Each RTM-capable
node operating in on the
two-step mode has created a follow-up message does not require any
subsequent explicit path receives an RTM capable node to also operate in packet and records the 2-step mode, time
at which it receives that packet at its ingress interface as
long well as that RTM-capable node forwards the follow-up message on
the
same LSP on time at which it forwards the corresponding previous message.

A one-step capable RTM node MAY elect transmits that packet from its egress interface;
this should be done as close to update the RTM follow-up
message physical layer as if it were operating possible to
ensure precise accuracy in two-step mode, however, it MUST
NOT update both messages.

A PTP event packet (sync) time determination. The RTM-capable node
determines the difference between those two times; for one-step
operation, this difference is carried determined just prior to or while
sending the packet, and the RTM-capable egress interface adds it to
the value in the RTM packet Scratch Pad field of the message in order progress. Note,
for
an RTM node 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 identify that 4.6 nanosecond
error for residence time measurement must be
performed on that specific packet.

To handle the residence time order of 1 millisecond. This may be
acceptable for applications where the Delay request message on target accuracy is in the
upstream direction, order
of hundreds of ns. As an RTM example several applications being
considered in the area of wireless applications are satisfied with an
accuracy of 1.5 microseconds [ITU-T.G.8271].

For two-step operation, the difference between packet must 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 created used to carry
update the
residence time correctionField in the follow-up message.

See Section 2.1 for further details on the associated downstream Delay Resp message. difference between one-
step and two-step operation.

The last RTM RTM-capable node of on the MPLS network LSP MAY then use the value in addition to update the
correctionField of
Scratch Pad field to perform time correction, if there is no follow-
up message. For example, the associated egress node may be a PTP packet, must also properly
handle Boundary Clock
synchronized to a Master Clock and will use the two-step flag of value in the Scratch
Pad field to update PTP's correctionField.

6. Applicable PTP packets.

B) When the Scenarios

This approach can be directly integrated in a PTP network connected to based on
the MPLS and IEEE 1588 delay request-response mechanism. The RTM node, operates capable
nodes act as end-to-end transparent clocks, and typically boundary
clocks, at the edges of the MPLS network, use the value in one-step clock mode, the associated RTM packet must be created by
Scratch Pad field to update the RTM node itself. The associated RTM packet including correctionField of the corresponding
PTP event packet needs now prior 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 performing the usual PTP packets.

8. processing.

7. IANA Considerations

8.1.

7.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.

7.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:

+-----------+-------------------------------+---------------+
| 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.

7.3. New RTM Sub-TLV Registry

IANA is requested to create sub-registry in MPLS RTM TLV Registry,
requested in Section 8.2, 7.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] .
[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.

7.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:

+-------+----------------+---------------+

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

Table 4: RTM Capability sub-TLV

7.5. IS-IS RTM Capability sub-TLV for TLV 22

IANA is requested to assign a new Type for RTM capability sub-TLV
from the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry as
follows:

+------+-------------+----+----+-----+-----+-----+---------------+
| Value Type | Description | 22 | 23 | 141 | 222 | 223 | Reference |
+-------+----------------+---------------+
+------+-------------+----+----+-----+-----+-----+---------------+
| TBA2 TBA3 | RTM Capability | y | n | n | n | n | This document |
+-------+----------------+---------------+
+------+-------------+----+----+-----+-----+-----+---------------+

Table 4: 5: IS-IS RTM Capability sub-TLV

8.5. IS-IS for TLV 22

7.6. RTM Application ID Capability TLV in BGP-LS

IANA is requested to assign a new Application ID code point for RTM from the
Application Identifiers for Capability TLV 251
from BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs sub-registry in its Border Gateway Protocol - Link
State (BGP-LS) Parameters registry as follows:

+-------+-------------+---------------+

+---------------+----------------+------------------+---------------+
| Value TLV Code | Description | IS-IS TLV/Sub- | Reference |
+-------+-------------+---------------+
| TBA3 Point | | TLV | |
+---------------+----------------+------------------+---------------+
| TBA9 | RTM Capability | 22/TBA3 | This document |
+-------+-------------+---------------+
+---------------+----------------+------------------+---------------+

Table 5: IS-IS 6: RTM Application ID

8.6. Capability TLV in BGP-LS

7.7. 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: 7: 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:

Table 7: 8: RTM_SET object sub-object types

8.7.

7.8. 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: 9: RTM_SET Attribute Flag

8.8.

7.9. New Error Codes

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

Table 9: 10: New Error Codes

8. Security Considerations

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

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 In
practice, this means that those portions of the PTP-related data in RTM messages that
will cannot be modified
covered by either confidentiality or integrity protection. Though
there are methods that make it possible in theory to provide either
or both such protections and still allow for intermediate nodes cannot be authenticated, and
the additional information to
make detectable but authenticated modifications, such methods do not
seem practical at present, particularly for timing protocols that must be accessible are
sensitive to latency and/or jitter.

The ability for proper
operation of potentially authenticating and/or encrypting RTM and
PTP 1-step data for scenarios both with and 2-step modes MUST be accessible to without participation of
intermediate RTM/PTP-capable nodes (i.e. - MUST NOT be encrypted in a manner that
makes this data inaccessible). is for further study.

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.

9. Acknowledgments

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

11.

10. References

11.1.

10.1. Normative References

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

[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>.

[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.

[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>.

[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.

[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<http://www.rfc-editor.org/info/rfc7752>.

10.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.

[ITU-T.G.8271]
"Packet over Transport aspects - Synchronization, quality
and availability targets", ITU-T Recomendation
G.8271/Y.1366, July 2016.

[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
Independent
ZTE Corp.

Email: gregimirsky@gmail.com

Stefano Ruffini
Ericsson

Email: stefano.ruffini@ericsson.com

Eric Gray
Ericsson

Email: eric.gray@ericsson.com

John Drake
Juniper Networks

Email: jdrake@juniper.net

Stewart Bryant
Independent
Huawei

Email: stewart.bryant@gmail.com

Alexander Vainshtein
ECI Telecom

Email: Alexander.Vainshtein@ecitele.com Alexander.Vainshtein@ecitele.com; Vainshtein.alex@gmail.com