draft-ietf-mpls-residence-time-13.txt   draft-ietf-mpls-residence-time-14.txt 
MPLS Working Group G. Mirsky MPLS Working Group G. Mirsky
Internet-Draft ZTE Corp. Internet-Draft ZTE Corp.
Intended status: Standards Track S. Ruffini Intended status: Standards Track S. Ruffini
Expires: August 3, 2017 E. Gray Expires: August 26, 2017 E. Gray
Ericsson Ericsson
J. Drake J. Drake
Juniper Networks Juniper Networks
S. Bryant S. Bryant
Huawei Huawei
A. Vainshtein A. Vainshtein
ECI Telecom ECI Telecom
January 30, 2017 February 22, 2017
Residence Time Measurement in MPLS network Residence Time Measurement in MPLS network
draft-ietf-mpls-residence-time-13 draft-ietf-mpls-residence-time-14
Abstract Abstract
This document specifies a new Generic Associated Channel for This document specifies a new Generic Associated Channel for
Residence Time Measurement and describes how it can be used by time Residence Time Measurement and describes how it can be used by time
synchronization protocols within a MPLS domain. synchronization protocols within a MPLS domain.
Residence time is the variable part of propagation delay of timing Residence time is the variable part of propagation delay of timing
and synchronization messages and knowing what this delay is for each and synchronization messages and knowing what this delay is for each
message allows for a more accurate determination of the delay to be message allows for a more accurate determination of the delay to be
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 August 3, 2017. This Internet-Draft will expire on August 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 43 skipping to change at page 2, line 43
4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 10 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 10
4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 11 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 11
4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 11 4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 11
4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 12 4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 12
4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 12 4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 12
4.6. RTM Capability Advertisement in BGP-LS . . . . . . . . . 13 4.6. RTM Capability Advertisement in BGP-LS . . . . . . . . . 13
4.7. RSVP-TE Control Plane Operation to Support RTM . . . . . 13 4.7. RSVP-TE Control Plane Operation to Support RTM . . . . . 13
4.8. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 15 4.8. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 15
4.8.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 16 4.8.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 16
5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 19 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 19
6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 19 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 20 7.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 20
7.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 20 7.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 20
7.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 21 7.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 21
7.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 21 7.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 21
7.5. IS-IS RTM Capability sub-TLV for TLV 22 . . . . . . . . . 21 7.5. IS-IS RTM Capability sub-TLV . . . . . . . . . . . . . . 22
7.6. RTM Capability TLV in BGP-LS . . . . . . . . . . . . . . 22 7.6. RTM Capability TLV in BGP-LS . . . . . . . . . . . . . . 22
7.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 22 7.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 22
7.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 23 7.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 23
7.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 23 7.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Time synchronization protocols, e.g., Network Time Protocol version 4 Time synchronization protocols, e.g., Network Time Protocol version 4
(NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2
[IEEE.1588.2008], define timing messages that can be used to [IEEE.1588.2008], define timing messages that can be used to
synchronize clocks across a network domain. Measurement of the synchronize clocks across a network domain. Measurement of the
cumulative time that one of these timing messages spends transiting cumulative time that one of these timing messages spends transiting
skipping to change at page 3, line 32 skipping to change at page 3, line 32
the time of receipt at an ingress interface and the time of the time of receipt at an ingress interface and the time of
transmission from an egress interface for each node along the network transmission from an egress interface for each node along the network
path from an ingress node to an egress node.) This document defines path from an ingress node to an egress node.) This document defines
a new Generic Associated Channel (G-ACh) value and an associated a new Generic Associated Channel (G-ACh) value and an associated
residence time measurement (RTM) message that can be used in a Multi- residence time measurement (RTM) message that can be used in a Multi-
Protocol Label Switching (MPLS) network to measure residence time Protocol Label Switching (MPLS) network to measure residence time
over a Label Switched Path (LSP). over a Label Switched Path (LSP).
This document describes RTM over an LSP signaled using RSVP-TE This document describes RTM over an LSP signaled using RSVP-TE
[RFC3209]. Using RSVP-TE, the LSP's path can be either explicitly [RFC3209]. Using RSVP-TE, the LSP's path can be either explicitly
specified or determined during signaling. Althugh it is possible to specified or determined during signaling. Although it is possible to
use RTM over an LSP instantiated using LDP, that is outside the scope use RTM over an LSP instantiated using LDP, that is outside the scope
of this document. of this document.
Comparison with alternative proposed solutions such as Comparison with alternative proposed solutions such as
[I-D.ietf-tictoc-1588overmpls] is outside the scope of this document. [I-D.ietf-tictoc-1588overmpls] is outside the scope of this document.
1.1. Conventions used in this document 1.1. Conventions used in this document
1.1.1. Terminology 1.1.1. Terminology
skipping to change at page 11, line 44 skipping to change at page 11, line 44
4.3. RTM Capability Advertisement in OSPFv2 4.3. RTM Capability Advertisement in OSPFv2
The format for the RTM Capability sub-TLV in OSPF is presented in The format for the RTM Capability sub-TLV in OSPF is presented in
Figure 4 Figure 4
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTM | Reserved | | RTM | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+- ...
Figure 4: RTM Capability sub-TLV in OSPFv2 Figure 4: RTM Capability sub-TLV in OSPFv2
o Type value (TBA2) will be assigned by IANA from appropriate o Type value (TBA2) will be assigned by IANA from appropriate
registry for OSPFv2 Section 7.4. registry for OSPFv2 Section 7.4.
o Length MUST be set to 4. o Length value equals number of octets of the Value field.
o Value contains variable number of bit-map fields so that overall
number of bits in the fields equals Length * 8.
o Bits are defined/sent starting with Bit 0. Additional bit-map
field definitions that may be defined in the future SHOULD be
assigned in ascending bit order so as to minimize the number of
bits that will need to be transmitted.
o Undefined bits MUST be transmitted as 0 and MUST be ignored on
receipt.
o Bits that are NOT transmitted MUST be treated as if they are set
to 0 on receipt.
o RTM (capability) - is a three-bit long bit-map field with values o RTM (capability) - is a three-bit long bit-map field with values
defined as follows: defined as follows:
* 0b001 - one-step RTM supported; * 0b001 - one-step RTM supported;
* 0b010 - two-step RTM supported; * 0b010 - two-step RTM supported;
* 0b100 - reserved. * 0b100 - reserved.
o Reserved field must be set to all zeroes on transmit and ignored
on receipt.
The capability to support RTM on a particular link (interface) is The capability to support RTM on a particular link (interface) is
advertised in the OSPFv2 Extended Link Opaque LSA described in advertised in the OSPFv2 Extended Link Opaque LSA described in
Section 3 [RFC7684] via the RTM Capability sub-TLV. Section 3 [RFC7684] via the RTM Capability sub-TLV.
Its Type value will be assigned by IANA from the OSPF Extended Link Its Type value will be assigned by IANA from the OSPF Extended Link
TLV Sub-TLVs registry Section 7.4, that will be created per [RFC7684] TLV Sub-TLVs registry Section 7.4, that will be created per [RFC7684]
request. request.
4.4. RTM Capability Advertisement in OSPFv3 4.4. RTM Capability Advertisement in OSPFv3
The capability to support RTM on a particular link (interface) can be The capability to support RTM on a particular link (interface) can be
advertised in OSPFv3 using LSA extensions as described in advertised in OSPFv3 using LSA extensions as described in
[I-D.ietf-ospf-ospfv3-lsa-extend]. Exact use of OSPFv3 LSA [I-D.ietf-ospf-ospfv3-lsa-extend]. Exact use of OSPFv3 LSA
extensions is for further study. extensions is for further study.
4.5. RTM Capability Advertisement in IS-IS 4.5. RTM Capability Advertisement in IS-IS
The format for the RTM Capabilities sub-TLV is presented in Figure 5 The capability to support RTM on a particular link (interface) is
advertised in a new sub-TLV which may be included in TLVs advertising
Intermediate System (IS) Reachability on a specific link (TLVs 22,
23, 222, and 223).
0 1 2 3 The format for the RTM Capabilities sub-TLV is presented in Figure 5
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 ...
| Type | Length | RTM | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | RTM | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 5: RTM Capability sub-TLV for the Extended IS Reachability TLV Figure 5: RTM Capability sub-TLV
o Type value (TBA3) will be assigned by IANA from the Sub-TLVs for o Type value (TBA3) will be assigned by IANA from the Sub-TLVs for
TLVs 22, 23, 141, 222, and 223 registry for IS-IS Section 7.5. TLVs 22, 23, 141, 222, and 223 registry for IS-IS Section 7.5.
o Length MUST be set to 2. o Definitions, rules of handling, and values for fields Length and
Value are as defined in Section 4.3
o RTM (capability) - as defined in Section 4.3.
o Reserved field must be set to all zeroes on transmit and ignored
on receipt.
The capability to support RTM on a particular link (interface) is o RTM (capability) - is a three-bit long bit-map field with values
advertised in the Extended IS Reachability TLV described in [RFC5305] defined in Section 4.3.
via the RTM Capability sub-TLV.
4.6. RTM Capability Advertisement in BGP-LS 4.6. RTM Capability Advertisement in BGP-LS
The format for the RTM Capabilities TLV is as presented in Figure 4. The format for the RTM Capabilities TLV is as presented in Figure 4.
Type value TBA9 will be assigned by IANA from the BGP-LS Node Type value TBA9 will be assigned by IANA from the BGP-LS Node
Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs
sub-registry Section 7.6. sub-registry Section 7.6.
Length, RTM, and Reserved fields as defined in Section 4.3. Definitions, rules of handling, and values for fields Length, Value,
and RTM are as defined in Section 4.3.
The RTM Capability will be advertised in BGP-LS as a Link Attribute The RTM Capability will be advertised in BGP-LS as a Link Attribute
TLV associated with the Link NLRI as described in section 3.3.2 of TLV associated with the Link NLRI as described in section 3.3.2 of
[RFC7752]. [RFC7752].
4.7. RSVP-TE Control Plane Operation to Support RTM 4.7. RSVP-TE Control Plane Operation to Support RTM
Throughout this document we refer to a node as RTM capable node when Throughout this document we refer to a node as RTM capable node when
at least one of its interfaces is RTM capable. Figure 6 provides an at least one of its interfaces is RTM capable. Figure 6 provides an
example of roles a node may have with respect to RTM capability: example of roles a node may have with respect to RTM capability:
skipping to change at page 19, line 15 skipping to change at page 19, line 33
5. Data Plane Theory of Operation 5. Data Plane Theory of Operation
After instantiating an LSP for a path using RSVP-TE [RFC3209] as After instantiating an LSP for a path using RSVP-TE [RFC3209] as
described in Section 4.7, the ingress node MAY begin sending RTM described in Section 4.7, the ingress node MAY begin sending RTM
packets to the first downstream RTM capable node on that path. Each packets to the first downstream RTM capable node on that path. Each
RTM packet has its Scratch Pad field initialized and its TTL set to RTM packet has its Scratch Pad field initialized and its TTL set to
expire on the next downstream RTM-capable node. Each RTM-capable expire on the next downstream RTM-capable node. Each RTM-capable
node on the explicit path receives an RTM packet and records the time node on the explicit path receives an RTM packet and records the time
at which it receives that packet at its ingress interface as well as at which it receives that packet at its ingress interface as well as
the time at which it transmits that packet from its egress interface; the time at which it transmits that packet from its egress interface.
this should be done as close to the physical layer as possible to These actions should be done as close to the physical layer as
ensure precise accuracy in time determination. The RTM-capable node possible at the same point of packet processing striving to avoid
introducing the appearance of jitter in propagation delay whereas it
should be accounted as residence time. The RTM-capable node
determines the difference between those two times; for one-step determines the difference between those two times; for one-step
operation, this difference is determined just prior to or while operation, this difference is determined just prior to or while
sending the packet, and the RTM-capable egress interface adds it to sending the packet, and the RTM-capable egress interface adds it to
the value in the Scratch Pad field of the message in progress. Note, the value in the Scratch Pad field of the message in progress. Note,
for the purpose of calculating a residence time, a common free for the purpose of calculating a residence time, a common free
running clock synchronizing all the involved interfaces may be running clock synchronizing all the involved interfaces may be
sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond
error for residence time on the order of 1 millisecond. This may be error for residence time on the order of 1 millisecond. This may be
acceptable for applications where the target accuracy is in the order acceptable for applications where the target accuracy is in the order
of hundreds of ns. As an example several applications being of hundreds of ns. As an example several applications being
skipping to change at page 21, line 42 skipping to change at page 22, line 13
from OSPFv2 Extended Link TLV Sub-TLVs registry as follows: from OSPFv2 Extended Link TLV Sub-TLVs registry as follows:
+-------+----------------+---------------+ +-------+----------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+----------------+---------------+ +-------+----------------+---------------+
| TBA2 | RTM Capability | This document | | TBA2 | RTM Capability | This document |
+-------+----------------+---------------+ +-------+----------------+---------------+
Table 4: RTM Capability sub-TLV Table 4: RTM Capability sub-TLV
7.5. IS-IS RTM Capability sub-TLV for TLV 22 7.5. IS-IS RTM Capability sub-TLV
IANA is requested to assign a new Type for RTM capability sub-TLV IANA is requested to assign a new Type for RTM capability sub-TLV
from the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry as from the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry as
follows: follows:
+------+-------------+----+----+-----+-----+-----+---------------+ +------+----------------+----+----+-----+-----+-----+---------------+
| Type | Description | 22 | 23 | 141 | 222 | 223 | Reference | | Type | Description | 22 | 23 | 141 | 222 | 223 | Reference |
+------+-------------+----+----+-----+-----+-----+---------------+ +------+----------------+----+----+-----+-----+-----+---------------+
| TBA3 | RTM | y | n | n | n | n | This document | | TBA3 | RTM Capability | y | y | n | y | y | This document |
+------+-------------+----+----+-----+-----+-----+---------------+ +------+----------------+----+----+-----+-----+-----+---------------+
Table 5: IS-IS RTM Capability sub-TLV for TLV 22 Table 5: IS-IS RTM Capability sub-TLV Registry Description
7.6. RTM Capability TLV in BGP-LS 7.6. RTM Capability TLV in BGP-LS
IANA is requested to assign a new code point for RTM Capability TLV IANA is requested to assign a new code point for RTM Capability TLV
from BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and from BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs sub-registry in its Border Gateway Protocol - Link Attribute TLVs sub-registry in its Border Gateway Protocol - Link
State (BGP-LS) Parameters registry as follows: State (BGP-LS) Parameters registry as follows:
+---------------+----------------+------------------+---------------+ +---------------+----------------+------------------+---------------+
| TLV Code | Description | IS-IS TLV/Sub- | Reference | | TLV Code | Description | IS-IS TLV/Sub- | Reference |
skipping to change at page 24, line 39 skipping to change at page 25, line 16
modify the G-ACh content, this is an issue that exists for nodes in modify the G-ACh content, this is an issue that exists for nodes in
general - for any and all data that may be carried over an LSP - and general - for any and all data that may be carried over an LSP - and
is therefore the basis for an additional presumed trust model is therefore the basis for an additional presumed trust model
associated with existing LSPs and nodes. associated with existing LSPs and nodes.
Security requirements of time protocols are provided in RFC 7384 Security requirements of time protocols are provided in RFC 7384
[RFC7384]. [RFC7384].
9. Acknowledgments 9. Acknowledgments
Authors want to thank Loa Andersson, Lou Berger and Acee Lindem for Authors want to thank Loa Andersson, Lou Berger, Acee Lindem, Les
their thorough reviews, thoughtful comments and, most of all, Ginsberg, and Uma Chunduri for their thorough reviews, thoughtful
patience. comments and, most of all, patience.
10. References 10. References
10.1. Normative References 10.1. Normative References
[IEEE.1588.2008] [IEEE.1588.2008]
"Standard for a Precision Clock Synchronization Protocol "Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems", for Networked Measurement and Control Systems",
IEEE Standard 1588, July 2008. IEEE Standard 1588, July 2008.
skipping to change at page 25, line 30 skipping to change at page 26, line 5
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <http://www.rfc-editor.org/info/rfc4385>. February 2006, <http://www.rfc-editor.org/info/rfc4385>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <http://www.rfc-editor.org/info/rfc5085>. December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
February 2009, <http://www.rfc-editor.org/info/rfc5420>. February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586, "MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009, DOI 10.17487/RFC5586, June 2009,
<http://www.rfc-editor.org/info/rfc5586>. <http://www.rfc-editor.org/info/rfc5586>.
 End of changes. 24 change blocks. 
51 lines changed or deleted 60 lines changed or added

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