idnits 2.17.1 draft-stein-tictoc-mpls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2010) is 4966 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TICTOC Y(J). Stein 3 Internet-Draft RAD Data Communications 4 Intended status: Informational September 19, 2010 5 Expires: March 23, 2011 7 Transport of Timing Packets over MPLS 8 draft-stein-tictoc-mpls-00.txt 10 Abstract 12 The TICTOC charter specifies that the working group is concerned with 13 highly accurate time and frequency distribution over native IP and 14 MPLS-enabled IP Packet Switched Networks (PSNs). We discuss here 15 issues specific to MPLS PSNs. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 23, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Encapsulation Options . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Using IP . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Using an Ethernet PW . . . . . . . . . . . . . . . . . . . 4 61 2.3. Defining a New MPLS Client or a new PW Type . . . . . . . . 4 62 2.4. Using VCCV or the G-ACh . . . . . . . . . . . . . . . . . . 5 63 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Motivation 69 The TICTOC charter specifies that the working group is concerned with 70 highly accurate time and frequency distribution over native IP and 71 MPLS-enabled IP Packet Switched Networks (PSNs). To date, 72 discussions have focused on NTPv4 and 1588-2008 timing distribution 73 using UDP/IP encapsulations. The present document discusses 74 transport of timing packets over MPLS PSNs, and is based on material 75 presented and discussed in previous TICTOC meetings. 77 We first must address the question as to why special treatment is 78 needed at all for transport of timing packets over MPLS. Timing 79 packets in IP format can certainly be transported over MPLS without 80 the LSRs along the path being aware of them. However, there 81 advantages to being able to recognize, and potentially manipulate, 82 timing packets. 84 For highly accurate timing distribution, timing packets are required 85 to travel through the PSN with minimal, symmetric, and 86 quasistationary delay, as well as minimal and uncorrelated packet 87 delay variation. Thus, prioritization and symmetric routing of 88 timing packets are minimal requirements. For the most demanding 89 applications, timing distribution mechanisms avail themselves of "on- 90 path support", such as Transparent Clock (TC) overwriting of header 91 fields. None of these can be selectively applied to timing packets 92 unless they can be recognized by the LSR. 94 2. Encapsulation Options 96 MPLS as a server layer presently permits three types of clients: 97 1. MPLS (via label stacking) 98 2. IP (either IPv4 or IPv6) 99 3. pseudowires (PWs) 100 although we can not rule out defining a new client for timing 101 distribution. Taking into account the two defined associated 102 channels that carry non-user traffic, namely the VCCV associated 103 channel for PWs [RFC5085] and the GAL G-ACh defined for MPLS-TP 104 [RFC5586] any proposal for carrying timing packets over MPLS will 105 need to put the timing information in one of the following six 106 formats: 107 1. a new MPLS client type 108 2. IP 109 3. an Ethernet PW 110 4. a new "timing" pseudowire type 111 5. a new VCCV channel type 112 6. a new G-ACh channel type. 113 We will discuss each of these options in turn. 115 2.1. Using IP 117 Since the two main timing distribution protocols have UDP/IP 118 encapsulations, arguably the simplest method of transporting timing 119 packets is in this format. There are several methods for 120 intermediate LSRs to recognize the timing packets : 121 o Deep Packet Inspection (i.e., peeking under the MPLS stack and 122 identifying well-known port numbers) 123 o using an arbitrary configured or signaled MPLS label 124 o using a new reserved MPLS label 125 o using a specific MPLS Traffic Class (ex-EXP). 126 It should be noted that there are very few available reserved labels, 127 and that traffic class usage is not standardized. 129 If an arbitrary label is required to be signaled, then an extension 130 to the signaling protocol will be required. Such an extension will 131 identify the FEC as belonging to a timing flow. 133 2.2. Using an Ethernet PW 135 The UDP/IP packets of the timing distribution protocols of the 136 previous subsection may be contained in Ethernet frames, that can be 137 transported over an MPLS network in an Ethernet PW. In addition, 138 IEEE 1588-2008 has a native Ethernet (non-IP) encapsulation. 140 Methods for identifying timing packets inside an Ethernet PW are 141 similar to those of the previous subsection. 143 2.3. Defining a New MPLS Client or a new PW Type 145 IEEE 1588-2008 allows for different transport layers to be defined, 146 with annexes to the standard defining UDP/IPv4, UDP/IPv6, Ethernet, 147 and several other transport networks. It is possible to define a new 148 transport mechanism for MPLS, which entails specifying how to 149 encapsulate a PTP PDU in an MPLS packet. This can be done in the 150 context of the PWE3 architecture (this was proposed in 151 draft-ronc-ptp-mpls-00.txt, now expired) or without reference to that 152 architecture. If the PWE3 architecture is used, then PWE3 features, 153 such as the control word and the control protocol, may be used. 155 Whether the MPLS encapsulation is a PW or not, the timing packet will 156 be recognized by virtue of its bottom-of-stack label. When 157 additional labels are present, the LSR will need to search for the 158 label with S=1. This technique is technically a violation of the 159 MPLS architecture, but is presently performed for other purposes, 160 e.g., ECMP avoidance [RFC4928]. 162 The particular label(s) used to signify timing packets may be 163 distributed by manual configuration or a signaling protocol. If the 164 latter is employed, a new FEC type will need to be defined. If a PW 165 is used, a new MPLS Pseudowire Type [RFC4446] will be needed for use 166 in the PWE3 control protocol [RFC4447]. 168 2.4. Using VCCV or the G-ACh 170 Timing is often distributed in order to enable proper functioning of 171 applications that already define PWs between the end points of the 172 timing flow. In this case, the timing information may be placed in 173 the VCCV associated channel of the application's PW. The associated 174 channel is typically identified by having the same PW (bottom-of- 175 stack) label as the application, but a control word with 0001 in its 176 initial nibble. The timing packets may then be identified by a new 177 channel type, or may use the IP channel type and then would be 178 identified by the well-known port numbers. It is recognized that 179 this requires the LSR to perform relatively deep packet inspection. 181 If there is no application PW between the timing end points, then we 182 may still use the Generic Associated CHannel (G-ACh) defined in 183 [RFC5586] in a similar manner. The G-ACh is identified by the G-ACh 184 Label (GAL), which is a reserved MPLS label of value 13, at its 185 bottom-of-stack. The format after the GAL is the same as that of 186 VCCV, and thus the considerations of the previous paragraph apply. 188 3. IANA Considerations 190 This document requires no IANA actions. 192 4. References 194 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 195 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 197 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 198 Heron, "Pseudowire Setup and Maintenance Using the Label 199 Distribution Protocol (LDP)", RFC 4447, April 2006. 201 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 202 Cost Multipath Treatment in MPLS Networks", BCP 128, 203 RFC 4928, June 2007. 205 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 206 Connectivity Verification (VCCV): A Control Channel for 207 Pseudowires", RFC 5085, December 2007. 209 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 210 Associated Channel", RFC 5586, June 2009. 212 Author's Address 214 Yaakov (Jonathan) Stein 215 RAD Data Communications 216 24 Raoul Wallenberg St., Bldg C 217 Tel Aviv 69719 218 ISRAEL 220 Email: yaakov_s@rad.com