draft-ietf-tictoc-1588overmpls-05.txt   draft-ietf-tictoc-1588overmpls-06.txt 
TICTOC Working Group S. Davari TICTOC Working Group S. Davari
Internet-Draft A. Oren Internet-Draft A. Oren
Intended status: Standards Track Broadcom Corp. Intended status: Experimental Broadcom Corp.
Expires: December 17, 2013 M. Bhatia Expires: October 30, 2014 M. Bhatia
P. Roberts P. Roberts
Alcatel-Lucent Alcatel-Lucent
L. Montini L. Montini
L. Martini
Cisco Systems Cisco Systems
June 15, 2013 April 28, 2014
Transporting Timing messages over MPLS Networks Transporting Timing messages over MPLS Networks
draft-ietf-tictoc-1588overmpls-05 draft-ietf-tictoc-1588overmpls-06
Abstract Abstract
This document defines the method for transporting Timing messages This document defines the method for transporting Timing messages
such as PTP and NTP over an MPLS network. The method allows for the such as PTP and NTP over an MPLS network. The method allows for the
easy identification of these PDUs at the port level to allow for port easy identification of these PDUs at the port level to allow for port
level processing of these PDUs in both LERs and LSRs. level processing of these PDUs in both LERs and LSRs.
The basic idea is to transport Timing messages inside dedicated MPLS The basic idea is to transport Timing messages inside dedicated MPLS
LSPs. These LSPs only carry Timing messages and possibly Control and LSPs. These LSPs only carry Timing messages and possibly Control and
skipping to change at page 1, line 49 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 17, 2013. This Internet-Draft will expire on October 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 9 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 10
5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 12 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 13
6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 13 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 14
6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 13 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 14
6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 13 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 14
6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 14 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 15
7. Timing message Processing . . . . . . . . . . . . . . . . . . 15 7. Timing message Processing . . . . . . . . . . . . . . . . . . 16
8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 17
9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12. OAM, Control and Management . . . . . . . . . . . . . . . . . 20 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 21
13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 22
14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 22 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 23
15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 23
15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 23
15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 23
15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24
16. Other considerations . . . . . . . . . . . . . . . . . . . . . 25 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 24
15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 24
15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 24
15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24
17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 16. Other considerations . . . . . . . . . . . . . . . . . . . . . 26
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 17. Security Considerations . . . . . . . . . . . . . . . . . . . 27
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 18. Applicability Statement . . . . . . . . . . . . . . . . . . . 28
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
20.1. Normative References . . . . . . . . . . . . . . . . . . . 29
20.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix 1. Routing extensions for Timing-aware Routers . . . . . 32 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
21.1. Normative References . . . . . . . . . . . . . . . . . . . 31
21.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . 33 Appendix 1. Appendix . . . . . . . . . . . . . . . . . . . . . . 34
1.1. Routing extensions for Timing-aware Routers . . . . . . . 34
1.2. Signaling Extensions for Creating Timing LSPs . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
When used in lower case, these words convey their typical use in When used in lower case, these words convey their typical use in
common language, and are not to be interpreted as described in common language, and are not to be interpreted as described in
RFC2119 [RFC2119]. RFC2119 [RFC2119].
1. Introduction 1. Introduction
skipping to change at page 5, line 39 skipping to change at page 6, line 39
targets optimal time and/or frequency recovery by avoiding variable targets optimal time and/or frequency recovery by avoiding variable
delay introduced by queues internal to the clocks. delay introduced by queues internal to the clocks.
To facilitate the fast and efficient recognition of Timing messages To facilitate the fast and efficient recognition of Timing messages
at the port level when the Timing messages are carried over MPLS at the port level when the Timing messages are carried over MPLS
LSPs, this document defines the specific encapsulations that should LSPs, this document defines the specific encapsulations that should
be used. In addition, it can be expected that there will exist LSR/ be used. In addition, it can be expected that there will exist LSR/
LERs where only a subset of the physical ports will have the port- LERs where only a subset of the physical ports will have the port-
based Timing message processing capabilities. In order to ensure based Timing message processing capabilities. In order to ensure
that the LSPs carrying Timing packets always enter and exit ports that the LSPs carrying Timing packets always enter and exit ports
with this capability, routing extensions are defined to advertise with this capability, routing extensions can be defined to advertise
this capability on a port basis and to allow for the establishment of this capability on a port basis and to allow for the establishment of
LSPs that only transit such ports. While this path establishment LSPs that only transit such ports. While this path establishment
restriction may be applied only at the LER Ingress and/or egress restriction may be applied only at the LER Ingress and/or egress
ports, it becomes more important when using transparent clock capable ports, it becomes more important when using transparent clock capable
LSRs in the path. LSRs in the path.
Port based Timing message processing involves Timing message Port based Timing message processing involves Timing message
recognition. Once the Timing messages are recognized they can be recognition. Once the Timing messages are recognized they can be
modified based on the reception or transmission Time-stamp. modified based on the reception or transmission Time-stamp.
This document provides two methods for transporting Timing messages This document provides two methods for transporting Timing messages
over MPLS. One is applicable to MPLS environment and the other one over MPLS. One is applicable to MPLS environment and the other one
is applicable to MPLS/MPLS-TP environment is applicable to MPLS/MPLS-TP environment.
The solution involves transporting Timing messages over dedicated The solution involves transporting Timing messages over dedicated
LSPs called Timing LSPs. These LSPs carry Timing messages and MAY LSPs called Timing LSPs. These LSPs carry Timing messages and MAY
carry Management and control messages, but not data plane client carry Management and control messages, but not data plane client
traffic. Timing LSPs can be established statically or via signaling. traffic. Timing LSPs can be established statically or via signaling.
Extensions to control plane (OSPF, ISIS, etc.) is required to enable Extensions to control plane (OSPF, ISIS, etc.) is required to enable
routers to distribute their Timing processing capabilities over MPLS routers to distribute their Timing processing capabilities over MPLS
to other routers. However such extensions are outside the scope of to other routers. However such extensions are outside the scope of
this document. this document.
When signaling is used to setup the PTP LSP, Extensions to signaling When signaling is used to setup the PTP LSP, extensions to signaling
protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. protocols (e.g., RSVP-TE) are required for establishing PTP LSPs.
However such extensions are outside the scope of this document. However such extensions are outside the scope of this document.
While the techniques included herein allow for the establishment of While the techniques included herein allow for the establishment of
paths optimized to include Time-stamping capable links, the paths optimized to include Time-stamping capable links, the
performance of the Slave clocks is outside the scope of this performance of the Slave clocks is outside the scope of this
document. document.
At the time of publishing this specification, Transparent Clocking At the time of publishing this specification, Transparent Clocking
(TC) is only defined for PTP. Therefore at this time any part of (TC) is only defined for PTP. Therefore at this time any part of
skipping to change at page 8, line 24 skipping to change at page 9, line 24
There are multiple ways of transporting Timing over MPLS. However, There are multiple ways of transporting Timing over MPLS. However,
there is a requirement to limit the possible encapsulation options to there is a requirement to limit the possible encapsulation options to
simplify the Timing message identification and processing required at simplify the Timing message identification and processing required at
the port level. the port level.
When Timing-awareness is needed, Timing messages should not be When Timing-awareness is needed, Timing messages should not be
transported over LSPs or PWs that are carrying customer traffic transported over LSPs or PWs that are carrying customer traffic
because LSRs perform Label switching based on the top label in the because LSRs perform Label switching based on the top label in the
stack. To detect Timing messages inside such LSPs require special stack. To detect Timing messages inside such LSPs require special
hardware to do deep packet inspection at line rate. Even if such hardware to do deep packet inspection at line rate. Even if such
hardware exists, the payload can't be deterministically identified by hardware exists, the payload cant be deterministically identified by
LSRs because the payload type is a context of the PW label, and the LSRs because the payload type is a context of the PW label, and the
PW label and its context are only known to the Edge routers (PEs/ PW label and its context are only known to the Edge routers (PEs/
LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES, LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES,
etc). Even if one restricts an LSP to only carry Ethernet PWs, the etc). Even if one restricts an LSP to only carry Ethernet PWs, the
LSRs dont have the knowledge of whether PW Control Word (CW) is LSRs dont have the knowledge of whether PW Control Word (CW) is
present or not and therefore can not deterministically identify the present or not and therefore can not deterministically identify the
payload. payload.
A generic method is defined in this document that does not require A generic method is defined in this document that does not require
deep packet inspection at line rate, and can deterministically deep packet inspection at line rate, and can deterministically
skipping to change at page 9, line 39 skipping to change at page 10, line 38
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
/ \ / \
+-------+ / \ +-------+ +-------+ / \ +-------+
| LER | / \ | LER | | LER | / \ | LER |
| Master|---/ \---| Slave | | Master|---/ \---| Slave |
| Clock | | Clock | | Clock | | Clock |
+-------+ +-------+ +-------+ +-------+
Figure (1) - Deployment example 1 of timing over MPLS network Figure (1) - Deployment example 1 of timing over MPLS network
Another example is shown in Figure2, where LERs terminate the Timing Another example is shown in Figure 2, where LERs terminate the Timing
messages received from switch/routers that are outside of the MPLS messages received from switch/routers that are outside of the MPLS
network acting as OC or BC. In this example LERs regenerate the network acting as OC or BC. In this example LERs regenerate the
clock and initiate timing messages encapsulated in Timing LSP toward clock and initiate timing messages encapsulated in Timing LSP toward
the MPLS network, while the LSRs act as Transparent Clock (TC) and the MPLS network, while the LSRs act as Transparent Clock (TC) and
just update the Timing field in the Timing messages, which are just update the Timing field in the Timing messages, which are
already encapsulated in Timing LSPs. already encapsulated in Timing LSPs.
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, | |Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router | | Router |-----| LER |-----| LSR |-----| LER |-----| Router |
skipping to change at page 10, line 35 skipping to change at page 11, line 28
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
Figure (3) - Deployment example 3 of timing over MPLS network Figure (3) - Deployment example 3 of timing over MPLS network
Another example is shown in Figure 4, where LERs and LSRs support Another example is shown in Figure 4, where LERs and LSRs support
Boundary Clocks. A single-hop LSP is created between two adjacent Boundary Clocks. A single-hop LSP is created between two adjacent
LSRs engaged in BC operation. Other methods such as PTP transport LSRs engaged in BC operation. Other methods such as PTP transport
over Ethernet MAY be used for transporting timing messages if the over Ethernet MAY be used for transporting timing messages if the
link between the two routers is Ethernet. link between the two routers is Ethernet.
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, | |Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router | | Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| OC/BC | | BC | | BC | | BC | | OC/BC | | OC/BC | | BC | | BC | | BC | | OC/BC |
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
Figure (4) - Deployment example 3 of timing over MPLS network Figure (4) - Deployment example 3 of timing over MPLS network
An MPLS domain MAY serve multiple customers. In these cases the MPLS An MPLS domain MAY serve multiple customers. In these cases the MPLS
domain (maintained by a service provider) may provide timing services domain (maintained by a service provider) may provide timing services
to multiple customers, each having their own Timing domain. to multiple customers, each having their own Timing domain.
skipping to change at page 12, line 29 skipping to change at page 13, line 29
Compliant implementations MUST use dedicated LSPs to carry Timing Compliant implementations MUST use dedicated LSPs to carry Timing
messages over MPLS. These LSPs are herein referred to as "Timing messages over MPLS. These LSPs are herein referred to as "Timing
LSPs" and the labels associated with these LSPs as "Timing LSP LSPs" and the labels associated with these LSPs as "Timing LSP
labels". The Timing LSPs that runs between Ingress and Egress LERs labels". The Timing LSPs that runs between Ingress and Egress LERs
MUST be co-routed. Alternatively, a single bidirectional co-routed MUST be co-routed. Alternatively, a single bidirectional co-routed
LSP can be used. LSP can be used.
Co-routing of the two directions is required to limit the difference Co-routing of the two directions is required to limit the difference
in the delays in the Master clock to Slave clock direction compared in the delays in the Master clock to Slave clock direction compared
to the Slave clock to Master clock direction. The Timing LSP MAY be to the Slave clock to Master clock direction. The Timing LSP MAY be
MPLS/MPLS-TP LSP. MPLS LSP/MPLS-TP LSP.
The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS.
New Extensions to RSVP-TE/GMPLS TLVs are required; however they are New Extensions to RSVP-TE/GMPLS TLVs are required; however they are
outside the scope of this document. outside the scope of this document.
The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as
BFD and LSP Ping but the LSP data plane client plane traffic MUST be BFD and LSP Ping but the LSP data plane client plane traffic MUST be
Timing packets only. Timing packets only.
6. Timing over LSP Encapsulation 6. Timing over LSP Encapsulation
This document defines two methods for carrying Timing messages over This standard defines two methods for carrying Timing messages over
MPLS. The first method is carrying UDP/IP encapsulated Timing MPLS. The first method is carrying UDP/IP encapsulated Timing
messages over Timing LSPs, and the second method, is carrying messages over Timing LSPs, and the second method, is carrying
Ethernet encapsulated Timing messages over Ethernet PWs inside Timing Ethernet encapsulated Timing messages over Ethernet PWs inside Timing
LSPs. LSPs.
6.1. Timing over UDP/IP over MPLS Encapsulation 6.1. Timing over UDP/IP over MPLS Encapsulation
The simplest method of transporting Timing messages over MPLS is to The simplest method of transporting Timing messages over MPLS is to
encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing
LSP. This format is shown in Figure 4. LSP. This format is shown in Figure 4.
skipping to change at page 14, line 5 skipping to change at page 15, line 5
[RFC5905]. [RFC5905].
6.2. Timing over PW Encapsulation 6.2. Timing over PW Encapsulation
Another method of transporting Timing over MPLS networks is by Another method of transporting Timing over MPLS networks is by
encapsulating Timing PDUs in PW which in turn is transported over encapsulating Timing PDUs in PW which in turn is transported over
Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448],
shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP
MUST follow Annex F of [IEEE-1588]. MUST follow Annex F of [IEEE-1588].
The RAW mode or Tagged mode defined in [RFC4448] MAY be used and the The RAW mode or Tagged mode defined in [RFC-4448] MAY be used and the
Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The
Timing over PW encapsulation MUST use the Control Word (CW) as Timing over PW encapsulation MUST use the Control Word (CW) as
specified in [RFC4448] to ensure proper detection of PTP messages specified in [RFC4448] to ensure proper detection of PTP messages
inside the MPLS packets for Timing over LSP and Timing over PW inside the MPLS packets for Timing over LSP and Timing over PW
encapsulation. The use of Sequence Number in the CW is optional. encapsulation. The use of Sequence Number in the CW is optional.
Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW
(the IP PW discussed in [RFC4447]) shown in Fig 5(B). (the IP PW discussed in [RFC4447]) shown in Fig 5(B).
+----------------+ +----------------+ +-----------------+ +----------------+
|Timing LSP Label| |Timing LSP Label| |Timing LSP Label | |Timing LSP Label|
+----------------+ +----------------+ +-----------------+ +----------------+
| PW Label | | PW Label | | PW Label | | PW Label |
+----------------+ +----------------+ +-----------------+ +----------------+
| Control Word | | IP | | Control Word | | IP |
+----------------+ +----------------+ +-----------------+ +----------------+
| Ethernet | | UDP | | Ethernet | | UDP |
| Header | +----------------+ | Header | +----------------+
+----------------+ | Timing PDU | +-----------------+ | Timing PDU |
|S-VLAN(Optional)| | | |S-VLAN (Optional)| | |
+----------------+ +----------------+ +-----------------+ +----------------+
|C-VLAN(Optional)| (B) |C-VLAN (Optional)| (B)
+----------------+ +-----------------+
| Timing PDU | | Timing PDU |
| | | |
+----------------+ +-----------------+
(A) (A)
Figure (5) - Timing over PW Encapsulations Figure (5) - Timing over PW Encapsulations
In order for an LSR to process PTP messages, the top label of the In order for an LSR to process PTP messages, the top label of the
label stack (the Tunnel Label) MUST be a Timing label. label stack (the Tunnel Label) MUST be a Timing label.
6.3. Other Timing Encapsulation methods 6.3. Other Timing Encapsulation methods
In future other timing encapsulation methods may be introduced, such In future other timing encapsulation methods may be introduced, such
as a new shim header after the Bottom of Stack to carry the Timing as a new shim header after the Bottom of Stack to carry the Timing
skipping to change at page 16, line 20 skipping to change at page 17, line 20
It is the responsibility of the network operator to ensure that It is the responsibility of the network operator to ensure that
physically disjoint Timing LSPs are established between a slave clock physically disjoint Timing LSPs are established between a slave clock
(or port) and redundant master clocks (or ports). (or port) and redundant master clocks (or ports).
When a slave clock (or port) listens to redundant master clocks or When a slave clock (or port) listens to redundant master clocks or
ports, any prolonged Timing LSP outage will trigger the slave clock ports, any prolonged Timing LSP outage will trigger the slave clock
or port to switch to a redundant master clock or port. or port to switch to a redundant master clock or port.
LSP/PW protection such as Linear protection Switching (1:1, 1+1), LSP/PW protection such as Linear protection Switching (1:1, 1+1),
Ring protection switching or MPLS Fast Reroute (FRR) generally switch Ring protection switching or MPLS Fast Reroute (FRR) can switch to an
alternative path that usually cause a change in delay, which if alternative path that can cause a change in delay, which if
undetected by slave clock can reduce accuracy of the slave clock. undetected by the slave clock, can reduce accuracy of the slave
clock. While it is expected that most Slave clocks will be able to
Therefore protection switching MAY be used, as long as phase jumps detect the change in delay, this specification still recommends that
upon switchover due to differences in path latency are detected and protection switching MUST NOT be used, unless the operator knows that
compensated for (such compensation not being required if BCs or peer- the protection switching will not have any adverse effect on the
peer TCs are used throughout). slave clock.
Note that any protection or reroute mechanism that adds additional
MPLS label to the label stack, such as Facility Backup Fast Reroute,
MUST ensure that the pushed label is also a Timing Label to ensure
recognition of the MPLS frame as containing Timing messages, as it
transits the backup path.
9. ECMP 9. ECMP
To ensure the optimal operation of slave clocks and avoid error To ensure the optimal operation of slave clocks and avoid error
introduced by forward and reverse path delay asymmetry, the physical introduced by forward and reverse path delay asymmetry, the physical
path for Timing messages from master clock to slave Clock and vice path for Timing messages from master clock to slave Clock and vice
versa must be the same for all Event Timing messages listed in versa must be the same for all Event Timing messages listed in
section 7. section 7.
Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost
Multipath). Multipath).
10. PHP 10. PHP
To ensure that the label on the top of the label stack is the Timing To ensure that the label on the top of the label stack is the Timing
LSP Label, PHP MUST not be used. LSP Label, PHP MUST not be used.
11. Entropy 11. Entropy
To ensure all Timing messages in a Timing LSP take the same path, To ensure all Timing messages in a Timing LSP take the same path,
Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and Entropy Label MUST NOT be used for the Timing LSP [RFC6790] and
Entropy Label MUST NOT be used for the PWs that are carried inside Entropy Label MUST NOT be used for the PWs that are carried inside
Timing LSP [RFC6391]. Timing LSP [RFC6391].
12. OAM, Control and Management 12. OAM, Control and Management
In order to monitor Timing LSPs and their encapsulated PWs, they MUST In order to monitor Timing LSPs and their encapsulated PWs, they MUST
be able to carry OAM and management messages. These management be able to carry OAM and management messages. These management
messages MUST be differentiated from Timing messages via already messages MUST be differentiated from Timing messages via already
defined IETF methods. defined IETF methods.
skipping to change at page 23, line 43 skipping to change at page 24, line 43
Timestamps the Timing packet and sends it to the LERs Boundary clock Timestamps the Timing packet and sends it to the LERs Boundary clock
processing module. processing module.
When a Timing-capable/aware LER behaves as an Ordinary Clock toward When a Timing-capable/aware LER behaves as an Ordinary Clock toward
the MPLS network, and receives a Timing message from a Timing- the MPLS network, and receives a Timing message from a Timing-
capable/aware MPLS interface, the LER Timestamps the Timing packet capable/aware MPLS interface, the LER Timestamps the Timing packet
and sends it to the LERs Ordinary clock processing module. and sends it to the LERs Ordinary clock processing module.
15.2. Behavior of Timing-capable/aware LSR 15.2. Behavior of Timing-capable/aware LSR
When a Timing-capable/aware LSR behaves as a Transparent clock and A Timing-capable/aware LSR behaves as a Transparent clock and
receives a Timing message from a Timing-capable/aware MPLS interface, receives a Timing message from a Timing-capable/aware MPLS interface.
The LSR updates the Correction Filed (CF) and forwards the timing The LSR updates the Correction Filed (CF) and forwards the timing
message over another MPLS interface. message over another MPLS interface.
When a Timing-capable/aware LSR behaves as a Boundary clock and
receives a Timing message from a Timing-capable/aware MPLS interface.
The LSR performs the functions of a Boundary Clock in terminating the
received Timing message and re-generating a new timing message over
another (or the same) MPLS interface.
15.3. Behavior of non-Timing-capable/aware LSR 15.3. Behavior of non-Timing-capable/aware LSR
It is most beneficial when all LSRs in the path of a Timing LSP be It is most beneficial when all LSRs in the path of a Timing LSP be
timing-Capable/aware LSRs. This would ensure the highest quality timing-Capable/aware LSRs. This would ensure the highest quality
time and clock synchronization by Timing Slave Clocks. However, this time and clock synchronization by Timing Slave Clocks. However, this
specification does not mandate that all LSRs in path of a Timing LSP specification does not mandate that all LSRs in path of a Timing LSP
be Timing- capable/aware. be Timing- capable/aware.
Non-Timing-capable/aware LSRs just switch the packets encapsulated in Non-Timing-capable/aware LSRs just switch the packets encapsulated in
Timing LSPs and dont perform any Timing operation (TC or BC). Timing LSPs and dont perform any Timing operation (TC). However as
However as explained in QoS section the Timing over MPLS packets MUST explained in QoS section the Timing over MPLS packets MUST be still
be still be treated with the highest priority based on their Traffic be treated with the highest priority based on their Traffic Class
Class (TC) marking. (TC) marking.
16. Other considerations 16. Other considerations
[IEEE-1588] defines an optional peer-to-peer Transparent clocking [IEEE-1588] defines an optional peer-to-peer Transparent clocking
that requires peer delay measurement between two adjacent Timing- that requires peer delay measurement between two adjacent Timing-
capable/ aware routers/switches. Peer delay measurement messages capable/ aware routers/switches. Peer delay measurement messages
need to be time stamped and terminated by the Timing-capable/aware need to be time stamped and terminated by the Timing-capable/aware
routers/ switches. This means that two adjacent LSRs may be engaged routers/ switches. This means that two adjacent LSRs may be engaged
in a peer delay measurement. in a peer delay measurement.
skipping to change at page 27, line 5 skipping to change at page 28, line 5
Timing messages separately from other customers to ensure there is no Timing messages separately from other customers to ensure there is no
cross- customer effect. For example if an LER BC is synchronized to cross- customer effect. For example if an LER BC is synchronized to
a specific grandmaster, belonging to customer A, then the LER MUST a specific grandmaster, belonging to customer A, then the LER MUST
use that BC clock only for customer A to ensure that customer A use that BC clock only for customer A to ensure that customer A
cannot attack other customers by manipulating its time. cannot attack other customers by manipulating its time.
Timing messages MAY be encrypted or authenticated, provided that the Timing messages MAY be encrypted or authenticated, provided that the
LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the
timing messages. timing messages.
18. Acknowledgements 18. Applicability Statement
The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrahi, The Timing over MPLS transport methods described in this document
Stefano Ruffini, Peter Meyer, and other members of IETF for reviewing apply to the following network Elements:
and providing feedback on this draft.
19. IANA Considerations o An LER receives IP or Ethernet Encapsulated Timing messages from a
non-MPLS interface and forwards them as MPLS encapsulated Timing
messages over Timing LSP, while performing Transparent Clock
functionality
o An LER receives MPLS encapsulated Timing messages from a Timing
LSP and forwards them to non-MPLS interface as IP or Ethernet
Encapsulated Timing messages, while performing Transparent Clock
functionality
o An LER receives MPLS encapsulated Timing messages from a Timing
LSP and terminates them, while performing the OC or BC
functionality
o An LSR receives MPLS encapsulated Timing messages from a Timing
LSP and forwards them to another MPLS interface, while performing
the TC functionality
This document also supports the case where not all LSRs are Timing-
capable/aware. It also supports the case where not all LER/LSR
interfaces are Timing-capable/aware.
19. Acknowledgements
The authors would like to thank Luca Martini, Ron Cohen, Yaakov
Stein, Tal Mizrahi, Stefano Ruffini, Peter Meyer and other members of
IETF for reviewing and providing feedback on this draft.
20. IANA Considerations
There are no IANA requirements in this specification. There are no IANA requirements in this specification.
20. References 21. References
20.1. Normative References 21.1. Normative References
[IEEE-1588] [IEEE-1588]
IEEE 1588-2008, "IEEE Standard for a Precision Clock IEEE 1588-2008, "IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems". Control Systems".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
skipping to change at page 29, line 46 skipping to change at page 31, line 46
Connectivity Verification (VCCV): A Control Channel for Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007. Pseudowires", RFC 5085, December 2007.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010. (BFD)", RFC 5880, June 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010. Switched Paths (LSPs)", RFC 5884, June 2010.
20.2. Informative References 21.2. Informative References
[I-D.ietf-pwe3-fat-pw]
Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow Aware Transport of Pseudowires
over an MPLS Packet Switched Network",
draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011.
[ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate
system routeing information exchange protocol for use in system routeing information exchange protocol for use in
conjunction with the Protocol for providing the conjunction with the Protocol for providing the
Connectionless-mode Network Service (ISO 8473)". Connectionless-mode Network Service (ISO 8473)".
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
skipping to change at page 32, line 5 skipping to change at page 34, line 5
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow-Aware Transport of Pseudowires J., and S. Amante, "Flow-Aware Transport of Pseudowires
over an MPLS Packet Switched Network", RFC 6391, over an MPLS Packet Switched Network", RFC 6391,
November 2011. November 2011.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012. RFC 6790, November 2012.
1. Routing extensions for Timing-aware Routers 1. Appendix
1.1. Routing extensions for Timing-aware Routers
MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and
IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE)
link information used for constraint-based routing. link information used for constraint-based routing.
Indeed, it is useful to advertise data plane TE router link Indeed, it is useful to advertise data plane TE router link
capabilities, such as the capability for a router to be Timing-aware. capabilities, such as the capability for a router to be Timing-aware.
This capability MUST then be taken into account during path This capability MUST then be taken into account during path
computation to prefer or even require links that advertise themselves computation to prefer or even require links that advertise themselves
as Timing-aware. In this way the path can ensure the entry and exit as Timing-aware. In this way the path can ensure the entry and exit
skipping to change at page 33, line 5 skipping to change at page 34, line 33
Timing-aware capabilities of a link. Such extensions are outside the Timing-aware capabilities of a link. Such extensions are outside the
scope of this document; however such extension SHOULD be able to scope of this document; however such extension SHOULD be able to
signal the following information per Router Link: signal the following information per Router Link:
o Capable of processing PTP, NTP or other Timing flows o Capable of processing PTP, NTP or other Timing flows
o Capable of performing Transparent Clock operation o Capable of performing Transparent Clock operation
o Capable of performing Boundary Clock operation o Capable of performing Boundary Clock operation
2. Signaling Extensions for Creating Timing LSPs 1.2. Signaling Extensions for Creating Timing LSPs
RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE
is used to setup Timing LSPs, some information that indicates that is used to setup Timing LSPs, some information that indicates that
the LSP is carrying Timing flows MUST be included in the new the LSP is carrying Timing flows MUST be included in the new
Extensions to RSVP-TE: Extensions to RSVP-TE:
The following information MAY also be included in the new Extensions The following information MAY also be included in the new Extensions
to RSVP-TE: to RSVP-TE:
o Offset from Bottom of Stack (BoS) to the start of the Time-stamp o Offset from Bottom of Stack (BoS) to the start of the Time-stamp
skipping to change at page 35, line 4 skipping to change at line 979
Canada Canada
Email: peter.roberts@alcatel-lucent.com Email: peter.roberts@alcatel-lucent.com
Laurent Montini Laurent Montini
Cisco Systems Cisco Systems
San Jose CA San Jose CA
USA USA
Email: lmontini@cisco.com Email: lmontini@cisco.com
Luca
Cisco Systems
San Jose CA
USA
Email: lmartini@cisco.com
 End of changes. 52 change blocks. 
108 lines changed or deleted 121 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/