<?xml version="1.0"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc toc="yes"?>
<rfc category='info' ipr='trust200902' docName='draft-stein-tictoc-mpls-00.txt'>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4446 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4446.xml'>
<!ENTITY RFC4447 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4447.xml'>
<!ENTITY RFC4928 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4928.xml'>
<!ENTITY RFC5085 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5085.xml'>
<!ENTITY RFC5586 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5586.xml'>
]>

<front>
<title abbrev="tictoc-mpls">Transport of Timing Packets over MPLS</title>

<author initials="Y(J)" surname="Stein" fullname="Yaakov (Jonathan) Stein">
<organization>RAD Data Communications</organization>
<address>
     <postal>
         <street>24 Raoul Wallenberg St., Bldg C</street>
         <city>Tel Aviv</city>
         <code>69719</code>
         <country>ISRAEL</country>
     </postal>
     <email>yaakov_s@rad.com</email>
</address>
</author>

<date day="19" month="September" year="2010" />

<area>Internet</area>
<workgroup>TICTOC</workgroup>
<keyword>timing</keyword>
<keyword>MPLS</keyword>


<abstract>
 <t> The TICTOC charter specifies that the working group is concerned with 
     highly accurate time and frequency distribution over native IP and 
     MPLS-enabled IP Packet Switched Networks (PSNs). 
     We discuss here issues specific to MPLS PSNs.  
 </t>
</abstract>

</front>

<middle>

<section title="Motivation">
 <t> The TICTOC charter specifies that the working group is concerned with 
     highly accurate time and frequency distribution over native IP and 
	 MPLS-enabled IP Packet Switched Networks (PSNs). 
	 To date, discussions have focused on NTPv4 and 1588-2008 timing distribution
	 using UDP/IP encapsulations. 
	 The present document discusses transport of timing packets over MPLS PSNs,
	 and is based on material presented and discussed in previous TICTOC meetings. 
 </t> 

 <t> We first must address the question as to why special treatment is needed at all
     for transport of timing packets over MPLS.
     Timing packets in IP format can certainly be transported over MPLS
	 without the LSRs along the path being aware of them.
	 However, there advantages to being able to recognize, and potentially manipulate, 
	 timing packets.     
 </t> 
 
 <t> For highly accurate timing distribution, timing packets are required
     to travel through the PSN with minimal, symmetric, and quasistationary delay,
	 as well as minimal and uncorrelated packet delay variation.
	 Thus, prioritization and symmetric routing of timing packets are minimal requirements.
	 For the most demanding applications, timing distribution mechanisms avail themselves
	 of "on-path support", such as Transparent Clock (TC) overwriting of header fields.
	 None of these can be selectively applied to timing packets unless they can be
	 recognized by the LSR.
 </t>
 
</section>

