draft-mirsky-mpls-residence-time-05.txt   draft-mirsky-mpls-residence-time-06.txt 
MPLS Working Group G. Mirsky MPLS Working Group G. Mirsky
Internet-Draft S. Ruffini Internet-Draft S. Ruffini
Intended status: Standards Track E. Gray Intended status: Standards Track E. Gray
Expires: September 10, 2015 Ericsson Expires: November 3, 2015 Ericsson
J. Drake J. Drake
Juniper Networks Juniper Networks
S. Bryant S. Bryant
Cisco Systems Cisco Systems
A. Vainshtein A. Vainshtein
ECI Telecom ECI Telecom
March 9, 2015 May 2, 2015
Residence Time Measurement in MPLS network Residence Time Measurement in MPLS network
draft-mirsky-mpls-residence-time-05 draft-mirsky-mpls-residence-time-06
Abstract Abstract
This document specifies G-ACh based Residence Time Measurement and This document specifies G-ACh based Residence Time Measurement and
how it can be used by time synchronization protocols being how it can be used by time synchronization protocols being
transported over MPLS domain. transported over MPLS domain.
Residence time is the variable part of propagation delay of timing
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 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 September 10, 2015. This Internet-Draft will expire on November 3, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4
2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4 2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4
3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 4 3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 4
3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 6 3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 6
4. Control Plane Theory of Operation . . . . . . . . . . . . . . 7 4. Control Plane Theory of Operation . . . . . . . . . . . . . . 7
4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7
4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8
4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9 4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9
4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9 4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9
4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 9 4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 10
4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10 4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10
4.7. RTM_SET Object . . . . . . . . . . . . . . . . . . . . . 11 4.7. RTM_SET Object . . . . . . . . . . . . . . . . . . . . . 11
4.7.1. RSO Sub-objects . . . . . . . . . . . . . . . . . . . 11 4.7.1. RSO Sub-objects . . . . . . . . . . . . . . . . . . . 12
5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 14 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 14
6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 15 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 15
7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 15 7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 17 8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 17
8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 17 8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 18
8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 18 8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 18
8.4. RTM Capability sub-TLV . . . . . . . . . . . . . . . . . 18 8.4. RTM Capability sub-TLV . . . . . . . . . . . . . . . . . 19
8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 19 8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 19
8.6. RTM_SET Object RSVP Class Number, Class Type and Sub- 8.6. RTM_SET Object RSVP Class Number, Class Type and Sub-
object Types . . . . . . . . . . . . . . . . . . . . . . 19 object Types . . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Time synchronization protocols, Network Time Protocol version 4 Time synchronization protocols, Network Time Protocol version 4
(NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2
[IEEE.1588.2008] can be used to synchronize clocks across network [IEEE.1588.2008] can be used to synchronize clocks across network
domain. In some scenarios calculation of time packet of time domain. Measurement of the time a PTP event message spends
synchronization protocol spends within a node, called Residence Time, traversing a node (using precise times of receipt at an ingress
can improve accuracy of clock synchronization. This document defines interface and transmission at an egress interface), called Residence
new Generalized Associated Channel (G-ACh) that can be used in Multi- Time, can be used to improve the accuracy of clock synchronization.
Protocol Label Switching (MPLS) network to measure Residence Time This document defines new Generalized Associated Channel (G-ACh) that
over Label Switched Path (LSP). Mechanisms for transport of time can be used in Multi-Protocol Label Switching (MPLS) network to
synchronization protocol packets over MPLS are out of scope in this measure Residence Time over Label Switched Path (LSP). Mechanisms
document. for transport of time synchronization protocol packets over MPLS are
out of scope in this document.
1.1. Conventions used in this document 1.1. Conventions used in this document
1.1.1. Terminology 1.1.1. Terminology
MPLS: Multi-Protocol Label Switching MPLS: Multi-Protocol Label Switching
ACH: Associated Channel ACH: Associated Channel
TTL: Time-to-Live TTL: Time-to-Live
skipping to change at page 3, line 38 skipping to change at page 3, line 48
ppm: parts per million ppm: parts per million
PTP: Precision Time Protocol PTP: Precision Time Protocol
LSP: Label Switched Path LSP: Label Switched Path
LSR: Label Switching Router LSR: Label Switching Router
OAM: Operations, Administration, and Maintenance OAM: Operations, Administration, and Maintenance
RSO: RTM Set Object RRO: Record Route Object
RSO: RTM Set Object
RTM: Residence Time Measurement RTM: Residence Time Measurement
IGP: Internal Gateway Protocol IGP: Internal Gateway Protocol
1.1.2. Requirements Language 1.1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
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 metrics are insufficient for use in some LSP or PW. But these metrics 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). PTPv2 [IEEE.1588.2008] defined in the Precision Time Protocol (PTP). PTPv2 [IEEE.1588.2008]
uses "residence time", the time it takes for a PTPv2 event packet to uses "residence time", the time it takes for a PTPv2 event packet to
transit a node. Residence times are accumulated in the transit a node. Residence times are accumulated in the
correctionField of the PTP event messages or of the associated correctionField of the PTP event messages, as defined in
follow-up messages (or Delay_Resp message associated with the [IEEE.1588.2008], or of the associated follow-up messages (or
Delay_Req message) in case of two-step clocks (detailed discussion in Delay_Resp message associated with the Delay_Req message) in case of
Section 7). The residence time values are specific to each output two-step clocks (detailed discussion in Section 7). The residence
PTP port and message. time values are specific to each output PTP port and message.
This accumulated residence time MAY then be applied to correct the IEEE 1588 uses this residence time to correct the propagated time,
propagated time for node delays, effectively making these nodes effectively making these nodes transparent.
transparent.
This document proposes mechanism to accumulate packet residence time This document proposes mechanism to accumulate packet residence time
from all LSRs that support the mechanism across a particular LSP. from all LSRs that support the mechanism across a particular LSP.
The values accumulated in scratchpad fields of MPLS RTM messages can
be used by the last RTM-capable LSR on an LSP to update the
correctionField of the corresponding PTP event packet prior to
performing the usual PTP processing.
3. G-ACh for Residence Time Measurement 3. G-ACh for Residence Time Measurement
RFC 5586 [RFC5586] and RFC 6423 [RFC6423] extended applicability of RFC 5586 [RFC5586] and RFC 6423 [RFC6423] extended applicability of
PW Associated Channel (ACH) [RFC5085] to LSPs. G-ACh provides a PW Associated Channel (ACH) [RFC5085] to LSPs. G-ACh provides a
mechanism to transport OAM and other control messages. Processing by mechanism to transport OAM and other control messages. Processing by
arbitrary transit LSRs can be triggered through controlled use of the arbitrary transit LSRs can be triggered through controlled use of the
Time-to-Live (TTL) value. In a way that is analogous to PTP Time-to-Live (TTL) value. In a way that is analogous to PTP
operations, the packet residence time can be handled by the RTM operations, the packet residence time can be handled by the RTM
capable node either as "one-step clock" or as a "two-step clock". capable node either as "one-step clock" or as a "two-step clock".
skipping to change at page 5, line 19 skipping to change at page 5, line 19
| | | |
| Scratch Pad | | Scratch Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: G-ACh packet format for Residence Time Measurement Figure 1: RTM G-ACh packet format for Residence Time Measurement
o First four octets are defined as G-ACh Header in [RFC5586]
o The Version field is set to 0, as defined in RFC 4385 [RFC4385]. o The Version field is set to 0, as defined in RFC 4385 [RFC4385].
o The Reserved field MUST be set to 0 on transmit and ignored on o The Reserved field MUST be set to 0 on transmit and ignored on
receipt. receipt.
o The RTM G-ACh field, value to be allocated by IANA, identifies the o The RTM G-ACh field, value to be allocated by IANA, identifies the
packet as such. packet as such.
o The Scratch Pad field is 8 octets in length. The first RTM- o The Scratch Pad field is 8 octets in length. The first RTM-
skipping to change at page 6, line 20 skipping to change at page 6, line 22
3.1. PTP Packet Sub-TLV 3.1. PTP Packet Sub-TLV
Figure 2 presents format of a PTP sub-TLV that MUST be precede every Figure 2 presents format of a PTP sub-TLV that MUST be precede every
PTP packet carried in RTM TLV. PTP packet carried in RTM TLV.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Resv |PTPType| Reserved | | Flags |PTPType|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID | | Port ID |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Sequence ID | | | Sequence ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PTP Sub-TLV format Figure 2: PTP Sub-TLV format
where Flags field has format where Flags field has format
0 1 2 3 4 5 6 7 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flags field format for Residence Time Measurement Figure 3: Flags field format of PTP Packet Sub-TLV
o The Type field identifies PTP sub-TLV defined in the Table 19 o The Type field identifies PTP sub-TLV defined in the Table 19
Values of messageType field in [IEEE.1588.2008]. Values of messageType field in [IEEE.1588.2008].
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 or not the current message has been processed by a 2-step whether or not the current message has been processed by a 2-step
node, where the flag is cleared if the message has been handled node, 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 1-step nodes and there is no follow-up message, and
set if there has been at least one 2-step node and a follow-up set if there has been at least one 2-step node and a follow-up
message is forthcoming. 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 the Table 19 [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. The Sequence ID is the sequence ID of the PTP source port.
message carried in the Value field of the message.
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 4. Control Plane Theory of Operation
The operation of RTM depends upon TTL expiry to deliver an RTM packet The operation of RTM depends upon TTL expiry to deliver an RTM packet
from one RTM capable interface to the next along the path from from one RTM capable interface to the next along the path from
ingress LSR to egress LSR, which means that an LSR with RTM capable ingress LSR to egress LSR. This means that an LSR with RTM capable
interfaces needs to be able to compute a TTL which will cause the interfaces MUST be able to compute a TTL which will cause the expiry
expiry of an RTM packet at the next LSR with RTM capable interfaces. of an RTM packet at the next LSR with RTM capable interfaces.
However, because of Equal Cost Multipath, labels distributed by LDP However, because of Equal Cost Multipath, labels distributed by LDP
do not necessarily instantiate a single path between a given ingress/ do not necessarily instantiate a single path between a given ingress/
egress LSR pair but rather MAY create a graph in which different egress LSR pair but rather MAY create a graph in which different
flows will take different paths through this network. This means one flows will take different paths through this network. This means one
doesn't necessarily know the path that RTM packets will take or even doesn't necessarily know the path that RTM packets will take or even
if they all take the same path. So, in an environment in which not if they all take the same path. In an environment in which not all
all interfaces in an IGP domain support RTM, it is effectively interfaces in an IGP domain support RTM, it is effectively impossible
impossible to use TTL expiry to deliver RTM packets and hence RTM to use TTL expiry to deliver RTM packets. Hence RTM cannot be used
cannot be used for LSPs instantiated using LDP, if multi-pathing is for LSPs instantiated using LDP, if multi-pathing is in use and not
in use and not all LSRs are RTM-capable. In the special but all LSRs are RTM-capable. In the special but important case of
important case of environment in which all interfaces in an IGP environment in which all interfaces in an IGP domain support RTM,
domain support RTM, setting the TTL to 1 will always cause the expiry setting the TTL to 1 will always cause the expiry of an RTM packet on
of an RTM packet on the next RTM capable downstream LSR and hence in the next RTM capable downstream LSR and hence in such an environment,
such an environment, RTM can be used for LSPs instantiated using LDP. RTM can be used for LSPs instantiated using LDP.
Also, if it is possible and desirable, multi-path forwarding may be Also, if it is possible and desirable, multi-path forwarding may be
disabled, at least for the set of packets that includes RTM. disabled,at least for LSPs used for RTM.
Generally speaking, RTM is more useful for an LSP instantiated using Generally speaking, RTM is more useful for an LSP instantiated using
RSVP-TE [RFC3209] because the LSP's path can be determined. RSVP-TE [RFC3209] because the LSP's path can be determined.
4.1. RTM Capability 4.1. RTM Capability
Note that RTM capability of a node is with respect to the pair of Note that RTM capability of a node is with respect to the pair of
interfaces that will be used to forward an RTM packet. In general, interfaces that will be used to forward an RTM packet. In general,
the ingress interface of this pair must be able to capture the the ingress interface of this pair must be able to capture the
arrival time of the packet and encode it in some way such that this arrival time of the packet and encode it in some way such that this
skipping to change at page 8, line 10 skipping to change at page 8, line 16
The supported modes (1-step verses 2-step) of any pair of interfaces The supported modes (1-step verses 2-step) of any pair of interfaces
is then determined by the capability of the egress interface. In is then determined by the capability of the egress interface. In
both cases, the egress interface implementation MUST be able to both cases, 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
correctionField in real-time (i.e. ? while the packet is being ScratchPad in real-time (i.e. while the packet is being forwarded) is
forwarded) is said to be 1-step capable. said to be 1-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 1-step or 2-step
capable with respect to the interface-pair. 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 an IGP is used to carry the above defined RTM capability sub- When an LSR uses an IGP to carry the RTM capability sub-TLV, the sub-
TLV, the implementation MUST associate the advertisement with the TLV MUST reflect the RTM capability (1-step or 2-step) associated
interface that has the ability used to determine its supported RTM with egress interfaces and MUST NOT propagate this sub-TLV in IGP
capabilities, and MUST NOT propagate this sub-TLV via any interface LSAs sent from an interface that does not support the same capability
that does not have the associated ingress ability described in this for RTM messages it receives.
section.
4.2. RTM Capability Sub-TLV 4.2. RTM Capability Sub-TLV
The format for the RTM Capabilities sub-TLV is presented in Figure 4 The format for the RTM Capabilities sub-TLV is presented in Figure 4
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(TBA5) | Length | | Type(TBA5) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTM | Reserved | | RTM | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RTM Capability sub-TLV Figure 4: RTM Capability sub-TLV
o Type value will be assigned by IANA from appropriate registries. o Type value will be assigned by IANA from appropriate registries.
o Length MUST be set to 4. o Length MUST be set to 4.
o RTM is a three-bit long bit-map field with values defined as o RTM (capability) - is a three-bit long bit-map field with values
follows: defined as follows:
* 0b001 - one-step RTM supported; * 0b001 - one-step RTM supported;
* 0b010 - two-step RTM supported; * 0b010 - two-step RTM supported;
* 0b100 - reserved. * 0b100 - reserved.
o Reserved field must be set to all zeroes on transmit and ignored o Reserved field must be set to all zeroes on transmit and ignored
on receipt. on receipt.
[RFC4202] explains that ?the Interface Switching Capability [RFC4202] explains that the Interface Switching Capability Descriptor
Descriptor describes switching capability of an interface. For bi- describes switching capability of an interface. For bi-directional
directional links, the switching capabilities of an interface are links, the switching capabilities of an interface are defined to be
defined to be the same in either direction. I.e., for data entering the same in either direction. I.e., for data entering the node
the node through that interface and for data leaving the node through through that interface and for data leaving the node through that
that interface". That principle SHOULD be applied when a node interface". That principle SHOULD be applied when a node advertises
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 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 advertised in the The capability to support RTM on a particular link advertised in the
OSPFv2 Extended Link Opaque LSA [I-D.ietf-ospf-prefix-link-attr] as OSPFv2 Extended Link Opaque LSA [I-D.ietf-ospf-prefix-link-attr] as
RTM Capability sub-TLV, presented in Figure 4, of the OSPFv2 Extended RTM Capability sub-TLV, presented in Figure 4, of the OSPFv2 Extended
skipping to change at page 10, line 10 skipping to change at page 10, line 18
characterized as "generic information not directly related to the characterized as "generic information not directly related to the
operation of the IS-IS protocol" [RFC6823]. Hence the capability to operation of the IS-IS protocol" [RFC6823]. Hence the capability to
process RTM messages can be advertised by including RTM Capability process RTM messages can be advertised by including RTM Capability
sub-TLV in GENINFO TLV [RFC6823]. sub-TLV in GENINFO TLV [RFC6823].
With respect to the Flags field of the GENINFO TLV: With respect to the Flags field of the GENINFO TLV:
o The S bit MUST be cleared to prevent the RTM Capability sub-TLV o The S bit MUST be cleared to prevent the RTM Capability sub-TLV
from leaking between levels. from leaking between levels.
o The D bit of the Flags field MUST be cleared as well. 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 o The I bit and the V bit MUST be set accordingly depending on
whether RTM capability being advertised for IPv4 or IPv6 interface whether RTM capability being advertised for IPv4 or IPv6 interface
of the node. of the node.
Application ID (TBA6) will be assigned from the Application Application ID (TBA6) will be assigned from the Application
Identifiers for TLV 251 IANA registry. The RTM Capability sub-TLV, Identifiers for TLV 251 IANA registry. The RTM Capability sub-TLV,
presented in Figure 4, MUST be included in GENINFO TLV in Application presented in Figure 4, MUST be included in GENINFO TLV in Application
Specific Information. Specific Information.
skipping to change at page 10, line 33 skipping to change at page 10, line 42
Though RTM capability is per interface throughout this document we Though RTM capability is per interface throughout this document we
will refer to an LSR as RTM capable LSR when: will refer to an LSR as RTM capable LSR when:
o ingress LSR's LSP interface is RTM capable; o ingress LSR's LSP interface is RTM capable;
o transit LSR's ingress and egress interfaces for the given LSP are o transit LSR's ingress and egress interfaces for the given LSP are
RTM capable; RTM capable;
o egress LSR's egress interface is RTM capable. o egress LSR's egress interface is RTM capable.
An ingress LSR that wishes to perform RTM along a path through an An ingress LSR that is configured to perform RTM along a path through
MPLS network to an egress LSR verifies that the selected egress LSR an MPLS network to an egress LSR verifies that the selected egress
has an interface that supports RTM via the egress LSR's advertisement LSR has an interface that supports RTM via the egress LSR's
of the RTM Capability sub-TLV. In the Path message that the ingress advertisement of the RTM Capability sub-TLV. In the Path message
LSR uses to instantiate the LSP to that egress LSR it places that the ingress LSR uses to instantiate the LSP to that egress LSR
initialized Record Route and RTM Set Objects Section 4.7, which tell it places initialized Record Route Object (RRO) [RFC3209] and RTM Set
the egress LSR that RTM is desired for this LSP. Object (RSO) [Section 4.7], which tell the egress LSR that RTM is
requested for this LSP.
In the Resv message that the egress LSR sends in response to the In the Resv message that the egress LSR sends in response to the
received Path message, it includes initialized Record Route and RTM received Path message, it includes initialized RRO and RSO. The RSO
Set Objects (RSO). The RTM Set Object contains an ordered list, from contains an ordered list, from egress LSR to ingress LSR, of the RTM
egress LSR to ingress LSR, of the RTM capable LSRs along the LSP's capable LSRs along the LSP's path. Each such LSR will use the ID of
path. Each such LSR will use the ID of the first LSR in the RTM Set the first LSR in the RSO in conjunction with the RRO to compute the
Object in conjunction with the Record Route Object to compute the hop hop count to its downstream LSR with reachable RTM capable interface.
count to its downstream LSR with reachable RTM capable interface. It It will also insert its ID at the beginning of the RTM Set Object
will also insert its ID at the beginning of the RTM Set Object before before forwarding the Resv upstream.
forwarding the Resv upstream.
After the ingress LSR receives the Resv, it MAY begin sending RTM After the ingress LSR receives the Resv, it MAY begin sending RTM
packets to the first RTM capable LSR on the LSP's path. Each RTM packets to the first RTM capable LSR on the LSP's path. Each RTM
packet has its Scratch Pad field initialized and its TTL set to packet has its Scratch Pad field initialized and its TTL set to
expire on that first subsequent RTM capable LSR. expire on that first subsequent RTM capable LSR.
It should be noted that RTM can also be used for LSPs instantiated It should be noted that RTM can also be used for LSPs instantiated
using [RFC3209] in an environment in which all interfaces in an IGP using [RFC3209] in an environment in which all interfaces in an IGP
support RTM. In this case the RTM Set Object MAY be omitted. support RTM. In this case the RSO MAY be omitted.
4.7. RTM_SET Object 4.7. RTM_SET Object
RTM capable interfaces can be recorded via RTM_SET object (RSO). The RTM capable interfaces can be recorded via RTM_SET object (RSO). The
RTM Set Class is TBA7. Currently one C_Type is defined, Type TBA8 RTM Set Class is TBA7. This document defines one C_Type, Type TBA8
RTM Set. The RTM_SET object format presented in Figure 5 RTM Set. The RTM_SET object format presented in Figure 5
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Sub-objects ~ ~ Sub-objects ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 51 skipping to change at page 12, line 17
The RTM Set object contains an ordered list, from egress LSR to The RTM Set object contains an ordered list, from egress LSR to
ingress LSR, of the RTM capable LSRs along the LSP's path. ingress LSR, of the RTM capable LSRs along the LSP's path.
The contents of a RTM_SET object are a series of variable-length data The contents of a RTM_SET object are a series of variable-length data
items called sub-objects. Each sub-object has its own Length field. items called sub-objects. Each sub-object has its own Length field.
The length contains the total length of the sub-object in bytes, The length contains the total length of the sub-object in bytes,
including the Type and Length fields. The length MUST always be a including the Type and Length fields. The length MUST always be a
multiple of 4, and at least 8 (smallest IPv4 sub-object). multiple of 4, and at least 8 (smallest IPv4 sub-object).
Sub-objects are organized as a last-in-first-out stack. The first Sub-objects are organized as a last-in-first-out stack. The first
sub-object relative to the beginning of RSO is considered the top. -out sub-object relative to the beginning of RSO is considered the
top. The last-out sub-object is considered the bottom. When a new
The last sub-object is considered the bottom. When a new sub-object sub-object is added, it is always added to the top.
is added, it is always added to the top.
Three kinds of sub-objects for RSO are currently defined. Three kinds of sub-objects for RSO are currently defined.
4.7.1.1. IPv4 Sub-object 4.7.1.1. IPv4 Sub-object
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | | Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 14 skipping to change at page 14, line 28
The identifier assigned to the link by the LSR specified by the The identifier assigned to the link by the LSR specified by the
Router ID. Router ID.
Flags Flags
TBD TBD
5. Data Plane Theory of Operation 5. Data Plane Theory of Operation
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 or if this is the special case of described in Section 4.6 or as described in the second paragraph of
homogeneous RTM-capable IP/MPLS domain discussed in the last Section 4 and in Section 4.6, ingress LSR MAY begin sending RTM
paragraph of Section 4, ingress LSR MAY begin sending RTM packets to packets to the first downstream RTM capable LSR on that path. Each
the first downstream RTM capable LSR on that path. Each RTM packet RTM packet has its Scratch Pad field initialized and its TTL set to
has its Scratch Pad field initialized and its TTL set to expire on expire on the next downstream RTM-capable LSR. Each RTM-capable LSR
the next downstream RTM-capable LSR. Each RTM-capable LSR on the on the explicit path receives an RTM packet and records the time at
explicit path receives an RTM packet and records the time at which it which it receives that packet at its ingress interface as well as the
receives that packet at its ingress interface as well as the time at time at which it transmits that packet from its egress interface;
which it transmits that packet from its egress interface; this should this should be done as close to the physical layer as possible to
be done as close to the physical layer as possible to ensure precise ensure precise accuracy in time determination. The RTM-capable LSR
accuracy in time determination. The RTM-capable LSR determines the determines the difference between those two times; for 1-step
difference between those two times; for 1-step operation, this operation, this difference is determined just prior to or while
difference is determined just prior to or while sending the packet, sending the packet, and the RTM-capable egress interface adds it to
and the RTM-capable egress interface adds it to the value in the the value in the Scratch Pad field of the message in progress. Note,
Scratch Pad field of the message in progress. Note, for the purpose for the purpose of calculating a residence time, a common free
of calculating a residence time, a common free running clock running clock synchronizing all the involved interfaces may be
synchronizing all the involved interfaces may be sufficient, as, for sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond
example, 4.6 ppm accuracy leads to 4.6 nanosecond error for residence error for residence time on the order of 1 millisecond.
time on the order of 1 millisecond.
For 2-step operation, the difference between packet arrival time (at For 2-step operation, the difference between packet arrival time (at
an ingress interface) and subsequent departure time (from an egress an ingress interface) and subsequent departure time (from an egress
interface) is determined at some later time prior to sending a 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 1-step
and 2-step operation. and 2-step operation.
The RTM capable LSR also sets the RTM packet's TTL to expire on the
next downstream RTM capable LSR.
The last RTM-capable LSR on the LSP MAY then use the value in the The last RTM-capable LSR on the LSP MAY then use the value in the
Scratch Pad field to perform time correction, if there is no follow- Scratch Pad field to perform time correction, if there is no follow-
up message. For example, the egress LSR may be a PTP Boundary Clock up message. For example, the egress LSR may be a PTP Boundary Clock
synchronized to a Master Clock and will use the value in the Scratch synchronized to a Master Clock and will use the value in the Scratch
Pad Field to update PTP's correctionField. Pad Field to update PTP's correctionField.
6. Applicable PTP Scenarios 6. Applicable PTP Scenarios
The proposed approach can be directly integrated in a PTP network The proposed approach can be directly integrated in a PTP network
based on delay request-response mechanism. The RTM capable LSR nodes based on the IEEE 1588 delay reqest-response mechanism. The RTM
act as end-to-end transparent clocks, and typically boundary clocks, capable LSR nodes act as end-to-end transparent clocks, and typically
at the edges of the MPLS network, use the value in the Scratch Pad boundary clocks, at the edges of the MPLS network, use the value in
field to update the correctionField of the corresponding PTP event the Scratch Pad field to update the correctionField of the
packet prior to performing the usual PTP processing. corresponding PTP event packet prior to performing the usual PTP
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 correct follow-up fashion, each 2-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: 2-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 2-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 behaviour 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, that is, the
specific PTP port of the boundary clock connected to the MPLS specific PTP port of the boundary clock connected to the MPLS
network. The Sequence ID is the sequence ID of the PTP message network. The Sequence ID is the sequence ID of the PTP message
carried in the Value field of the 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
2-step mode device - must stay set accordingly until the original and 2-step mode device, MUST stay set accordingly until the original and
follow-up message 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 2-step RTM capable egress
interface will need to examine the S-bit in the Flags field of the 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 - 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
skipping to change at page 17, line 24 skipping to change at page 17, line 32
upstream direction, an RTM packet must be created to carry the upstream direction, an RTM packet must be created to carry the
residence time on the associated downstream Delay Resp message. residence time on the associated downstream Delay Resp message.
The last RTM node of the MPLS network in addition to update the The last RTM node of the MPLS network in addition to update the
correctionField of the associated PTP packet, must also properly correctionField of the associated PTP packet, must also properly
handle the two-step flag of the PTP packets. handle the two-step flag of the PTP packets.
B) When the PTP network connected to the MPLS and RTM node, operates 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 in one-step clock mode, the associated RTM packet must be created by
the RTM node itself. The associated RTM packet including the PTP the RTM node itself. The associated RTM packet including the PTP
event packet needs now to indicate that a "follow up" message will be event packet needs now to indicate that a follow up message will be
coming. coming.
The last RTM node of the LSP, modeif it receives an RTM message with The last RTM node of the LSP, modeif it receives an RTM message with
a PTP payload indicating a follow-up message will be forthcoming, a PTP payload indicating a follow-up message will be forthcoming,
must generate a follow-up message and properly set the two-step flag must generate a follow-up message and properly set the two-step flag
of the PTP packets. of the PTP packets.
8. IANA Considerations 8. IANA Considerations
8.1. New RTM G-ACh 8.1. New RTM G-ACh
skipping to change at page 21, line 7 skipping to change at page 21, line 27
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. Acknowledgements 10. Acknowledgements
TBD Authors want to thank Loa Andersson for his thorough review and
thoghtful comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-ospf-ospfv3-lsa-extend] [I-D.ietf-ospf-ospfv3-lsa-extend]
Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-06 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-06
(work in progress), February 2015. (work in progress), February 2015.
[I-D.ietf-ospf-prefix-link-attr] [I-D.ietf-ospf-prefix-link-attr]
Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", draft-ietf-ospf-prefix-link-attr-03 (work Advertisement", draft-ietf-ospf-prefix-link-attr-04 (work
in progress), February 2015. in progress), April 2015.
[IEEE.1588.2008] [IEEE.1588.2008]
"Standard for a Precision Clock Synchronization Protocol "Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems", IEEE for Networked Measurement and Control Systems", IEEE
Standard 1588, March 2008. Standard 1588, March 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
 End of changes. 46 change blocks. 
127 lines changed or deleted 140 lines changed or added

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