draft-ietf-mpls-residence-time-06.txt   draft-ietf-mpls-residence-time-07.txt 
MPLS Working Group G. Mirsky MPLS Working Group G. Mirsky
Internet-Draft S. Ruffini Internet-Draft S. Ruffini
Intended status: Standards Track E. Gray Intended status: Standards Track E. Gray
Expires: September 19, 2016 Ericsson Expires: October 9, 2016 Ericsson
J. Drake J. Drake
Juniper Networks Juniper Networks
S. Bryant S. Bryant
Cisco Systems Cisco Systems
A. Vainshtein A. Vainshtein
ECI Telecom ECI Telecom
March 18, 2016 April 7, 2016
Residence Time Measurement in MPLS network Residence Time Measurement in MPLS network
draft-ietf-mpls-residence-time-06 draft-ietf-mpls-residence-time-07
Abstract Abstract
This document specifies G-ACh based Residence Time Measurement and This document specifies G-ACh based Residence Time Measurement and
how it can be used by time synchronization protocols being how it can be used by time synchronization protocols being
transported over MPLS domain. transported over 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 45 skipping to change at page 1, line 45
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 September 19, 2016. This Internet-Draft will expire on October 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 38 skipping to change at page 2, line 38
3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 6 3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 6
4. Control Plane Theory of Operation . . . . . . . . . . . . . . 7 4. Control Plane Theory of Operation . . . . . . . . . . . . . . 7
4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7
4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8
4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9 4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9
4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9 4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9
4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 9 4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 9
4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10 4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10
4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11 4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11
4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 13 4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 13
5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 15 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 16
6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 16 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 16
7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 16 7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19 8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19
8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19 8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19
8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20 8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20
8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20 8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20
8.5. RTM Capability sub-TLV in OSPFv3 . . . . . . . . . . . . 20 8.5. RTM Capability sub-TLV in OSPFv3 . . . . . . . . . . . . 21
8.6. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21 8.6. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21
8.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21 8.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21
8.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22 8.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22
8.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 22 8.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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.2014] 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 one of these timing messages spends transiting the cumulative time one of these timing messages spends transiting the
nodes on the path from ingress node to egress node is termed nodes on the path from ingress node to egress node is termed
Residence Time and it is used to improve the accuracy of clock Residence Time and it is used to improve the accuracy of clock
synchronization. (I.e., it is the sum of the difference between the synchronization. (I.e., it is the sum of the difference between the
time of receipt at an ingress interface and the time of transmission time of receipt at an ingress interface and the time of transmission
from an egress interface for each node along the path from ingress from an egress interface for each node along the path from ingress
node to egress node.) This document defines a new Generalized node to egress node.) This document defines a new Generalized
Associated Channel (G-ACh) value and an associated residence time Associated Channel (G-ACh) value and an associated residence time
measurement (RTM) packet that can be used in a Multi-Protocol Label measurement (RTM) packet that can be used in a Multi-Protocol Label
skipping to change at page 4, line 32 skipping to change at page 4, line 32
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Residence Time Measurement 2. Residence Time Measurement
Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be
used to measure one-way or two-way end-to-end propagation delay over used to measure one-way or two-way end-to-end propagation delay over
LSP or PW. But these measurements are insufficient for use in some LSP or PW. But these measurements are insufficient for use in some
applications, for example, time synchronization across a network as applications, for example, time synchronization across a network as
defined in the Precision Time Protocol (PTP). In PTPv2 defined in the Precision Time Protocol (PTP). In PTPv2
[IEEE.1588.2008] residence times is accumulated in the [IEEE.1588.2014] residence times is accumulated in the
correctionField of the PTP event message, as defined in correctionField of the PTP event message, as defined in
[IEEE.1588.2008], or in the associated follow-up message (or [IEEE.1588.2014], or in the associated follow-up message (or
Delay_Resp message associated with the Delay_Req message) in case of Delay_Resp message associated with the Delay_Req message) in case of
two-step clocks (see the detailed discussion in Section 7). two-step clocks (see the detailed discussion in Section 7).
IEEE 1588 uses this residence time to correct the transit time from IEEE 1588 uses this residence time to correct the transit time from
ingress node to egress node, effectively making the transit nodes ingress node to egress node, effectively making the transit nodes
transparent. transparent.
This document proposes a mechanism that can be used as one of types This document proposes a mechanism that can be used as one of types
of on-path support for a clock synchronization protocol or to perform of on-path support for a clock synchronization protocol or to perform
one-way measurement of residence time. The proposed mechanism one-way measurement of residence time. The proposed mechanism
skipping to change at page 6, line 9 skipping to change at page 6, line 9
field with its residence time measurement. Its format is IEEE field with its residence time measurement. Its format is IEEE
double precision and its units are nanoseconds. Note that double precision and its units are nanoseconds. Note that
depending on whether the timing procedure is one-step or two-step depending on whether the timing procedure is one-step or two-step
operation (Section 7), the residence time is either for the timing operation (Section 7), the residence time is either for the timing
packet carried in the Value field of this RTM packet or for an packet carried in the Value field of this RTM packet or for an
associated timing packet carried in the Value field of another RTM associated timing packet carried in the Value field of another RTM
packet. packet.
o The Type field identifies the type and encapsulation of a timing o The Type field identifies the type and encapsulation of a timing
packet carried in the Value field, e.g., NTP [RFC5905] or PTP packet carried in the Value field, e.g., NTP [RFC5905] or PTP
[IEEE.1588.2008]. IANA will be asked to create a sub-registry in [IEEE.1588.2014]. IANA will be asked to create a sub-registry in
Generic Associated Channel (G-ACh) Parameters Registry called Generic Associated Channel (G-ACh) Parameters Registry called
"MPLS RTM TLV Registry". "MPLS RTM TLV Registry".
o The Length field contains the length, in octets , of the of the o The Length field contains the length, in octets , of the of the
timing packet carried in the Value field. timing packet carried in the Value field.
o The optional Value field MAY carry a packet of the time o The optional Value field MAY carry a packet of the time
synchronization protocol identified by Type field. It is synchronization protocol identified by Type field. It is
important to note that the packet may be authenticated or important to note that the packet may be authenticated or
encrypted and carried over LSP edge to edge unchanged while the encrypted and carried over LSP edge to edge unchanged while the
skipping to change at page 7, line 13 skipping to change at page 7, line 13
where Flags field has format where Flags field has format
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 4 5 6 7 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flags field format of PTP Packet Sub-TLV Figure 3: Flags field format of PTP Packet Sub-TLV
o The Type field identifies PTP sub-TLV defined in the Table 19 o The Type field identifies PTP sub-TLV defined in the Table 19
Values of messageType field in [IEEE.1588.2008]. Values of messageType field in [IEEE.1588.2014].
o The Length field of the PTP sub-TLV contains the number of octets o The Length field of the PTP sub-TLV contains the number of octets
of the Value field and MUST be 20. of the Value field and MUST be 20.
o The Flags field currently defines one bit, the S-bit, that defines o The Flags field currently defines one bit, the S-bit, that defines
whether the current message has been processed by a 2-step node, whether the current message has been processed by a 2-step node,
where the flag is cleared if the message has been handled where the flag is cleared if the message has been handled
exclusively by 1-step nodes and there is no follow-up message, and exclusively by 1-step nodes and there is no follow-up message, and
set if there has been at least one 2-step node and a follow-up set if there has been at least one 2-step node and a follow-up
message is forthcoming. message is forthcoming.
o The PTPType indicates the type of PTP packet carried in the TLV. o The PTPType indicates the type of PTP packet carried in the TLV.
PTPType is the messageType field of the PTPv2 packet whose values PTPType is the messageType field of the PTPv2 packet whose values
are defined in the Table 19 [IEEE.1588.2008]. are defined in the Table 19 [IEEE.1588.2014].
o The 10 octets long Port ID field contains the identity of the o The 10 octets long Port ID field contains the identity of the
source port. source port.
o The Sequence ID is the sequence ID of the PTP message carried in o The Sequence ID is the sequence ID of the PTP message carried in
the Value field of the message. the Value field of the message.
4. Control Plane Theory of Operation 4. Control Plane Theory of Operation
The operation of RTM depends upon TTL expiry to deliver an RTM packet The operation of RTM depends upon TTL expiry to deliver an RTM packet
skipping to change at page 12, line 8 skipping to change at page 12, line 8
4.7. RTM_SET TLV 4.7. RTM_SET TLV
RTM capable interfaces can be recorded via RTM_SET TLV. The RTM_SET RTM capable interfaces can be recorded via RTM_SET TLV. The RTM_SET
sub-object format is of generic Type, Length, Value (TLV), presented sub-object format is of generic Type, Length, Value (TLV), presented
in Figure 6 . in Figure 6 .
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 | Reserved | | Type | Length |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RTM_SET TLV format Figure 6: RTM_SET TLV format
Type value (TBA5) will be assigned by IANA from its Attributes TLV Type value (TBA5) will be assigned by IANA from its Attributes TLV
Space sub-registry. Space sub-registry.
The Length contains the total length of the sub-object in bytes, The Length contains the total length of the sub-object in bytes,
including the Type and Length fields. including the Type and Length fields.
The I flag MUST be set to 0 if the node identified in the Value field
was able to find downstream RTM node and calculate distance to it.
If the node failed to find the downstream RTM node, then the I flag
MUST be set to 1.
Reserved field must be zeroed on initiation and ignored on receipt. Reserved field must be zeroed on initiation and ignored on receipt.
The content of an RTM_SET TLV is a series of variable-length sub- The content of an RTM_SET TLV is a series of variable-length sub-
TLVs. Only a single RTM_SET can be present in the LSP_ATTRIBUTES TLVs. Only a single RTM_SET can be present in the LSP_ATTRIBUTES
object. The sub-TLVs are defined in Section 4.7.1 below. object. The sub-TLVs are defined in Section 4.7.1 below.
The following processing procedures apply to every RTM capable node The following processing procedures apply to every RTM capable node
along the LSP that in this paragraph is referred as node for sake of along the LSP that in this paragraph is referred as node for sake of
brevity. Each node MUST examine Resv message whether RTM_SET brevity. Each node MUST examine Resv message whether RTM_SET
Attribute Flag in the LSP_ATTRIBUTES object is set. If the RTM_SET Attribute Flag in the LSP_ATTRIBUTES object is set. If the RTM_SET
skipping to change at page 12, line 49 skipping to change at page 13, line 5
been found the node will use the ID of the first node in the RTM_SET been found the node will use the ID of the first node in the RTM_SET
in conjunction with the RRO to compute the hop count to its in conjunction with the RRO to compute the hop count to its
downstream node with reachable RTM capable interface. If the node downstream node with reachable RTM capable interface. If the node
cannot find matching ID in RRO, then it MUST try to use ID of the cannot find matching ID in RRO, then it MUST try to use ID of the
next node in the RTM_SET until it finds the match or reaches the end next node in the RTM_SET until it finds the match or reaches the end
of RTM_SET TLV. If match have been found, then the calculated value of RTM_SET TLV. If match have been found, then the calculated value
is used by the node as TTL value in outgoing label to reach the next is used by the node as TTL value in outgoing label to reach the next
RTM capable node on the LSP. Otherwise, the TTL value MUST be set to RTM capable node on the LSP. Otherwise, the TTL value MUST be set to
255. The node MUST add RTM_SET sub-TLV with the same address it used 255. The node MUST add RTM_SET sub-TLV with the same address it used
in RRO sub-object at the beginning of the RTM_SET TLV in associated in RRO sub-object at the beginning of the RTM_SET TLV in associated
outgoing Resv message before forwarding it upstream. outgoing Resv message before forwarding it upstream. If the
calculated TTL value been set to 255, as described above, then the I
field in node RTM_SET TLV MUST be set to 1 before Resv message
forwarded upstream.
The ingress node MAY inspect values of I field in the received Resv
message that has RTM_SET Attribute Flag in the LSP_ATTRIBUTES object
set. Presence of the RTM_SET TLV with I field set to 1 indicates
that not all RTM nodes along the LSP could been included in the
calculation of the residence time. Re-signaling of the path MAY be
performed.
There are scenarios when some information is removed from an RRO due There are scenarios when some information is removed from an RRO due
to policy processing (e.g., as may happen between providers) or RRO to policy processing (e.g., as may happen between providers) or RRO
is limited due to size constraints . Such changes affect the core is limited due to size constraints . Such changes affect the core
assumption of the method to control processing of RTM packets. RTM assumption of the method to control processing of RTM packets. RTM
SHOULD NOT be used if it is not guaranteed that RRO contains complete SHOULD NOT be used if it is not guaranteed that RRO contains complete
information. information.
4.7.1. RTM_SET Sub-TLVs 4.7.1. RTM_SET Sub-TLVs
skipping to change at page 17, line 18 skipping to change at page 17, line 32
message will be forthcoming (this is necessary in order to message will be forthcoming (this is necessary in order to
Let any subsequent 2-step node know that there is already a Let any subsequent 2-step node know that there is already a
follow-up message, and follow-up message, and
Let the end-point know to wait for a follow-up message; Let the end-point know to wait for a follow-up message;
2. Create a follow-up message in which to put the RTM determined as 2. Create a follow-up message in which to put the RTM determined as
an initial correctionField value. an initial correctionField value.
IEEE 1588v2 [IEEE.1588.2008] defines this behavior for PTP messages. IEEE 1588v2 [IEEE.1588.2014] defines this behavior for PTP messages.
Thus, for example, with reference to the PTP protocol, the PTPType Thus, for example, with reference to the PTP protocol, the PTPType
field identifies whether the message is a Sync message, Follow_up field identifies whether the message is a Sync message, Follow_up
message, Delay_Req message, or Delay_Resp message. The 10 octet long message, Delay_Req message, or Delay_Resp message. The 10 octet long
Port ID field contains the identity of the source port, that is, the Port ID field contains the identity of the source port, that is, the
specific PTP port of the boundary clock connected to the MPLS specific PTP port of the boundary clock connected to the MPLS
network. The Sequence ID is the sequence ID of the PTP message network. The Sequence ID is the sequence ID of the PTP message
carried in the Value field of the message. carried in the Value field of the message.
PTP messages also include a bit that indicates whether or not a PTP messages also include a bit that indicates whether or not a
skipping to change at page 23, line 32 skipping to change at page 24, line 19
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-ospf-ospfv3-lsa-extend] [I-D.ietf-ospf-ospfv3-lsa-extend]
Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09
(work in progress), November 2015. (work in progress), November 2015.
[IEEE.1588.2008] [IEEE.1588.2014]
"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, March 2008. IEEE Standard 1588, August 2014.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <http://www.rfc-editor.org/info/rfc3209>.
 End of changes. 20 change blocks. 
25 lines changed or deleted 40 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/