<section title="Encapsulation Options">
 <t> MPLS as a server layer presently permits three types of clients:
  <list style="hanging">
   <t hangText="1."> MPLS (via label stacking) </t>
   <t hangText="2."> IP (either IPv4 or IPv6) </t> 
   <t hangText="3."> pseudowires (PWs) </t>  
  </list> 
  although we can not rule out defining a new client for timing distribution.
  Taking into account the two defined associated channels that carry non-user traffic, 
  namely the VCCV associated channel for PWs <xref target="RFC5085" />
  and the GAL G-ACh defined for MPLS-TP <xref target="RFC5586" />
  any proposal for carrying timing packets over MPLS will need to
  put the timing information in one of the following six formats: 
  <list style="hanging">
   <t hangText="1."> a new MPLS client type </t>
   <t hangText="2."> IP </t> 
   <t hangText="3."> an Ethernet PW </t> 
   <t hangText="4."> a new "timing" pseudowire type </t>  
   <t hangText="5."> a new VCCV channel type </t>  
   <t hangText="6."> a new G-ACh channel type. </t>  
   </list> 
   We will discuss each of these options in turn.   
  </t>

 <section title="Using IP">  
  <t> Since the two main timing distribution protocols have UDP/IP encapsulations, 
      arguably the simplest method of transporting timing packets is in this format.
	  There are several methods for intermediate LSRs to recognize the timing packets :
	  <list style="symbols">
	   <t> Deep Packet Inspection (i.e., peeking under the MPLS stack and identifying well-known port numbers) </t>
       <t> using an arbitrary configured or signaled MPLS label </t>
	   <t> using a new reserved MPLS label </t>
	   <t> using a specific MPLS Traffic Class (ex-EXP).  </t>
	  </list>
	  It should be noted that there are very few available reserved labels,
	  and that traffic class usage is not standardized.
  </t>
  <t> If an arbitrary label is required to be signaled, 
      then an extension to the signaling protocol will be required.
	  Such an extension will identify the FEC as belonging to a timing flow.
  </t>
      
 </section>

 <section title="Using an Ethernet PW">  
  <t>
   The UDP/IP packets of the timing distribution protocols of the previous subsection
   may be contained in Ethernet frames, that can be transported over an MPLS network
   in an Ethernet PW. In addition, IEEE 1588-2008 has a native Ethernet (non-IP) encapsulation.   
  </t>
  <t>
   Methods for identifying timing packets inside an Ethernet PW are similar to those
   of the previous subsection.
  </t>
 </section>

 <section title="Defining a New MPLS Client or a new PW Type">  
  <t> IEEE 1588-2008 allows for different transport layers to be defined,
      with annexes to the standard defining UDP/IPv4, UDP/IPv6, Ethernet, 
      and several other transport networks.
      It is possible to define a new transport mechanism for MPLS,
      which entails specifying how to encapsulate a PTP PDU in an MPLS packet.
      This can be done in the context of the PWE3 architecture
      (this was proposed in draft-ronc-ptp-mpls-00.txt, now expired)
      or without reference to that architecture.
	  If the PWE3 architecture is used, then PWE3 features, 
	  such as the control word and the control protocol, may be used.
  </t>
  
  <t> Whether the MPLS encapsulation is a PW or not, 
      the timing packet will be recognized by virtue of its bottom-of-stack label.
	  When additional labels are present, the LSR will need to search for the label
	  with S=1. This technique is technically a violation of the MPLS architecture,
      but is presently performed for other purposes, e.g., ECMP avoidance <xref target="RFC4928" />. 
  </t>
  
  <t> The particular label(s) used to signify timing packets may be distributed by manual configuration
      or a signaling protocol. If the latter is employed, a new FEC type will need to be defined. 
	  If a PW is used, a new  MPLS Pseudowire Type <xref target="RFC4446" />
	  will be needed for use in the PWE3 control protocol <xref target="RFC4447" />.
  </t>	  
  
 </section>

 <section title="Using VCCV or the G-ACh">  
  <t> Timing is often distributed in order to enable proper functioning of applications 
      that already define PWs between the end points of the timing flow.
      In this case, the timing information may be placed in the VCCV associated channel
      of the application's PW.
      The associated channel is typically identified by having the same PW (bottom-of-stack) label
      as the application, but a control	word with 0001 in its initial nibble.
	  The timing packets may then be identified by a new channel type,
	  or may use the IP channel type and then would be identified by the well-known port numbers.
	  It is recognized that this requires the LSR to perform relatively deep packet inspection.
  </t>
  
  <t> If there is no application PW between the timing end points,
      then we may still use the Generic Associated CHannel (G-ACh) defined in <xref target="RFC5586" />
	  in a similar manner. The G-ACh is identified by the G-ACh Label (GAL),
	  which is a reserved MPLS label of value 13, at its bottom-of-stack.
	  The format after the GAL is the same as that of VCCV,
	  and thus the considerations of the previous paragraph apply.
  </t>
 </section>

</section>

<section title="IANA Considerations">
 <t> This document requires no IANA actions.</t>
</section>

</middle>


<back>

<references title='References'>
    &RFC4446; 
    &RFC4447; 
    &RFC4928; 
    &RFC5085; 
    &RFC5586; 
</references>  
 
</back>

</rfc>
