draft-ietf-mpls-residence-time-01.txt   draft-ietf-mpls-residence-time-02.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: July 31, 2016 Ericsson Expires: August 13, 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
January 28, 2016 February 10, 2016
Residence Time Measurement in MPLS network Residence Time Measurement in MPLS network
draft-ietf-mpls-residence-time-01 draft-ietf-mpls-residence-time-02
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 July 31, 2016. This Internet-Draft will expire on August 13, 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 Object . . . . . . . . . . . . . . . . . . . . . 11 4.7. RTM_SET Sub-object . . . . . . . . . . . . . . . . . . . 11
4.7.1. RSO Sub-objects . . . . . . . . . . . . . . . . . . . 12 4.7.1. RSSO 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 . . . . . . . . . . . . . . . . . 19 8.4. RTM Capability sub-TLV . . . . . . . . . . . . . . . . . 19
8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 20 8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 20
8.6. RTM_SET Object RSVP Class Number, Class Type and Sub- 8.6. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 20
object Types . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 23
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 3, line 25 skipping to change at page 3, line 25
Time, is one of on-path support types defined in [IEEE.1588.2008] and Time, is one of on-path support types defined in [IEEE.1588.2008] and
can be used to improve the accuracy of clock synchronization. This can be used to improve the accuracy of clock synchronization. This
document defines new Generalized Associated Channel (G-ACh) that can document defines new Generalized Associated Channel (G-ACh) that can
be used in Multi-Protocol Label Switching (MPLS) network to measure be used in Multi-Protocol Label Switching (MPLS) network to measure
Residence Time over Label Switched Path (LSP). Mechanisms for Residence Time over Label Switched Path (LSP). Mechanisms for
transport of time synchronization protocol packets over MPLS are out transport of time synchronization protocol packets over MPLS are out
of scope in this document. of scope in this document.
Though it is possible to use RTM over LSPs instantiated using LDP Though it is possible to use RTM over LSPs instantiated using LDP
such scenarios are outside the scope of this document. The scope of such scenarios are outside the scope of this document. The scope of
this document is on LSPs instantiated using RSVP-TE [RFC3209] because this document is on Traffic Engineered LSPs because the LSP's path
the LSP's path can be determined. can be either explicitly specified or, at the minimum, can be
determined when signaling. Such LSP can be instantiated either by
using RSVP-TE [RFC3209] or Path Computation Element [RFC4655]. The
PCE-based scenario is for further study and is outside the scope of
this document.
[I-D.ietf-tictoc-1588overmpls] describes alternative method of on- [I-D.ietf-tictoc-1588overmpls] describes alternative method of on-
path support for timing distribution protocols. Comparison of path support for timing distribution protocols. Comparison of
proposed solutions is outside the scope of this document. proposed solutions is outside the scope of 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
skipping to change at page 3, line 49 skipping to change at page 4, line 4
TTL: Time-to-Live TTL: Time-to-Live
G-ACh: Generic Associated Channel G-ACh: Generic Associated Channel
GAL: Generic Associated Channel Label GAL: Generic Associated Channel Label
NTP: Network Time Protocol NTP: Network Time Protocol
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
RRO: Record Route Object RRO: Record Route Object
RSO: RTM Set 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
skipping to change at page 5, line 42 skipping to change at page 5, line 42
Figure 1: RTM 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 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 (TBA1) to be allocated by IANA,
packet as such. identifies the 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-
capable LSR MUST initialize the Scratch Pad field, it SHOULD set capable LSR MUST initialize the Scratch Pad field, it SHOULD set
it to zero value. The Scratch Pad is used to accumulate the it to zero value. The Scratch Pad is used to accumulate the
residence time spent in each RTM capable LSR transited by the residence time spent in each RTM capable LSR transited by the
packet on its path from ingress LSR to egress LSR. Its format is packet on its path from ingress LSR to egress LSR. Its format is
IEEE double precision and its units are nanoseconds. Note: IEEE double precision and its units are nanoseconds. Note:
depending on one-step or two-step operation (Section 7), the depending on one-step or two-step operation (Section 7), the
residence time might be related to the same packet carried in the residence time might be related to the same packet carried in the
Value field or to a packet carried in a different RTM packet. Value field or to a packet carried in a different RTM packet.
skipping to change at page 8, line 42 skipping to change at page 8, line 42
LSAs sent from a router which describe a particular interface that LSAs sent from a router which describe a particular interface that
does not support the same capability for RTM messages it receives. does not support the same capability for RTM messages it receives.
4.2. RTM Capability Sub-TLV 4.2. RTM Capability Sub-TLV
The format for the RTM Capabilities sub-TLV is presented in Figure 4 The format for the RTM Capabilities sub-TLV is presented in Figure 4
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(TBA5) | Length | | Type(TBA2) | 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 (TBA2) will be assigned by IANA from appropriate
registries.
o Length MUST be set to 4. o Length MUST be set to 4.
o RTM (capability) - is a three-bit long bit-map field with values o RTM (capability) - is a three-bit long bit-map field with values
defined as follows: defined as follows:
* 0b001 - one-step RTM supported; * 0b001 - one-step RTM supported;
* 0b010 - two-step RTM supported; * 0b010 - two-step RTM supported;
skipping to change at page 10, line 19 skipping to change at page 10, line 19
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 required by o The D bit of the Flags field MUST be cleared as required by
[RFC6823]. [RFC6823].
o The I bit and the V bit MUST be set accordingly depending on o The I bit and the V bit MUST be set accordingly depending on
whether RTM capability being advertised 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 (TBA3) will be assigned from the Application
Identifiers for TLV 251 IANA registry. The RTM Capability sub-TLV, Identifiers for TLV 251 IANA registry. The RTM Capability sub-TLV,
presented in Figure 4, MUST be included in GENINFO TLV in Application presented in Figure 4, MUST be included in GENINFO TLV in Application
Specific Information. Specific Information.
4.6. RSVP-TE Control Plane Operation to Support RTM 4.6. RSVP-TE Control Plane Operation to Support RTM
Throughout this document we refer to an LSR as RTM capable LSR when Throughout this document we refer to an LSR as RTM capable LSR when
at least one of its interfaces is RTM capable. Figure 5 provides an at least one of its interfaces is RTM capable. Figure 5 provides an
example of relationship between roles a network element may have in example of relationship between roles a network element may have in
PTP over MPLS scenario and RTM capability: PTP over MPLS scenario and RTM capability:
skipping to change at page 11, line 19 skipping to change at page 11, line 19
o F is the egress LER for the MPLS LSP and is not RTM capable; o F is the egress LER for the MPLS LSP and is not RTM capable;
o G is a Boundary Clock with its ingress port in Slave state. Node 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 RTM Set it places initialized Record Route Object (RRO) [RFC3209] and
Object (RSO) [Section 4.7], which tell the egress LSR that RTM is LSP_ATTRIBUTES Object [RFC5420] with RTM Set Sub-object (RSSO)
requested for this LSP. [Section 4.7], which indicates to the egress LSR that RTM is
requested for this LSP. RSSO SHOULD NOT be included into the
LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it is known that
all LSRs support RSSO, because then LSR that does not recognize RSSO
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 RSO. The RSO received Path message, it includes initialized RRO and RSSO. The
contains an ordered list, from egress LSR to ingress LSR, of the RTM RSSO contains an ordered list, from egress LSR to ingress LSR, of the
capable LSRs along the LSP's path. Each such LSR will use the ID of RTM capable LSRs along the LSP's path. Each such LSR will use the ID
the first LSR in the RSO in conjunction with the RRO to compute the of the first LSR in the RSSO in conjunction with the RRO to compute
hop count to its downstream LSR with reachable RTM capable interface. the hop count to its downstream LSR with reachable RTM capable
It will also insert its ID at the beginning of the RTM Set Object interface. It will also insert its ID at the beginning of the RSSO
before forwarding the Resv upstream. 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 RSO MAY be omitted. support RTM. In this case the RSSO and LSP_ATTRIBUTES Object MAY be
omitted.
4.7. RTM_SET Object 4.7. RTM_SET Sub-object
RTM capable interfaces can be recorded via RTM_SET object (RSO). The RTM capable interfaces can be recorded via RTM_SET sub-object (RSSO).
RTM Set Class is TBA7. This document defines one C_Type, Type TBA8 The RTM Set Class is TBA7. This document defines one C_Type, Type
RTM Set. The RTM_SET object format presented in Figure 6 TBA8 RTM Set. The RTM_SET sub-object format is of generic Type,
Length, Value (TLV), presented in Figure 6
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Type | Length | Reserved |
~ Sub-objects ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RTM Set object format Figure 6: RTM Set Sub-object format
The contents of a RTM_SET object are a series of variable-length data Type value (TBA4) will be assigned by IANA from its Attributes TLV
items called sub-objects. The sub-objects are defined in Space sub-registry.
Section 4.7.1 below.
The RSO can be present in both RSVP Path and Resv messages. If a The Length contains the total length of the sub-object in bytes,
Path message contains multiple RSOs, only the first RSO is including the Type and Length fields.
meaningful. Subsequent RSOs SHOULD be ignored and SHOULD NOT be
propagated. Similarly, if in a Resv message multiple RSOs are 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
sub-TLVs are defined in Section 4.7.1 below.
The RSSO can be present in both RSVP Path and Resv messages. If a
Path message contains multiple RSSOs, only the first RSSO is
meaningful. Subsequent RSSOs SHOULD be ignored and SHOULD NOT be
propagated. Similarly, if in a Resv message multiple RSSOs are
encountered following a FILTER_SPEC before another FILTER_SPEC is encountered following a FILTER_SPEC before another FILTER_SPEC is
encountered, only the first RSO is meaningful. Subsequent RSOs encountered, only the first RSSO is meaningful. Subsequent RSSOs
SHOULD be ignored and SHOULD NOT be propagated. SHOULD be ignored and SHOULD NOT be propagated.
4.7.1. RSO Sub-objects 4.7.1. RSSO Sub-TLVs
The RTM Set 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 object are a series of variable-length data The contents of a RTM_SET sub-object are a series of variable-length
items called sub-objects. Each sub-object has its own Length field. sub-TLVs. Each sub-TLV has its own Length field. The Length
The length contains the total length of the sub-object in bytes, contains the total length of the sub-TLV in bytes, including the Type
including the Type and Length fields. The length MUST always be a and Length fields. The Length MUST always be a multiple of 4, and at
multiple of 4, and at least 8 (smallest IPv4 sub-object). least 8 (smallest IPv4 sub-object).
Sub-objects are organized as a last-in-first-out stack. The first Sub-TLVs are organized as a last-in-first-out stack. The first -out
-out sub-object relative to the beginning of RSO is considered the sub-TLV relative to the beginning of RSSO is considered the top. The
top. The last-out sub-object is considered the bottom. When a new last-out sub-TLV is considered the bottom. When a new sub-TLV is
sub-object is added, it is always added to the top. added, it is always added to the top.
Three kinds of sub-objects for RSO are currently defined. Three kinds of sub-TLVs for RSSO are currently defined.
4.7.1.1. IPv4 Sub-TLV
4.7.1.1. IPv4 Sub-object
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | | Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address | | IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IPv4 sub-object 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-object 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 Flags
TBD TBD
4.7.1.2. IPv6 Sub-object 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 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 address | | IPv6 address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IPv6 sub-object format Figure 8: IPv6 sub-TLV format
Type Type
0x02 IPv6 address 0x02 IPv6 address
Length Length
The Length contains the total length of the sub-object in bytes,
The Length contains the total length of the sub-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 Flags
TBD TBD
4.7.1.3. Unnumbered Interface Sub-object 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 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID | | Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: IPv4 sub-object format Figure 9: IPv4 sub-TLV format
Type Type
0x03 Unnumbered interface 0x03 Unnumbered interface
Length Length
The Length contains the total length of the sub-object in bytes, The Length contains the total length of the sub-TLV in bytes,
including the Type and Length fields. The Length is always 12. including the Type and Length fields. The Length is always 12.
Router ID Router ID
The Router ID interpreted as discussed in the Section 2 of RFC The Router ID interpreted as discussed in the Section 2 of RFC
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
skipping to change at page 20, line 18 skipping to change at page 20, line 18
Application Identifiers for TLV 251 registry as follows: Application Identifiers for TLV 251 registry as follows:
+-------+-------------+---------------+ +-------+-------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------+---------------+ +-------+-------------+---------------+
| TBA3 | RTM | This document | | TBA3 | RTM | This document |
+-------+-------------+---------------+ +-------+-------------+---------------+
Table 5: IS-IS RTM Application ID Table 5: IS-IS RTM Application ID
8.6. RTM_SET Object RSVP Class Number, Class Type and Sub-object Types 8.6. RTM_SET Sub-object RSVP Type and sub-TLVs
IANA is requested to assign a new Class Number for RTM_SET object as
follows:
+-------+----------------+---------------+
| Value | Description | Reference |
+-------+----------------+---------------+
| TBA4 | RTM_SET object | This document |
+-------+----------------+---------------+
Table 6: RTM_SET object Class
IANA is requested to assign a new Class Type for RTM_SET object as IANA is requested to assign a new Type for RTM_SET sub-object from
follows: Attributes TLV Space sub-registry as follows:
+-------+-------------+---------------+ +----+------------+-----------+----------------+---------+----------+
| Value | Description | Reference | | Ty | Name | Allowed | Allowed on LSP | Allowed | Referenc |
+-------+-------------+---------------+ | pe | | on LSP_AT | _REQUIRED_ATTR | on LSP | e |
| TBA5 | RTM Set | This document | | | | TRIBUTES | IBUTES | Hop Att | |
+-------+-------------+---------------+ | | | | | ributes | |
+----+------------+-----------+----------------+---------+----------+
| TB | RTM_SET | Yes | No | No | This |
| A4 | sub-object | | | | document |
+----+------------+-----------+----------------+---------+----------+
Table 7: RTM_SET object Class Type Table 6: RTM_SET Sub-object Type
IANA requested to create new sub-registry for sub-object types of IANA requested to create new sub-registry for sub-TLV types of
RTM_SET 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 7: 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
skipping to change at page 22, line 49 skipping to change at page 22, line 35
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <http://www.rfc-editor.org/info/rfc4385>. February 2006, <http://www.rfc-editor.org/info/rfc4385>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <http://www.rfc-editor.org/info/rfc5085>. December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586, "MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009, DOI 10.17487/RFC5586, June 2009,
<http://www.rfc-editor.org/info/rfc5586>. <http://www.rfc-editor.org/info/rfc5586>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <http://www.rfc-editor.org/info/rfc5905>.
skipping to change at page 23, line 39 skipping to change at page 23, line 34
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS Montini, "Transporting Timing messages over MPLS
Networks", draft-ietf-tictoc-1588overmpls-07 (work in Networks", draft-ietf-tictoc-1588overmpls-07 (work in
progress), October 2015. progress), October 2015.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<http://www.rfc-editor.org/info/rfc4202>. <http://www.rfc-editor.org/info/rfc4202>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011, DOI 10.17487/RFC6374, September 2011,
<http://www.rfc-editor.org/info/rfc6374>. <http://www.rfc-editor.org/info/rfc6374>.
 End of changes. 48 change blocks. 
90 lines changed or deleted 115 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/