draft-ietf-tictoc-1588overmpls-00.txt   draft-ietf-tictoc-1588overmpls-01.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: Standards Track Broadcom Corp.
Expires: July 30, 2011 L. Martini Expires: November 25, 2011 M. Bhatia
Cisco Systems
M. Bhatia
P. Roberts P. Roberts
Alcatel-Lucent Alcatel-Lucent
January 26, 2011 L. Montini
Cisco Systems
May 24, 2011
Transporting PTP messages (1588) over MPLS Networks Transporting PTP messages (1588) over MPLS Networks
draft-ietf-tictoc-1588overmpls-00 draft-ietf-tictoc-1588overmpls-01
Abstract Abstract
This document defines the method for transporting PTP messages (PDUs) This document defines the method for transporting PTP messages (PDUs)
over an MPLS network to enable a proper handling of these packets over an MPLS network to enable a proper handling of these packets
(e.g. implementation of Transparent Clocks (TC)) in LSRs. (e.g. implementation of Transparent Clocks (TC)) in LSRs.
The basic idea is to transport PTP messages inside dedicated MPLS The basic idea is to transport PTP messages inside dedicated MPLS
LSPs. These LSPs only carry PTP messages and possibly Control and LSPs. These LSPs only carry PTP messages and possibly Control and
Management packets, but they do not carry customer traffic. Management packets, but they do not carry customer traffic.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 July 30, 2011. This Internet-Draft will expire on November 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 35 skipping to change at page 3, line 35
9. OAM, Control and Management . . . . . . . . . . . . . . . . . 18 9. OAM, Control and Management . . . . . . . . . . . . . . . . . 18
10. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 19 10. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 19
11. FCS Recalculation . . . . . . . . . . . . . . . . . . . . . . 20 11. FCS Recalculation . . . . . . . . . . . . . . . . . . . . . . 20
12. UDP Checksum Correction . . . . . . . . . . . . . . . . . . . 21 12. UDP Checksum Correction . . . . . . . . . . . . . . . . . . . 21
13. Routing extensions for 1588aware LSRs . . . . . . . . . . . . 22 13. Routing extensions for 1588aware LSRs . . . . . . . . . . . . 22
13.1. 1588aware Node Capability for OSPF . . . . . . . . . . . . 22 13.1. 1588aware Link Capability for OSPF . . . . . . . . . . . . 22
13.2. 1588aware Node Capability for IS-IS . . . . . . . . . . . 23 13.2. 1588aware Link Capability for IS-IS . . . . . . . . . . . 23
14. RSVP-TE Extensions for support of 1588 . . . . . . . . . . . . 26 14. RSVP-TE Extensions for support of 1588 . . . . . . . . . . . . 25
15. Distributing PW labels . . . . . . . . . . . . . . . . . . . . 27 15. Distributing PW labels . . . . . . . . . . . . . . . . . . . . 26
15.1. LDP extensions for distributing PW labels . . . . . . . . 27 15.1. LDP extensions for distributing PW labels . . . . . . . . 26
15.2. BGP extensions for distributing PW labels . . . . . . . . 27 15.2. BGP extensions for distributing PW labels . . . . . . . . 26
16. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 28 16. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 27
16.1. Behavior of 1588-aware LER . . . . . . . . . . . . . . . . 28 16.1. Behavior of 1588-aware LER . . . . . . . . . . . . . . . . 27
16.2. Behavior of 1588-aware LSR . . . . . . . . . . . . . . . . 28 16.2. Behavior of 1588-aware LSR . . . . . . . . . . . . . . . . 27
16.3. Behavior of non-1588-aware LSR . . . . . . . . . . . . . . 28 16.3. Behavior of non-1588-aware LSR . . . . . . . . . . . . . . 27
17. Other considerations . . . . . . . . . . . . . . . . . . . . . 30 17. Other considerations . . . . . . . . . . . . . . . . . . . . . 29
18. Security Considerations . . . . . . . . . . . . . . . . . . . 31 18. Security Considerations . . . . . . . . . . . . . . . . . . . 30
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
19.1. IANA Considerations for OSPF . . . . . . . . . . . . . . . 32
19.2. IANA Considerations for IS-IS . . . . . . . . . . . . . . 32
19.3. IANA Considerations for RSVP . . . . . . . . . . . . . . . 32
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
20.1. Normative References . . . . . . . . . . . . . . . . . . . 33 20.1. IANA Considerations for OSPF . . . . . . . . . . . . . . . 32
20.2. Informative References . . . . . . . . . . . . . . . . . . 33 20.2. IANA Considerations for IS-IS . . . . . . . . . . . . . . 32
20.3. IANA Considerations for RSVP . . . . . . . . . . . . . . . 32
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
21.1. Normative References . . . . . . . . . . . . . . . . . . . 33
21.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
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].
skipping to change at page 8, line 11 skipping to change at page 8, line 11
This document provides two methods for transporting PTP messages over This document provides two methods for transporting PTP messages over
MPLS. The main objectives are for LSRs to be able to MPLS. The main objectives are for LSRs to be able to
deterministically detect and identify the PTP messages. deterministically detect and identify the PTP messages.
2. Terminology 2. Terminology
1588: The timing and synchronization as defined by IEEE 1588 1588: The timing and synchronization as defined by IEEE 1588
PTP: The timing and synchronization protocol used by 1588 PTP: The timing and synchronization protocol used by 1588
Master: The Source of 1588 Timing and clock Master: The Source of 1588 Timing and clock. This will be a port in
master state on a Grandmaster Clock or on a Boundary Clock.
Slave: The Destination of 1588 Timing and clock that tries to follow Slave: The Destination of 1588 Timing and clock that tries to follow
the Master clock the Master clock. This will be a port in slave state on a boundary
clock or on a Slave-Only Ordinary Clock.
OC: Ordinary Clock OC: Ordinary Clock - a device with a single PTP port.
TC: Transparent Clock, a time stamping method applied by intermediate TC: Transparent Clock, a time stamping method applied by intermediate
nodes between Master and Slave nodes between Master and Slave
BC: Boundary Clock, is a node that recovers the Master clock via a BC: Boundary Clock, is a node that recovers the Master clock via a
Slave function and uses that clock as the Master for other Slaves Slave function and uses that clock as the Master for other Slaves
PTP LSP: An LSP dedicated to carry PTP messages PTP LSP: An LSP dedicated to carry PTP messages
PTP PW: A PW within a PTP LSP that is dedicated to carry PTP PTP PW: A PW within a PTP LSP that is dedicated to carry PTP
skipping to change at page 20, line 7 skipping to change at page 20, line 7
The PTP messages are time critical and must be treated with the The PTP messages are time critical and must be treated with the
highest priority. Therefore 1588 over MPLS messages must be treated highest priority. Therefore 1588 over MPLS messages must be treated
with the highest priority in the routers. This can be achieved by with the highest priority in the routers. This can be achieved by
proper setup of PTP tunnels. It is recommended that the PTP LSPs are proper setup of PTP tunnels. It is recommended that the PTP LSPs are
setup and marked properly to indicate EF-PHB for the CoS and Green setup and marked properly to indicate EF-PHB for the CoS and Green
for drop eligibility. for drop eligibility.
11. FCS Recalculation 11. FCS Recalculation
Ethernet FCS MUST be recalculated at every LSR that performs the TC Ethernet FCS of the outer encapsulation MUST be recalculated at every
processing and FCS retention described in [RFC4720] MUST not be used. LSR that performs the TC processing and FCS retention for the payload
Ethernet described in [RFC4720] MUST not be used.
12. UDP Checksum Correction 12. UDP Checksum Correction
For UDP/IP encapsulation mode of 1588 over MPLS, the UDP checksum is For UDP/IP encapsulation mode of 1588 over MPLS, the UDP checksum is
optional when used for IPv4 encapsulation and mandatory in case of optional when used for IPv4 encapsulation and mandatory in case of
IPv6. When IPv4/v6 UDP checksum is used each 1588-aware LSR must IPv6. When IPv4/v6 UDP checksum is used each 1588-aware LSR must
either incrementally update the UDP checksum after the CF update or either incrementally update the UDP checksum after the CF update or
should verify the UDP checksum on reception from upstream and should verify the UDP checksum on reception from upstream and
recalculate the checksum completely on transmission after CF update recalculate the checksum completely on transmission after CF update
to downstream node. to downstream node.
13. Routing extensions for 1588aware LSRs 13. Routing extensions for 1588aware LSRs
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 node capabilities, Indeed, it is useful to advertise data plane TE router link
such as the capability for a router to be 1588-aware. This capabilities, such as the capability for a router to be 1588-aware.
capability MUST then be taken into account during path computation to This capability MUST then be taken into account during path
prefer nodes that advertise themselves as 1588-aware, so that the PTP computation to prefer links that advertise themselves as 1588-aware,
LSPs can be properly handled. so that the PTP LSPs can be properly handled.
For this purpose, the following sections specify extensions to OSPF For this purpose, the following sections specify extensions to OSPF
and IS-IS in order to advertise 1588 aware capabilities of a node. and IS-IS in order to advertise 1588 aware capabilities of a link.
Editor Note: There is an open issue on whether we must consider LSRs
that may not want to support PTP on all ports. An example could be
an LSR where a few blades have been upgraded to support PTP
timestamping in silicon. In such cases, routers must explicitly
indicate the ports that are 1588-aware. If the WG agrees about this
then we will need to change the subsequent OSPF and IS-IS sections to
advertise the 1588-aware capability on per port/interface basis,
rather than per node as is current described.
13.1. 1588aware Node Capability for OSPF 13.1. 1588aware Link Capability for OSPF
This extension makes use of the Router Information (RI) Opaque LSA OSPF uses the Link TLV (Type 2) that is itself carried within either
defined in [RFC4970]for both OSPFv2 and OSPFv3, by defining a new the Traffic Engineering LSA specified in [RFC3630] or the OSPFv3
OSPF Router Information (RI) TLV - The 1588-aware Capability TLV. Intra-Area-TE LSA (function code 10) defined in [RFC5329] to
advertise the TE related information for the locally attached router
links. For an LSA Type 10, one LSA can contain one Link TLV
information for a single link. This extension defines a new 1588-
aware capability sub-TLV that can be carried as part of the Link TLV.
The 1588-aware Capability TLV is OPTIONAL and is defined as follows: The 1588-aware capability sub-TLV is OPTIONAL and MUST NOT appear
more than once within the Link TLV. If a second instance of the
1588-aware capability sub-TLV is present, the receiving system MUST
only process the first instance of the sub-TLV. It is defined as
follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: 1588-aware Capability TLV Figure 3: 1588-aware Capability TLV
skipping to change at page 23, line 17 skipping to change at page 23, line 15
first, so bit 7 is the least significant bit of the flags octet. first, so bit 7 is the least significant bit of the flags octet.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved |C| | Reserved |C|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 4: Flags Format Figure 4: Flags Format
Correction (C) field Update field, 1 bit: Setting the C bit to 1 Correction (C) field Update field, 1 bit: Setting the C bit to 1
indicates that the node is capable of recognizing the PTP event indicates that the link is capable of recognizing the PTP event
packets and can compensate for residence time by updating the PTP packets and can compensate for residence time by updating the PTP
packet Correction Field. When this is set to 0, it means that this packet Correction Field. When this is set to 0, it means that this
node cannot perform the residence time correction but is capable of link cannot perform the residence time correction but is capable of
performing MPLS frame forwarding of the frames with PTP labels using performing MPLS frame forwarding of the frames with PTP labels using
a method that support the end to end delivery of accurate timing. a method that support the end to end delivery of accurate timing.
The exact method is not defined herein. The exact method is not defined herein.
Reserved, 7 bits: Reserved for future use. The reserved bits must be Reserved, 7 bits: Reserved for future use. The reserved bits must be
ignored by the receiver. ignored by the receiver.
The 1588-aware Capability TLV is applicable to both OSPFv2 and The 1588-aware Capability sub-TLV is applicable to both OSPFv2 and
OSPFv3. OSPFv3.
The 1588-aware Capability TLV MAY be advertised within an area-local 13.2. 1588aware Link Capability for IS-IS
or autonomous system (AS) scope Router Information (RI) LSA. But the
1588-aware Capability TLV SHOULD NOT be advertised into an area in
more than one RI LSA irrespective of the scope of the LSA.
The flooding scope is controlled by the Opaque LSA type in OSPFv2 and
by the S1 and S2 bits in OSPFv3. For area scope, the 1588-aware
Capability TLV MUST be carried within an OSPFv2 Type 10 RI LSA or an
OSPFv3 RI LSA with the S1 bit set and S2 bit clear. If the flooding
scope is the entire routing domain (AS scope), the 1588-aware
Capability TLV MUST be carried within an OSPFv2 Type 11 RI LSA or
OSPFv3 RI LSA with the S1 bit clear and the S2 bit set.
13.2. 1588aware Node Capability for IS-IS
Generic capability advertisement mechanisms for IS-IS are defined in The IS-IS Traffic Engineering [RFC3784] defines the intra-area
[RFC4971]. These allow a router to advertise its capabilities within traffic engineering enhancements and uses the Extended IS
an IS-IS area or an entire IS-IS routing domain. This document Reachability TLV (Type 22) [RFC5305] to carry the per link TE-related
defines a new sub-TLV (named the 1588-aware Capability) to be carried information. This extension defines a new 1588-aware capability sub-
within the IS-IS Router Capability TLV. TLV that can be carried as part of the Extended IS Reachability TLV.
The IS-IS extensions defined in this document allow for discovering The 1588-aware capability sub-TLV is OPTIONAL and MUST NOT appear
1588-aware nodes within an IS-IS routing domain. Solutions for 1588- more than once within the Extended IS Reachability TLV or the Multi-
aware nodes discovery across AS boundaries are beyond the scope of Topology (MT) Intermediate Systems TLV (type 222) specified in
this document, and are for further study. [RFC5120]. If a second instance of the 1588-aware capability sub-TLV
is present, the receiving system MUST only process the first instance
of the sub-TLV.
The format of the IS-IS 1588-aware sub-TLV is identical to the TLV The format of the IS-IS 1588-aware sub-TLV is identical to the TLV
format used by the Traffic Engineering Extensions to IS-IS [RFC3784]. format used by the Traffic Engineering Extensions to IS-IS [RFC3784].
That is, the TLV is comprised of 1 octet for the type, 1 octet That is, the TLV is comprised of 1 octet for the type, 1 octet
specifying the TLV length, and a value field. The Length field specifying the TLV length, and a value field. The Length field
defines the length of the value portion in octets. defines the length of the value portion in octets.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 43 skipping to change at page 24, line 31
first, so bit 7 is the least significant bit of the flags octet. first, so bit 7 is the least significant bit of the flags octet.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved |C| | Reserved |C|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 6: Flags Format Figure 6: Flags Format
Correction (C) field Update field, 1 bit: Setting the C bit to 1 Correction (C) field Update field, 1 bit: Setting the C bit to 1
indicates that the node is capable of recognizing the PTP event indicates that the link is capable of recognizing the PTP event
packets and can compensate for residence time by updating the PTP packets and can compensate for residence time by updating the PTP
packet Correction Field. When this is set to 0, it means that this packet Correction Field. When this is set to 0, it means that this
node cannot perform the residence time correction but is capable of link cannot perform the residence time correction but is capable of
performing MPLS frame forwarding of the frames with PTP labels using performing MPLS frame forwarding of the frames with PTP labels using
a method that support the end to end delivery of accurate timing. a method that support the end to end delivery of accurate timing.
The exact method is not defined herein. The exact method is not defined herein.
Reserved, 7 bits: Reserved for future use. The reserved bits must be Reserved, 7 bits: Reserved for future use. The reserved bits must be
ignored by the receiver. ignored by the receiver.
The 1588-aware sub-TLV is optional and is carried within an IS-IS
Capability TLV [RFC4971] to facilitate selection of 1588-aware nodes.
The flooding scope for 1588-aware node information advertised through
IS-IS can be a single L1 area, an L1 area and the L2 sub-domain, or
the entire IS-IS routing domain.
14. RSVP-TE Extensions for support of 1588 14. RSVP-TE Extensions for support of 1588
RSVP-TE signaling MAY be used to setup the PTP LSPs. A new RSVP RSVP-TE signaling MAY be used to setup the PTP LSPs. A new RSVP
object is defined to signal that this is a PTP LSP. The OFFSET to object is defined to signal that this is a PTP LSP. The OFFSET to
the start of the PTP message header MAY also be signaled. the start of the PTP message header MAY also be signaled.
Implementations can trivially locate the correctionField (CF) Implementations can trivially locate the correctionField (CF)
location given this information. The OFFSET points to the start of location given this information. The OFFSET points to the start of
the PTP header as a node may want to check the PTP messageType before the PTP header as a node may want to check the PTP messageType before
it touches the correctionField (CF). it touches the correctionField (CF).
skipping to change at page 32, line 5 skipping to change at page 31, line 5
18. Security Considerations 18. Security Considerations
MPLS PW security considerations in general are discussed in [RFC3985] MPLS PW security considerations in general are discussed in [RFC3985]
and [RFC4447],and those considerations also apply to this document. and [RFC4447],and those considerations also apply to this document.
An experimental security protocol is defined in [IEEE]. The PTP An experimental security protocol is defined in [IEEE]. The PTP
security extension and protocol provides group source authentication, security extension and protocol provides group source authentication,
message integrity, and replay attack protection for PTP messages. message integrity, and replay attack protection for PTP messages.
19. IANA Considerations 19. Acknowledgements
19.1. IANA Considerations for OSPF The authors would like to thank Luca Martini, Ron Cohen, Yaakov
Stein, Tal Mizrahi and other members of the TICTOC WG for reviewing
and providing feedback on this draft.
IANA has defined a registry for TLVs carried in the Router 20. IANA Considerations
Information LSA defined in [RFC4970]. IANA is requested to assign a
new TLV code-point for the PCED TLV carried within the Router 20.1. IANA Considerations for OSPF
Information LSA.
IANA has defined a sub-registry for the sub-TLVs carried in an OSPF
TE Link TLV (type 2). IANA is requested to assign a new sub-TLV
codepoint for the 1588aware capability sub-TLV carried within the
Router Link TLV.
Value Sub-TLV References Value Sub-TLV References
----- ---------------------- ---------- ----- ---------------------- ----------
TBD 1588aware node sub-TLV (this document) TBD 1588aware node sub-TLV (this document)
19.2. IANA Considerations for IS-IS 20.2. IANA Considerations for IS-IS
IANA has defined a registry for the sub-TLVs carried in the IS-IS IANA has defined a sub-registry for the sub-TLVs carried in the IS-IS
Router Capability sub-TLVs defined in [RFC4971]. IANA is requested Extended IS Reacability TLV. IANA is requested to assign a new sub-
to assign a new sub-TLV code-point for the 1588aware node sub-TLV TLV code-point for the 1588aware capability sub-TLV carried within
carried within the Router Capability sub-TLV. the Extended IS Reacability TLV.
Value Sub-TLV References Value Sub-TLV References
----- ---------------------- ---------- ----- ---------------------- ----------
TBD 1588aware node sub-TLV (this document) TBD 1588aware node sub-TLV (this document)
19.3. IANA Considerations for RSVP 20.3. IANA Considerations for RSVP
IANA is requested to assign a new Class Number for 1588 PTP LSP IANA is requested to assign a new Class Number for 1588 PTP LSP
object that is used to signal PTP LSPs. object that is used to signal PTP LSPs.
1588 PTP LSP Object 1588 PTP LSP Object
Class-Num of type 11bbbbbb Class-Num of type 11bbbbbb
Suggested value TBD Suggested value TBD
Defined CType: 1 (1588 PTP LSP) Defined CType: 1 (1588 PTP LSP)
20. References 21. References
20.1. Normative References 21.1. Normative References
[IEEE] IEEE 1588-2008, "IEEE Standard for a Precision Clock [IEEE] 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-
Edge (PWE3) Architecture", RFC 3985, March 2005. Edge (PWE3) Architecture", RFC 3985, March 2005.
skipping to change at page 33, line 45 skipping to change at page 33, line 45
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] [I-D.ietf-pwe3-fat-pw]
Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 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 PSN", draft-ietf-pwe3-fat-pw-05 (work in over an MPLS Packet Switched Network",
progress), October 2010. draft-ietf-pwe3-fat-pw-06 (work in progress), May 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.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)", System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004. RFC 3784, June 2004.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007. Router Capabilities", RFC 4970, July 2007.
[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
System to Intermediate System (IS-IS) Extensions for System to Intermediate System (IS-IS) Extensions for
Advertising Router Information", RFC 4971, July 2007. Advertising Router Information", RFC 4971, July 2007.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, September 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
Authors' Addresses Authors' Addresses
Shahram Davari Shahram Davari
Broadcom Corp. Broadcom Corp.
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: davari@broadcom.com Email: davari@broadcom.com
Amit Oren Amit Oren
Broadcom Corp. Broadcom Corp.
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: amito@broadcom.com Email: amito@broadcom.com
Luca Martini
Cisco Systems
San Jose CA
USA
Email: lmartini@cisco.com
Manav Bhatia Manav Bhatia
Alcatel-Lucent Alcatel-Lucent
Bangalore, Bangalore,
India India
Email: manav.bhatia@alcatel-lucent.com Email: manav.bhatia@alcatel-lucent.com
Peter Roberts Peter Roberts
Alcatel-Lucent Alcatel-Lucent
Kanata, Kanata,
Canada Canada
Email: peter.roberts@alcatel-lucent.com Email: peter.roberts@alcatel-lucent.com
Laurent Montini
Cisco Systems
San Jose CA
USA
Email: lmontini@cisco.com
 End of changes. 43 change blocks. 
109 lines changed or deleted 109 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/