TICTOC Y(J). Stein
Internet-Draft RAD Data Communications
Intended status: Informational September 19, 2010
Expires: March 23, 2011
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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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
Stein Expires March 23, 2011 [Page 1]
Internet-Draft tictoc-mpls September 2010
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 BSD License.
Table of Contents
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Encapsulation Options . . . . . . . . . . . . . . . . . . . . . 3
2.1. Using IP . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Using an Ethernet PW . . . . . . . . . . . . . . . . . . . 4
2.3. Defining a New MPLS Client or a new PW Type . . . . . . . . 4
2.4. Using VCCV or the G-ACh . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Stein Expires March 23, 2011 [Page 2]
Internet-Draft tictoc-mpls September 2010
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] and the GAL G-ACh defined for MPLS-TP
[RFC5586] 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
Stein Expires March 23, 2011 [Page 3]
Internet-Draft tictoc-mpls September 2010
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 :
o Deep Packet Inspection (i.e., peeking under the MPLS stack and
identifying well-known port numbers)
o using an arbitrary configured or signaled MPLS label
o using a new reserved MPLS label
o 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
Stein Expires March 23, 2011 [Page 4]
Internet-Draft tictoc-mpls September 2010
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].
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] will be needed for use
in the PWE3 control protocol [RFC4447].
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] 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
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128,
RFC 4928, June 2007.
Stein Expires March 23, 2011 [Page 5]
Internet-Draft tictoc-mpls September 2010
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
Author's Address
Yaakov (Jonathan) Stein
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719
ISRAEL
Email: yaakov_s@rad.com
Stein Expires March 23, 2011 [Page 6]