--- 1/draft-ietf-mpls-residence-time-13.txt 2017-02-22 07:13:27.324735933 -0800 +++ 2/draft-ietf-mpls-residence-time-14.txt 2017-02-22 07:13:27.384737351 -0800 @@ -1,26 +1,26 @@ MPLS Working Group G. Mirsky Internet-Draft ZTE Corp. Intended status: Standards Track S. Ruffini -Expires: August 3, 2017 E. Gray +Expires: August 26, 2017 E. Gray Ericsson J. Drake Juniper Networks S. Bryant Huawei A. Vainshtein ECI Telecom - January 30, 2017 + February 22, 2017 Residence Time Measurement in MPLS network - draft-ietf-mpls-residence-time-13 + draft-ietf-mpls-residence-time-14 Abstract This document specifies a new Generic Associated Channel for Residence Time Measurement and describes how it can be used by time synchronization protocols within a MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be @@ -35,21 +35,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 3, 2017. + This Internet-Draft will expire on August 26, 2017. Copyright Notice Copyright (c) 2017 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 @@ -75,35 +75,35 @@ 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 10 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 11 4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 11 4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 12 4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 12 4.6. RTM Capability Advertisement in BGP-LS . . . . . . . . . 13 4.7. RSVP-TE Control Plane Operation to Support RTM . . . . . 13 4.8. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 15 4.8.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 16 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 19 - 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 19 + 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 20 7.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 20 7.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 21 7.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 21 - 7.5. IS-IS RTM Capability sub-TLV for TLV 22 . . . . . . . . . 21 + 7.5. IS-IS RTM Capability sub-TLV . . . . . . . . . . . . . . 22 7.6. RTM Capability TLV in BGP-LS . . . . . . . . . . . . . . 22 7.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 22 7.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 23 - 7.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 23 + 7.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction Time synchronization protocols, e.g., Network Time Protocol version 4 (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 [IEEE.1588.2008], define timing messages that can be used to synchronize clocks across a network domain. Measurement of the cumulative time that one of these timing messages spends transiting @@ -113,21 +113,21 @@ the time of receipt at an ingress interface and the time of transmission from an egress interface for each node along the network path from an ingress node to an egress node.) This document defines a new Generic Associated Channel (G-ACh) value and an associated residence time measurement (RTM) message that can be used in a Multi- Protocol Label Switching (MPLS) network to measure residence time over a Label Switched Path (LSP). This document describes RTM over an LSP signaled using RSVP-TE [RFC3209]. Using RSVP-TE, the LSP's path can be either explicitly - specified or determined during signaling. Althugh it is possible to + specified or determined during signaling. Although it is possible to use RTM over an LSP instantiated using LDP, that is outside the scope of this document. Comparison with alternative proposed solutions such as [I-D.ietf-tictoc-1588overmpls] is outside the scope of this document. 1.1. Conventions used in this document 1.1.1. Terminology @@ -505,92 +505,103 @@ 4.3. RTM Capability Advertisement in OSPFv2 The format for the RTM Capability sub-TLV in OSPF is presented in Figure 4 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RTM | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RTM | ... + +-+-+-+-+-+-+-+-+-+- ... Figure 4: RTM Capability sub-TLV in OSPFv2 o Type value (TBA2) will be assigned by IANA from appropriate registry for OSPFv2 Section 7.4. - o Length MUST be set to 4. + o Length value equals number of octets of the Value field. + + o Value contains variable number of bit-map fields so that overall + number of bits in the fields equals Length * 8. + + o Bits are defined/sent starting with Bit 0. Additional bit-map + field definitions that may be defined in the future SHOULD be + assigned in ascending bit order so as to minimize the number of + bits that will need to be transmitted. + + o Undefined bits MUST be transmitted as 0 and MUST be ignored on + receipt. + + o Bits that are NOT transmitted MUST be treated as if they are set + to 0 on receipt. o RTM (capability) - is a three-bit long bit-map field with values defined as follows: * 0b001 - one-step RTM supported; * 0b010 - two-step RTM supported; * 0b100 - reserved. - o Reserved field must be set to all zeroes on transmit and ignored - on receipt. - The capability to support RTM on a particular link (interface) is advertised in the OSPFv2 Extended Link Opaque LSA described in Section 3 [RFC7684] via the RTM Capability sub-TLV. Its Type value will be assigned by IANA from the OSPF Extended Link TLV Sub-TLVs registry Section 7.4, that will be created per [RFC7684] request. 4.4. RTM Capability Advertisement in OSPFv3 The capability to support RTM on a particular link (interface) can be advertised in OSPFv3 using LSA extensions as described in [I-D.ietf-ospf-ospfv3-lsa-extend]. Exact use of OSPFv3 LSA extensions is for further study. 4.5. RTM Capability Advertisement in IS-IS - The format for the RTM Capabilities sub-TLV is presented in Figure 5 + The capability to support RTM on a particular link (interface) is + advertised in a new sub-TLV which may be included in TLVs advertising + Intermediate System (IS) Reachability on a specific link (TLVs 22, + 23, 222, and 223). - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | RTM | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + The format for the RTM Capabilities sub-TLV is presented in Figure 5 + 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 ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... + | Type | Length | RTM | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... - Figure 5: RTM Capability sub-TLV for the Extended IS Reachability TLV + Figure 5: RTM Capability sub-TLV o Type value (TBA3) will be assigned by IANA from the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry for IS-IS Section 7.5. - o Length MUST be set to 2. - - o RTM (capability) - as defined in Section 4.3. - - o Reserved field must be set to all zeroes on transmit and ignored - on receipt. + o Definitions, rules of handling, and values for fields Length and + Value are as defined in Section 4.3 - The capability to support RTM on a particular link (interface) is - advertised in the Extended IS Reachability TLV described in [RFC5305] - via the RTM Capability sub-TLV. + o RTM (capability) - is a three-bit long bit-map field with values + defined in Section 4.3. 4.6. RTM Capability Advertisement in BGP-LS The format for the RTM Capabilities TLV is as presented in Figure 4. Type value TBA9 will be assigned by IANA from the BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs sub-registry Section 7.6. - Length, RTM, and Reserved fields as defined in Section 4.3. + Definitions, rules of handling, and values for fields Length, Value, + and RTM are as defined in Section 4.3. The RTM Capability will be advertised in BGP-LS as a Link Attribute TLV associated with the Link NLRI as described in section 3.3.2 of [RFC7752]. 4.7. RSVP-TE Control Plane Operation to Support RTM Throughout this document we refer to a node as RTM capable node when at least one of its interfaces is RTM capable. Figure 6 provides an example of roles a node may have with respect to RTM capability: @@ -859,23 +870,25 @@ 5. Data Plane Theory of Operation After instantiating an LSP for a path using RSVP-TE [RFC3209] as described in Section 4.7, the ingress node MAY begin sending RTM packets to the first downstream RTM capable node on that path. Each RTM packet has its Scratch Pad field initialized and its TTL set to expire on the next downstream RTM-capable node. Each RTM-capable node on the explicit path receives an RTM packet and records the time at which it receives that packet at its ingress interface as well as - the time at which it transmits that packet from its egress interface; - this should be done as close to the physical layer as possible to - ensure precise accuracy in time determination. The RTM-capable node + the time at which it transmits that packet from its egress interface. + These actions should be done as close to the physical layer as + possible at the same point of packet processing striving to avoid + introducing the appearance of jitter in propagation delay whereas it + should be accounted as residence time. The RTM-capable node determines the difference between those two times; for one-step operation, this difference is determined just prior to or while sending the packet, and the RTM-capable egress interface adds it to the value in the Scratch Pad field of the message in progress. Note, for the purpose of calculating a residence time, a common free running clock synchronizing all the involved interfaces may be sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond error for residence time on the order of 1 millisecond. This may be acceptable for applications where the target accuracy is in the order of hundreds of ns. As an example several applications being @@ -978,33 +991,33 @@ from OSPFv2 Extended Link TLV Sub-TLVs registry as follows: +-------+----------------+---------------+ | Value | Description | Reference | +-------+----------------+---------------+ | TBA2 | RTM Capability | This document | +-------+----------------+---------------+ Table 4: RTM Capability sub-TLV -7.5. IS-IS RTM Capability sub-TLV for TLV 22 +7.5. IS-IS RTM Capability sub-TLV IANA is requested to assign a new Type for RTM capability sub-TLV from the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry as follows: - +------+-------------+----+----+-----+-----+-----+---------------+ + +------+----------------+----+----+-----+-----+-----+---------------+ | Type | Description | 22 | 23 | 141 | 222 | 223 | Reference | - +------+-------------+----+----+-----+-----+-----+---------------+ - | TBA3 | RTM | y | n | n | n | n | This document | - +------+-------------+----+----+-----+-----+-----+---------------+ + +------+----------------+----+----+-----+-----+-----+---------------+ + | TBA3 | RTM Capability | y | y | n | y | y | This document | + +------+----------------+----+----+-----+-----+-----+---------------+ - Table 5: IS-IS RTM Capability sub-TLV for TLV 22 + Table 5: IS-IS RTM Capability sub-TLV Registry Description 7.6. RTM Capability TLV in BGP-LS IANA is requested to assign a new code point for RTM Capability TLV from BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs sub-registry in its Border Gateway Protocol - Link State (BGP-LS) Parameters registry as follows: +---------------+----------------+------------------+---------------+ | TLV Code | Description | IS-IS TLV/Sub- | Reference | @@ -1113,23 +1125,23 @@ modify the G-ACh content, this is an issue that exists for nodes in general - for any and all data that may be carried over an LSP - and is therefore the basis for an additional presumed trust model associated with existing LSPs and nodes. Security requirements of time protocols are provided in RFC 7384 [RFC7384]. 9. Acknowledgments - Authors want to thank Loa Andersson, Lou Berger and Acee Lindem for - their thorough reviews, thoughtful comments and, most of all, - patience. + Authors want to thank Loa Andersson, Lou Berger, Acee Lindem, Les + Ginsberg, and Uma Chunduri for their thorough reviews, thoughtful + comments and, most of all, patience. 10. References 10.1. Normative References [IEEE.1588.2008] "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588, July 2008. @@ -1151,24 +1163,20 @@ [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, . [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, . - [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic - Engineering", RFC 5305, DOI 10.17487/RFC5305, October - 2008, . - [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, . [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, .