--- 1/draft-ietf-mpls-residence-time-03.txt 2016-02-18 08:15:09.183473056 -0800 +++ 2/draft-ietf-mpls-residence-time-04.txt 2016-02-18 08:15:09.239474484 -0800 @@ -1,25 +1,25 @@ MPLS Working Group G. Mirsky Internet-Draft S. Ruffini Intended status: Standards Track E. Gray -Expires: August 15, 2016 Ericsson +Expires: August 21, 2016 Ericsson J. Drake Juniper Networks S. Bryant Cisco Systems A. Vainshtein ECI Telecom - February 12, 2016 + February 18, 2016 Residence Time Measurement in MPLS network - draft-ietf-mpls-residence-time-03 + draft-ietf-mpls-residence-time-04 Abstract This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 15, 2016. + This Internet-Draft will expire on August 21, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -67,38 +67,39 @@ 2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4 3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 5 3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 6 4. Control Plane Theory of Operation . . . . . . . . . . . . . . 7 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8 4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9 4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9 4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 9 4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10 - 4.7. RTM_SET Sub-object . . . . . . . . . . . . . . . . . . . 11 - 4.7.1. RSSO Sub-TLVs . . . . . . . . . . . . . . . . . . . . 12 + 4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 12 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 15 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 15 7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 18 8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 18 8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 19 - 8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 19 - 8.5. RTM Capability sub-TLV in OSPFv3 . . . . . . . . . . . . 20 - 8.6. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 20 - 8.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 20 + 8.4. New Error Codes . . . . . . . . . . . . . . . . . . . . . 19 + 8.5. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20 + 8.6. RTM Capability sub-TLV in OSPFv3 . . . . . . . . . . . . 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 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 - 11.2. Informative References . . . . . . . . . . . . . . . . . 23 + 11.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction Time synchronization protocols, Network Time Protocol version 4 (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 [IEEE.1588.2008] can be used to synchronize clocks across network domain. Measurement of the time a PTP event message spends traversing a node (using precise times of receipt at an ingress interface and transmission at an egress interface), called Residence @@ -143,22 +144,20 @@ PTP: Precision Time Protocol LSP: Label Switched Path LSR: Label Switching Router OAM: Operations, Administration, and Maintenance RRO: Record Route Object - RSSO: RTM Set Sub-object - RTM: Residence Time Measurement IGP: Internal Gateway Protocol 1.1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. @@ -476,134 +475,139 @@ o G is a Boundary Clock with its ingress port in Slave state. Node G receives PTP messages. 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 LSR has an interface that supports RTM via the egress LSR's advertisement of the RTM Capability sub-TLV. In the Path message that the ingress LSR uses to instantiate the LSP to that egress LSR it places initialized Record Route Object (RRO) [RFC3209] and - LSP_ATTRIBUTES Object [RFC5420] with RTM Set Sub-object (RSSO) - [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. + LSP_ATTRIBUTES Object [RFC5420] with RTM_SET TLV [Section 4.7], also + referred as RTM_SET in this document, which indicates to the egress + LSR that RTM is requested for this LSP. RTM_SET SHOULD NOT be + included in the LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it + is known that all LSRs support RTM_SET TLV, because an LSR that does + not recognize RTM_SET would reject the Path message. In the Resv message that the egress LSR sends in response to the - received Path message, it includes initialized RRO and RSSO. The - RSSO contains an ordered list, from egress LSR to ingress LSR, of the - RTM capable LSRs along the LSP's path. Each such LSR will use the ID - of the first LSR in the RSSO in conjunction with the RRO to compute - the hop count to its downstream LSR with reachable RTM capable - interface. It will also insert its ID at the beginning of the RSSO - before forwarding the Resv message upstream. + received Path message, it includes initialized RRO and RTM_SET TLV in + LSP_ATTRIBUTES object. The RTM_SET contains an ordered list, from + egress LSR to ingress LSR, of the RTM capable LSRs along the LSP's + path. Each such LSR will use the ID of the first LSR in the RTM_SET + in conjunction with the RRO to compute the hop count to its + downstream LSR with reachable RTM capable interface. The calculated + 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 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 expire on that first subsequent RTM capable LSR. It should be noted that RTM can also be used for LSPs instantiated using [RFC3209] in an environment in which all interfaces in an IGP - support RTM. In this case the RSSO and LSP_ATTRIBUTES Object MAY be - omitted. + support RTM. In this case the RTM_SET TLV and LSP_ATTRIBUTES Object + 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). - The RTM_SET sub-object format is of generic Type, Length, Value - (TLV), presented in Figure 6 + RTM capable interfaces can be recorded via RTM_SET TLV. The RTM_SET + sub-object format is of generic Type, Length, Value (TLV), presented + in Figure 6 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 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 Space sub-registry. The Length contains the total length of the sub-object in bytes, including the Type and Length fields. 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 content of an RTM_SET TLV 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, only the first RSSO is meaningful. Subsequent RSSOs - SHOULD be ignored and SHOULD NOT be propagated. + Only a single RTM_SET can be present in the LSP_ATTRIBUTES object. + If more than one RTM_SET TLV is found in the LSP_ATTRIBUTES object + the LSP setup MUST fail with generation of the PathErr message with + Error Code Duplicate TLV Section 8.4 and Error Value contains Type + value in its 8 least significant bits. -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 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 sub-TLVs. Each sub-TLV has its own Length field. The Length contains the total length of the sub-TLV in bytes, including the Type and Length fields. The Length MUST always be a multiple of 4, and at least 8 (smallest IPv4 sub-object). Sub-TLVs are organized as a last-in-first-out stack. The first -out - sub-TLV relative to the beginning of RSSO is considered the top. The - last-out sub-TLV is considered the bottom. When a new sub-TLV is - added, it is always added to the top. + sub-TLV relative to the beginning of RTM_SET TLV is considered the + top. The last-out sub-TLV is considered the bottom. When a new sub- + TLV is added, it is always added to the top. Only a single RTM_SET + sub-TLV with the given Value field MUST be present in the RTM_SET + TLV. If more than one sub-TLV is found the LSP setup MUST fail with + the generation of a 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 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Flags | + | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: IPv4 sub-TLV format Type 0x01 IPv4 address Length The Length contains the total length of the sub-TLV in bytes, including the Type and Length fields. The Length is always 8. IPv4 address A 32-bit unicast host address. - Flags + Reserved - TBD + Zeroed on transmission and ignored on receipt. 4.7.1.2. IPv6 Sub-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Flags | + | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: IPv6 sub-TLV format Type @@ -612,30 +615,30 @@ Length The Length contains the total length of the sub-TLV in bytes, including the Type and Length fields. The Length is always 20. IPv6 address A 128-bit unicast host address. - Flags + Reserved - TBD + Zeroed on transmission and ignored on receipt. 4.7.1.3. Unnumbered Interface Sub-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Flags | + | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: IPv4 sub-TLV format Type @@ -649,22 +652,23 @@ Router ID The Router ID interpreted as discussed in the Section 2 of RFC 3447 [RFC3477]. Interface ID The identifier assigned to the link by the LSR specified by the Router ID. - Flags - TBD + Reserved + + Zeroed on transmission and ignored on receipt. 5. Data Plane Theory of Operation 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 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 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 on the explicit path receives an RTM packet and records the time at @@ -871,93 +875,106 @@ +-----------+-------------+-------------------------+ | 0 | Reserved | This document | | 1 | PTP 2-step | This document | | 2-127 | Reserved | IETF Consensus | | 128 - 191 | Reserved | First Come First Served | | 192 - 255 | Reserved | Private Use | +-----------+-------------+-------------------------+ 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 from OSPFv2 Extended Link TLV Sub-TLVs registry as follows: +-------+----------------+---------------+ | Value | Description | Reference | +-------+----------------+---------------+ | 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 from future OSPFv3 Extended-LSA Sub-TLVs registry that would be part of OSPFv3 IANA registry as follows: +-------+----------------+---------------+ | Value | Description | Reference | +-------+----------------+---------------+ | 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 Application Identifiers for TLV 251 registry as follows: +-------+-------------+---------------+ | Value | Description | Reference | +-------+-------------+---------------+ | 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 Attributes TLV Space sub-registry as follows: +-----+------------+-----------+---------------+---------+----------+ | Typ | Name | Allowed | Allowed on | Allowed | Referenc | | e | | on LSP_A | LSP_REQUIRED_ | on LSP | e | | | | TTRIBUTES | ATTRIBUTES | Hop Att | | | | | | | ributes | | +-----+------------+-----------+---------------+---------+----------+ | TBA | RTM_SET | Yes | No | No | This | | 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 RTM_SET sub-object as follows: +-----------+----------------------+-------------------------+ | Value | Description | Reference | +-----------+----------------------+-------------------------+ | 0 | Reserved | | | 1 | IPv4 address | This document | | 2 | IPv6 address | This document | | 3 | Unnumbered interface | This document | | 4-127 | Reserved | IETF Consensus | | 128 - 191 | Reserved | First Come First Served | | 192 - 255 | Reserved | Private Use | +-----------+----------------------+-------------------------+ - Table 8: RTM_SET object sub-object types + Table 9: RTM_SET object sub-object types 9. Security Considerations Routers that support Residence Time Measurement are subject to the same security considerations as defined in [RFC5586] . In addition - particularly as applied to use related to PTP - there is a presumed trust model that depends on the existence of a trusted relationship of at least all PTP-aware nodes on the path traversed by PTP messages. This is necessary as these nodes are expected to