Transport of Timing Packets over MPLS
draft-stein-tictoc-mpls-00.txt

Abstract

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.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 March 23, 2011.

Copyright Notice

Copyright (c) 2010 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Motivation
2.  Encapsulation Options
    2.1.  Using IP
    2.2.  Using an Ethernet PW
    2.3.  Defining a New MPLS Client or a new PW Type
    2.4.  Using VCCV or the G-ACh
3.  IANA Considerations
4.  References
§  Author's Address

1.  Motivation

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.

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.

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.

2.  Encapsulation Options

MPLS as a server layer presently permits three types of clients:

1.

MPLS (via label stacking)

2.

IP (either IPv4 or IPv6)

3.

pseudowires (PWs)

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 [RFC5085] (Nadeau, T. and C. Pignataro, “Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires,” December 2007.) and the GAL G-ACh defined for MPLS-TP [RFC5586] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.) any proposal for carrying timing packets over MPLS will need to put the timing information in one of the following six formats:

1.

a new MPLS client type

2.

IP

3.

an Ethernet PW

4.

a new "timing" pseudowire type

5.

a new VCCV channel type

6.

a new G-ACh channel type.

We will discuss each of these options in turn.

2.1.  Using IP

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 :

• Deep Packet Inspection (i.e., peeking under the MPLS stack and identifying well-known port numbers)
• using an arbitrary configured or signaled MPLS label
• using a new reserved MPLS label
• using a specific MPLS Traffic Class (ex-EXP).

It should be noted that there are very few available reserved labels, and that traffic class usage is not standardized.

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.

2.2.  Using an Ethernet PW

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.

Methods for identifying timing packets inside an Ethernet PW are similar to those of the previous subsection.

2.3.  Defining a New MPLS Client or a new PW Type

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.

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 [RFC4928] (Swallow, G., Bryant, S., and L. Andersson, “Avoiding Equal Cost Multipath Treatment in MPLS Networks,” June 2007.).

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 [RFC4446] (Martini, L., “IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3),” April 2006.) will be needed for use in the PWE3 control protocol [RFC4447] (Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, “Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP),” April 2006.).

2.4.  Using VCCV or the G-ACh

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.

If there is no application PW between the timing end points, then we may still use the Generic Associated CHannel (G-ACh) defined in [RFC5586] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.) 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.

3.  IANA Considerations

This document requires no IANA actions.

4. References

Author's Address