draft-ietf-mpls-residence-time-03.txt   draft-ietf-mpls-residence-time-04.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: August 15, 2016 Ericsson Expires: August 21, 2016 Ericsson
J. Drake J. Drake
Juniper Networks Juniper Networks
S. Bryant S. Bryant
Cisco Systems Cisco Systems
A. Vainshtein A. Vainshtein
ECI Telecom ECI Telecom
February 12, 2016 February 18, 2016
Residence Time Measurement in MPLS network Residence Time Measurement in MPLS network
draft-ietf-mpls-residence-time-03 draft-ietf-mpls-residence-time-04
Abstract Abstract
This document specifies G-ACh based Residence Time Measurement and This document specifies G-ACh based Residence Time Measurement and
how it can be used by time synchronization protocols being how it can be used by time synchronization protocols being
transported over MPLS domain. transported over MPLS domain.
Residence time is the variable part of propagation delay of timing Residence time is the variable part of propagation delay of timing
and synchronization messages and knowing what this delay is for each and synchronization messages and knowing what this delay is for each
message allows for a more accurate determination of the delay to be message allows for a more accurate determination of the delay to be
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 15, 2016. This Internet-Draft will expire on August 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4 2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4
3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 5 3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 5
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 . . . . . . . . . . 9
4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10 4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10
4.7. RTM_SET Sub-object . . . . . . . . . . . . . . . . . . . 11 4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11
4.7.1. RSSO Sub-TLVs . . . . . . . . . . . . . . . . . . . . 12 4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 12
5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 15 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 15
6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 15 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 15
7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 16 7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 18 8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 18
8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 18 8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 18
8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 19 8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 19
8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 19 8.4. New Error Codes . . . . . . . . . . . . . . . . . . . . . 19
8.5. RTM Capability sub-TLV in OSPFv3 . . . . . . . . . . . . 20 8.5. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20
8.6. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 20 8.6. RTM Capability sub-TLV in OSPFv3 . . . . . . . . . . . . 20
8.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 20 8.7. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 20
8.8. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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. Measurement of the time a PTP event message spends domain. Measurement of the time a PTP event message spends
traversing a node (using precise times of receipt at an ingress traversing a node (using precise times of receipt at an ingress
interface and transmission at an egress interface), called Residence interface and transmission at an egress interface), called Residence
skipping to change at page 4, line 16 skipping to change at page 4, line 16
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
RRO: Record Route Object RRO: Record Route Object
RSSO: RTM Set Sub-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].
skipping to change at page 11, line 20 skipping to change at page 11, line 20
o G is a Boundary Clock with its ingress port in Slave state. Node o G is a Boundary Clock with its ingress port in Slave state. Node
G receives PTP messages. G receives PTP messages.
An ingress LSR that is configured to perform RTM along a path through An ingress LSR that is configured to perform RTM along a path through
an MPLS network to an egress LSR verifies that the selected egress an MPLS network to an egress LSR verifies that the selected egress
LSR has an interface that supports RTM via the egress LSR's LSR has an interface that supports RTM via the egress LSR's
advertisement of the RTM Capability sub-TLV. In the Path message advertisement of the RTM Capability sub-TLV. In the Path message
that the ingress LSR uses to instantiate the LSP to that egress LSR that the ingress LSR uses to instantiate the LSP to that egress LSR
it places initialized Record Route Object (RRO) [RFC3209] and it places initialized Record Route Object (RRO) [RFC3209] and
LSP_ATTRIBUTES Object [RFC5420] with RTM Set Sub-object (RSSO) LSP_ATTRIBUTES Object [RFC5420] with RTM_SET TLV [Section 4.7], also
[Section 4.7], which indicates to the egress LSR that RTM is referred as RTM_SET in this document, which indicates to the egress
requested for this LSP. RSSO SHOULD NOT be included into the LSR that RTM is requested for this LSP. RTM_SET SHOULD NOT be
LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it is known that included in the LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it
all LSRs support RSSO, because then LSR that does not recognize RSSO is known that all LSRs support RTM_SET TLV, because an LSR that does
would reject the Path message. not recognize RTM_SET would reject the Path message.
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 RRO and RSSO. The received Path message, it includes initialized RRO and RTM_SET TLV in
RSSO contains an ordered list, from egress LSR to ingress LSR, of the LSP_ATTRIBUTES object. The RTM_SET contains an ordered list, from
RTM capable LSRs along the LSP's path. Each such LSR will use the ID egress LSR to ingress LSR, of the RTM capable LSRs along the LSP's
of the first LSR in the RSSO in conjunction with the RRO to compute path. Each such LSR will use the ID of the first LSR in the RTM_SET
the hop count to its downstream LSR with reachable RTM capable in conjunction with the RRO to compute the hop count to its
interface. It will also insert its ID at the beginning of the RSSO downstream LSR with reachable RTM capable interface. The calculated
before forwarding the Resv message upstream. value is used by the LSR as TTL value in outgoing label to reach the
next RTM capable LSR on the LSP. It will also insert its ID at the
beginning of the RTM_SET before forwarding the Resv message 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 RSSO and LSP_ATTRIBUTES Object MAY be support RTM. In this case the RTM_SET TLV and LSP_ATTRIBUTES Object
omitted. MAY be omitted.
4.7. RTM_SET Sub-object 4.7. RTM_SET TLV
RTM capable interfaces can be recorded via RTM_SET sub-object (RSSO). RTM capable interfaces can be recorded via RTM_SET TLV. The RTM_SET
The RTM_SET sub-object format is of generic Type, Length, Value sub-object format is of generic Type, Length, Value (TLV), presented
(TLV), presented in Figure 6 in Figure 6
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RTM Set Sub-object format Figure 6: RTM_SET TLV format
Type value (TBA5) will be assigned by IANA from its Attributes TLV Type value (TBA5) will be assigned by IANA from its Attributes TLV
Space sub-registry. Space sub-registry.
The Length contains the total length of the sub-object in bytes, The Length contains the total length of the sub-object in bytes,
including the Type and Length fields. including the Type and Length fields.
Reserved field must be zeroed on transmit and ignored on receipt. Reserved field must be zeroed on transmit and ignored on receipt.
The content of an RSSO is a series of variable-length sub-TLVs. The The content of an RTM_SET TLV is a series of variable-length sub-
sub-TLVs are defined in Section 4.7.1 below. TLVs. The sub-TLVs are defined in Section 4.7.1 below.
The RSSO can be present in both RSVP Path and Resv messages. If a Only a single RTM_SET can be present in the LSP_ATTRIBUTES object.
Path message contains multiple RSSOs, only the first RSSO is If more than one RTM_SET TLV is found in the LSP_ATTRIBUTES object
meaningful. Subsequent RSSOs SHOULD be ignored and SHOULD NOT be the LSP setup MUST fail with generation of the PathErr message with
propagated. Similarly, if in a Resv message multiple RSSOs are Error Code Duplicate TLV Section 8.4 and Error Value contains Type
encountered following a FILTER_SPEC before another FILTER_SPEC is value in its 8 least significant bits.
encountered, only the first RSSO is meaningful. Subsequent RSSOs
SHOULD be ignored and SHOULD NOT be propagated.
4.7.1. RSSO Sub-TLVs 4.7.1. RTM_SET Sub-TLVs
The RTM Set sub-object contains an ordered list, from egress LSR to The RTM Set sub-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 sub-object are a series of variable-length 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 sub-TLVs. Each sub-TLV has its own Length field. The Length
contains the total length of the sub-TLV in bytes, including the Type contains the total length of the sub-TLV in bytes, including the Type
and Length fields. The Length MUST always be a multiple of 4, and at and Length fields. The Length MUST always be a multiple of 4, and at
least 8 (smallest IPv4 sub-object). least 8 (smallest IPv4 sub-object).
Sub-TLVs are organized as a last-in-first-out stack. The first -out Sub-TLVs are organized as a last-in-first-out stack. The first -out
sub-TLV relative to the beginning of RSSO is considered the top. The sub-TLV relative to the beginning of RTM_SET TLV is considered the
last-out sub-TLV is considered the bottom. When a new sub-TLV is top. The last-out sub-TLV is considered the bottom. When a new sub-
added, it is always added to the top. TLV is added, it is always added to the top. Only a single RTM_SET
sub-TLV with the given Value field MUST be present in the RTM_SET
TLV. If more than one sub-TLV is found the LSP setup MUST fail with
the generation of a PathErr message with the Error Code "Duplicate
sub-TLV" Section 8.4 and Error Value contains 16-bit value composed
of (Type of TLV, Type of sub-TLV).
Three kinds of sub-TLVs for RSSO are currently defined. Three kinds of sub-TLVs for RTM_SET are currently defined.
4.7.1.1. IPv4 Sub-TLV 4.7.1.1. IPv4 Sub-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 | Flags | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address | | IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IPv4 sub-TLV format Figure 7: IPv4 sub-TLV format
Type Type
0x01 IPv4 address 0x01 IPv4 address
Length Length
The Length contains the total length of the sub-TLV in bytes, The Length contains the total length of the sub-TLV in bytes,
including the Type and Length fields. The Length is always 8. including the Type and Length fields. The Length is always 8.
IPv4 address IPv4 address
A 32-bit unicast host address. A 32-bit unicast host address.
Flags Reserved
TBD Zeroed on transmission and ignored on receipt.
4.7.1.2. IPv6 Sub-TLV 4.7.1.2. IPv6 Sub-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 | Flags | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 address | | IPv6 address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IPv6 sub-TLV format Figure 8: IPv6 sub-TLV format
Type Type
skipping to change at page 14, line 14 skipping to change at page 14, line 15
Length Length
The Length contains the total length of the sub-TLV in bytes, The Length contains the total length of the sub-TLV in bytes,
including the Type and Length fields. The Length is always 20. including the Type and Length fields. The Length is always 20.
IPv6 address IPv6 address
A 128-bit unicast host address. A 128-bit unicast host address.
Flags Reserved
TBD Zeroed on transmission and ignored on receipt.
4.7.1.3. Unnumbered Interface Sub-TLV 4.7.1.3. Unnumbered Interface Sub-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 | Flags | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID | | Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: IPv4 sub-TLV format Figure 9: IPv4 sub-TLV format
Type Type
skipping to change at page 14, line 51 skipping to change at page 15, line 5
Router ID Router ID
The Router ID interpreted as discussed in the Section 2 of RFC The Router ID interpreted as discussed in the Section 2 of RFC
3447 [RFC3477]. 3447 [RFC3477].
Interface ID Interface ID
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 Reserved
TBD
Zeroed on transmission and ignored on receipt.
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 as described in the second paragraph of described in Section 4.6 or as described in the second paragraph of
Section 4 and in Section 4.6, ingress LSR MAY begin sending RTM Section 4 and in Section 4.6, ingress LSR MAY begin sending RTM
packets to the first downstream RTM capable LSR on that path. Each packets to the first downstream RTM capable LSR on that path. Each
RTM packet has its Scratch Pad field initialized and its TTL set to RTM packet has its Scratch Pad field initialized and its TTL set to
expire on the next downstream RTM-capable LSR. Each RTM-capable LSR expire on the next downstream RTM-capable LSR. Each RTM-capable LSR
on the explicit path receives an RTM packet and records the time at on the explicit path receives an RTM packet and records the time at
skipping to change at page 19, line 41 skipping to change at page 19, line 41
+-----------+-------------+-------------------------+ +-----------+-------------+-------------------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| 1 | PTP 2-step | This document | | 1 | PTP 2-step | This document |
| 2-127 | Reserved | IETF Consensus | | 2-127 | Reserved | IETF Consensus |
| 128 - 191 | Reserved | First Come First Served | | 128 - 191 | Reserved | First Come First Served |
| 192 - 255 | Reserved | Private Use | | 192 - 255 | Reserved | Private Use |
+-----------+-------------+-------------------------+ +-----------+-------------+-------------------------+
Table 3: RTM Sub-TLV Type Table 3: RTM Sub-TLV Type
8.4. RTM Capability sub-TLV in OSPFv2 8.4. New Error Codes
IANA is requested to assign new Error Codes from Error Codes and
Globally-Defined Error Value Sub-Codes registry
+------------+-------------------+---------------+
| Error Code | Meaning | Reference |
+------------+-------------------+---------------+
| TBA6 | Duplicate TLV | This document |
| TBA7 | Duplicate sub-TLV | This document |
+------------+-------------------+---------------+
Table 4: New Error Codes
8.5. RTM Capability sub-TLV in OSPFv2
IANA is requested to assign a new type for RTM Capability sub-TLV IANA is requested to assign a new type for RTM Capability sub-TLV
from OSPFv2 Extended Link TLV Sub-TLVs registry as follows: from OSPFv2 Extended Link TLV Sub-TLVs registry as follows:
+-------+----------------+---------------+ +-------+----------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+----------------+---------------+ +-------+----------------+---------------+
| TBA2 | RTM Capability | This document | | TBA2 | RTM Capability | This document |
+-------+----------------+---------------+ +-------+----------------+---------------+
Table 4: RTM Capability sub-TLV Table 5: RTM Capability sub-TLV
8.5. RTM Capability sub-TLV in OSPFv3 8.6. RTM Capability sub-TLV in OSPFv3
IANA is requested to assign a new type for RTM Capability sub-TLV IANA is requested to assign a new type for RTM Capability sub-TLV
from future OSPFv3 Extended-LSA Sub-TLVs registry that would be part from future OSPFv3 Extended-LSA Sub-TLVs registry that would be part
of OSPFv3 IANA registry as follows: of OSPFv3 IANA registry as follows:
+-------+----------------+---------------+ +-------+----------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+----------------+---------------+ +-------+----------------+---------------+
| TBA3 | RTM Capability | This document | | TBA3 | RTM Capability | This document |
+-------+----------------+---------------+ +-------+----------------+---------------+
Table 5: RTM Capability sub-TLV Table 6: RTM Capability sub-TLV
8.6. IS-IS RTM Application ID 8.7. IS-IS RTM Application ID
IANA is requested to assign a new Application ID for RTM from the IANA is requested to assign a new Application ID for RTM from the
Application Identifiers for TLV 251 registry as follows: Application Identifiers for TLV 251 registry as follows:
+-------+-------------+---------------+ +-------+-------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------+---------------+ +-------+-------------+---------------+
| TBA4 | RTM | This document | | TBA4 | RTM | This document |
+-------+-------------+---------------+ +-------+-------------+---------------+
Table 6: IS-IS RTM Application ID Table 7: IS-IS RTM Application ID
8.7. RTM_SET Sub-object RSVP Type and sub-TLVs 8.8. RTM_SET Sub-object RSVP Type and sub-TLVs
IANA is requested to assign a new Type for RTM_SET sub-object from IANA is requested to assign a new Type for RTM_SET sub-object from
Attributes TLV Space sub-registry as follows: Attributes TLV Space sub-registry as follows:
+-----+------------+-----------+---------------+---------+----------+ +-----+------------+-----------+---------------+---------+----------+
| Typ | Name | Allowed | Allowed on | Allowed | Referenc | | Typ | Name | Allowed | Allowed on | Allowed | Referenc |
| e | | on LSP_A | LSP_REQUIRED_ | on LSP | e | | e | | on LSP_A | LSP_REQUIRED_ | on LSP | e |
| | | TTRIBUTES | ATTRIBUTES | Hop Att | | | | | TTRIBUTES | ATTRIBUTES | Hop Att | |
| | | | | ributes | | | | | | | ributes | |
+-----+------------+-----------+---------------+---------+----------+ +-----+------------+-----------+---------------+---------+----------+
| TBA | RTM_SET | Yes | No | No | This | | TBA | RTM_SET | Yes | No | No | This |
| 5 | sub-object | | | | document | | 5 | sub-object | | | | document |
+-----+------------+-----------+---------------+---------+----------+ +-----+------------+-----------+---------------+---------+----------+
Table 7: RTM_SET Sub-object Type Table 8: RTM_SET Sub-object Type
IANA requested to create new sub-registry for sub-TLV types of IANA requested to create new sub-registry for sub-TLV types of
RTM_SET sub-object as follows: RTM_SET sub-object as follows:
+-----------+----------------------+-------------------------+ +-----------+----------------------+-------------------------+
| Value | Description | Reference | | Value | Description | Reference |
+-----------+----------------------+-------------------------+ +-----------+----------------------+-------------------------+
| 0 | Reserved | | | 0 | Reserved | |
| 1 | IPv4 address | This document | | 1 | IPv4 address | This document |
| 2 | IPv6 address | This document | | 2 | IPv6 address | This document |
| 3 | Unnumbered interface | This document | | 3 | Unnumbered interface | This document |
| 4-127 | Reserved | IETF Consensus | | 4-127 | Reserved | IETF Consensus |
| 128 - 191 | Reserved | First Come First Served | | 128 - 191 | Reserved | First Come First Served |
| 192 - 255 | Reserved | Private Use | | 192 - 255 | Reserved | Private Use |
+-----------+----------------------+-------------------------+ +-----------+----------------------+-------------------------+
Table 8: RTM_SET object sub-object types Table 9: RTM_SET object sub-object types
9. Security Considerations 9. Security Considerations
Routers that support Residence Time Measurement are subject to the Routers that support Residence Time Measurement are subject to the
same security considerations as defined in [RFC5586] . same security considerations as defined in [RFC5586] .
In addition - particularly as applied to use related to PTP - there In addition - particularly as applied to use related to PTP - there
is a presumed trust model that depends on the existence of a trusted is a presumed trust model that depends on the existence of a trusted
relationship of at least all PTP-aware nodes on the path traversed by relationship of at least all PTP-aware nodes on the path traversed by
PTP messages. This is necessary as these nodes are expected to PTP messages. This is necessary as these nodes are expected to
 End of changes. 36 change blocks. 
65 lines changed or deleted 83 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/