draft-ietf-teas-te-metric-recording-01.txt   draft-ietf-teas-te-metric-recording-02.txt 
TEAS Working Group Zafar Ali TEAS Working Group Zafar Ali
Internet Draft George Swallow Internet Draft George Swallow
Intended status: Standard Track Clarence Filsfils Intended status: Standard Track Clarence Filsfils
Expires: December 7, 2015 Matt Hartley Expires: January 5, 2016 Matt Hartley
Cisco Systems Cisco Systems
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Ruediger Kunze Ruediger Kunze
Deutsche Telekom AG Deutsche Telekom AG
June 8, 2015 July 6, 2015
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
extension for recording TE Metric of a Label Switched Path extension for recording TE Metric of a Label Switched Path
draft-ietf-teas-te-metric-recording-01.txt draft-ietf-teas-te-metric-recording-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
This Internet-Draft will expire on December 7, 2015. This Internet-Draft will expire on January 5, 2016.
Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 2, line 5 skipping to change at page 2, line 34
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process, works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it except to format it for publication as an RFC or to translate it
into languages other than English. into languages other than English.
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt
Abstract Abstract
There are many scenarios in which Traffic Engineering (TE) metrics There are many scenarios in which Traffic Engineering (TE) metrics
such as cost, latency and latency variation associated with a such as cost, Delay and Delay variation associated with the TE link
Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched formed by Label Switched Path (LSP) are not available to the
Path (LSP) are not available to the ingress and egress nodes. This ingress and egress nodes. This draft provides extensions for the
draft provides extensions for the Resource ReserVation Protocol- Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) to
Traffic Engineering (RSVP-TE) for the support of the discovery of support automatic collection of cost, Delay and Delay variation
cost, latency and latency variation of an LSP. information for the TE link formed by a LSP.
Conventions used in this document Conventions used in this document
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 this document are to be interpreted as described in RFC 2119
[RFC2119]. [RFC2119].
Table of Contents Table of Contents
1. Introduction................................................3 Copyright Notice............................................1
2. RSVP-TE Requirement.........................................4 1. Introduction.............................................3
2.1. Cost, Latency and Latency Variation Collection Indication.4 1.1. Use Cases..............................................4
2.2. Cost, Latency and Latency Variation Collection............4 1.1.1. GMPLS..........................................4
2.3. Cost, Latency and Latency Variation Update................4 1.1.2. Inter-area tunnels with loose-hops.............4
3. RSVP-TE signaling extensions................................5 2. RSVP-TE Requirement......................................4
3.1. Cost, Latency, and Latency Variation Collection Flags.....5 2.1. Cost, Delay and Delay Variation Collection Indication..4
3.4. Cost subobject............................................5 2.2. Cost, Delay and Delay Variation Collection.............4
3.5. Latency subobject.........................................6 2.3. Cost, Delay and Delay Variation Update.................5
3.6. Latency Variation subobject...............................7 2.4. Cost Definition........................................5
3.7. Signaling Procedures......................................8 3. RSVP-TE signaling extensions.............................5
4. Security Considerations....................................12 Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
5. IANA Considerations........................................12
5.1. RSVP Attribute Bit Flags.................................12
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt
5.2. New RSVP error sub-code..................................13 3.1. Cost, Delay and Delay Variation Collection Flags.......5
6. Acknowledgments............................................14 3.2. Cost Subobject.........................................6
7. References.................................................14 3.3. Delay Subobject........................................6
7.1. Normative References.....................................14 3.4. Delay Variation Subobject..............................7
7.2. Informative References...................................14 4. Signaling Procedures.....................................8
4.1. Cost, Delay and Delay Variation Collection Request.....8
4.2. Cost, Delay and Delay Variation Recoding...............8
4.3. Metric Update..........................................10
4.4. Compatibility..........................................10
5. Endpoint processing......................................11
6. Manageability Considerations.............................11
6.1. Policy Configuration...................................11
7. Security Considerations..................................12
8. IANA Considerations......................................12
8.1. RSVP Attribute Bit Flags...............................12
8.2. Policy Control Failure Error subcodes..................13
9. Acknowledgments..........................................13
10. References..............................................14
10.1. Normative References..................................14
10.2. Informative References................................14
1. Introduction 1. Introduction
In certain networks, such as financial information networks, In certain networks, such as financial information networks,
network performance information (e.g. latency, latency network performance information (e.g. Delay, Delay variation) is
variation) is becoming as critical to data path selection as becoming as critical to data path selection as other metrics RFC
other metrics [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. If 7471 [RFC7471], [DRAFT-ISIS-TE-METRIC]. If cost, Delay or Delay
cost, latency or latency variation associated with a Forwarding variation associated with a Forwarding Adjacency (FA) or a
Adjacency (FA) or a Routing Adjacency (RA) LSP is not available Routing Adjacency (RA) LSP is not available to the ingress or
to the ingress or egress node, it cannot be advertised as an egress node, it cannot be advertised as an attribute of the TE
attribute of the FA or RA. There are scenarios in packet and link (FA or RA). There are scenarios in packet and optical
optical networks where the route information of an LSP may not networks where the route information of an LSP may not be
be provided to the ingress node for confidentiality reasons provided to the ingress node for confidentiality reasons and/or
and/or the ingress node may not run the same routing instance as the ingress node may not run the same routing instance as the
the intermediate nodes traversed by the path. In such scenarios, intermediate nodes traversed by the path. Similarly, there are
the ingress node cannot determine the cost, latency and latency scenarios in which measuring Delay and/ or Delay variation on a
TE link formed by a LSP is not supported. In such scenarios, the
ingress node cannot determine the cost, Delay and Delay
variation properties of the LSP's route. variation properties of the LSP's route.
One possible way to address this issue is to configure cost, One possible way to address this issue is to configure cost,
latency and latency variation values manually. However, in the Delay and Delay variation values manually. However, in the event
event of an LSP being rerouted (e.g. due to re-optimization), of an LSP being rerouted (e.g. due to re-optimization), such
such configuration information may become invalid. Consequently, configuration information may become invalid. Consequently, in
in cases where that an LSP is advertised as a TE-Link, the cases where that an LSP is advertised as a TE-Link, the ingress
ingress and/or egress nodes cannot provide the correct latency, and/or egress nodes cannot provide the correct Delay, Delay
latency variation and cost attribute associated with the TE-Link variation and cost information associated with the TE-Link
automatically. automatically.
In summary, there is a requirement for the ingress and egress In summary, there is a requirement for the ingress and egress
nodes to learn the cost, latency and latency variation nodes to learn the cost, Delay and Delay variation information
attributes of an FA or RA LSP. This draft provides extensions to of the TE link formed by a LSP. This document provides a
the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) mechanism to collect the cost, Delay and Delay variation
for the support of the automatic discovery of these attributes. information of a LSP, which can then be advertised as properties
of the TE-link formed by that LSP. Note that specification of
Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
the use of the collected cost, Delay and Delay variation
information is outside the scope of this document.
1.1. Use Cases 1.1. Use Cases
This section describes some of the use cases for TE metric
recording.
1.1.1. GMPLS 1.1.1. GMPLS
In Generalized Multi-Protocol Label Switching (GMPLS) networks In Generalized Multi-Protocol Label Switching (GMPLS) networks
signaling bidirectional LSPs, the egress node cannot determine signaling bidirectional LSPs, the egress node cannot determine
the cost, latency and latency variation properties of the LSP the cost, Delay and Delay variation properties of the LSP path.
path. A multi-domain or multi-layer network is an example of A multi-domain or multi-layer network is an example of such
such networks. A GMPLS User-Network Interface (UNI) [RFC4208] is networks. A GMPLS User-Network Interface (UNI) [RFC4208] is also
also an example of such networks. an example of such networks.
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt
1.1.2. Inter-area tunnels with loose-hops 1.1.2. Inter-area tunnels with loose-hops
When a LSP is established over multiple IGP-areas using loose When a LSP is established over multiple IGP-areas using loose
hops in the ERO, the ingress node only has knowledge of the hops in the ERO, the ingress node only has knowledge of the
first IGP-area traversed by the LSP. In this case, it cannot first IGP-area traversed by the LSP. In this case, it cannot
determine the cost, latency and latency variation properties of determine the cost, Delay and Delay variation properties of the
the LSP path. LSP path.
2. RSVP-TE Requirements 2. RSVP-TE Requirement
This section outlines RSVP-TE requirements for the support of This section outlines RSVP-TE requirements for the support of
the automatic discovery of cost, latency and latency variation the automatic discovery of cost, Delay and Delay variation
attributes of an LSP. These requirements are very similar to the information of an LSP.
requirement of discovering the Shared Risk Link Groups (SRLGs)
associated with the route taken by an LSP [DRAFT-SRLG-
RECORDING].
2.1. Cost, Latency and Latency Variation Collection Indication 2.1. Cost, Delay and Delay Variation Collection Indication
The ingress node of the LSP must be capable of indicating The ingress node of the LSP SHOULD be capable of indicating
whether the cost, latency and latency variation attributes of whether the cost and/or delay and/ or delay variation
the LSP should be collected during the signaling procedure of information of the LSP is to be collected during the signaling
setting up the LSP. No cost, latency or latency variation procedure of setting up an LSP. A separate collection indication
information is collected without an explicit request being made flag for each of this attribute is required. Cost, delay and
by the ingress node. delay variation information SHOULD NOT be collected without an
explicit request for it being made by the ingress node.
2.2. Cost, Latency and Latency Variation Collection 2.2. Cost, Delay and Delay Variation Collection
If requested, cost, latency and latency variation is If requested, the cost and/or delay and/ or delay variation
collected during the setup of an LSP. The endpoints of the LSP information SHOULD be collected during the setup of an LSP. Each
may use the collected information for routing, flooding and TE of the cost, delay or delay variation can be collected
link configuration and other purposes. independently. The endpoints of the LSP can use the collected
information, for example, for routing, flooding and other
purposes.
2.3. Cost, Latency and Latency Variation Update Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
When the cost, latency or latency variation property of a TE 2.3. Cost, Delay and Delay Variation Update
link along the route of a LSP for which that property was
collected changes (e.g., if the administrator changes the cost When the cost and/or delay and/ or delay variation information
of a TE link traversed by the LSP), the node where the change of an existing LSP for which corresponding information was
occurred needs to be capable of updating the cost, latency and collected during signaling changes, the relevant nodes of the
latency variation information of the path and signaling this to LSP SHOULD be capable of updating the associated information of
the end-points. Similarly, if a path segment of the LSP is the LSP. This means that the signaling procedure SHOULD be
rerouted, the endpoints of the re-routed segment need to be capable of updating the new cost and/or delay and/ or delay
capable of updating the cost, latency and latency variation variation information.
information of the path. Any node which adds cost, latency or
latency variation information to an LSP during initial setup,
needs to signal changes to these values to both endpoints.
2.4. Cost Definition 2.4. Cost Definition
Although the terms latency and latency variation are well Although the terms Delay and Delay variation are well
understood, "cost" may be ambiguous; in particular, in the understood, "cost" may be ambiguous; in particular, in the
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt
context of a LSP that traverses nodes and links operated by context of a LSP that traverses nodes and links operated by
different entities, there may be no common definition of cost. different entities, there may be no common definition of cost.
However, there are situations in which the entire LSP may be However, there are situations in which the entire LSP may be
within a single AS (e.g. inter-area LSPs) in which cost within a single AS (e.g. inter-area LSPs) in which cost
discovery is useful. discovery is useful.
The precise meaning and interpretation of numerical costs is a The precise meaning and interpretation of numerical costs is a
matter for the network operator. For the purposes of this matter for the network operator. For the purposes of this
document, two constraints are assumed: document, two constraints are assumed:
. A higher cost represents an inferior path . A higher cost represents an inferior path.
. Simple addition of costs for different sections of a path . Simple addition of costs for different sections of a path
must make sense. must make sense.
3. RSVP-TE signaling extensions 3. RSVP-TE signaling extensions
3.1. Cost, Latency and Latency Variation Collection Flags 3.1. Cost, Delay and Delay Variation Collection Flags
In order to indicate nodes that cost, latency and/ or latency In order to indicate nodes that cost and/or Delay and/ or Delay
variation collection is desired, the following three Attribute variation collection is desired, this document defines a new
flags are defined in the Attribute Flags TLV: flags in the Attribute Flags TLV (see RFC 5420 [RFC5420]), which
MAY be carried in an LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES
Object:
- Cost Collection flag (to be assigned by IANA) - Cost Collection flag (Bit number to be assigned by IANA)
- Latency Collection flag (to be assigned by IANA) - Delay Collection flag (Bit number to be assigned by IANA)
- Latency Variation Collection flag (to be assigned by IANA) - Delay Variation Collection flag (Bit number to be assigned by
IANA)
These flags are set and carried in either the LSP_ATTRIBUTES or The Cost, Delay and Delay Variation Collection flag is
LSP_REQUIRED_ATTRIBUTES Objects in a Path message. meaningful on a Path message. If the Cost Collection flag is
set to 1, it means that the cost information SHOULD be reported
to the ingress and egress node along the setup of the LSP.
Similarly, if the Delay Collection flag is set to 1, it means
that the Delay information SHOULD be reported to the ingress and
Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
egress node along the setup of the LSP. Likewise, if the Delay
Variation Collection flag is set to 1, it means that the Delay
Variation information SHOULD be reported to the ingress and
egress node along the setup of the LSP.
The rules of the processing of the Attribute Flags TLV are not
changed.
3.2. Cost Subobject 3.2. Cost Subobject
The Cost subobject is a new RRO (ROUTE_RECORD OBJECT) sub-object This document defines a new RRO sub-object (ROUTE_RECORD sub-
used to record the cost information of the LSP. Its format is object) to record the cost information of the LSP. Its format
similar to the other RRO subobjects defined in [RFC3209]. is modeled on the RRO sub-objects defined in RFC 3209 [RFC3209].
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 (must be zero) | | Type | Length | Reserved (must be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Cost | | Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBA1 - Cost subobject (to be assigned by IANA). Type: The type of the sub-object (value to be assigned by
IANA).
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt
Length: The Length value is set to 8 or 12 depending on the Length: The Length field contains the total length of the
presence of Upstream Cost information. It MUST NOT be set to sub-object in bytes, including the Type and Length fields.
any other value. The Length value is set to 8.
Reserved: This field is reserved for future use. It MUST be Reserved: This field is reserved for future use. It MUST be
set to 0 on transmission and MUST be ignored when received. set to 0 on transmission and MUST be ignored when received.
Downstream Cost: Cost of the local link along the route of Cost: Cost of the local TE link along the route of the LSP.
the LSP in the direction of the tail-end node, encoded as a
32-bit integer. This approach has been taken to avoid
defining a flag for each cost type in the Attribute-Flags
TLV.
Upstream Cost: Cost of the local link along the route of the
LSP in the direction of the head-end node, encoded as a 32-
bit integer.
3.3. Latency Subobject 3.3. Delay Subobject
The Latency subobject is a new RRO sub-object to record the This document defines a new RRO sub-object (ROUTE_RECORD sub-
latency information of the LSP. Its format is similar the other object) to record the delay information of the LSP. Its format
RRO subobjects defined in [RFC3209]. is modeled on the RRO sub-objects defined in RFC 3209 [RFC3209].
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 (must be zero) | | Type | Length | Reserved (must be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Downstream Delay | |A| Reserved | Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Upstream Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
Type: TBA2 - Latency subobject (to be assigned by IANA). Type: The type of the sub-object (value to be assigned by
IANA).
Length: 8 or 12 depending on the presence of Upstream Delay Length: The Length field contains the total length of the
information. sub-object in bytes, including the Type and Length fields.
The Length value is set to 8.
A-bit: These fields represent the Anomalous (A) bit A-bit: These fields represent the Anomalous (A) bit
associated with the Downstream and Upstream Delay associated with the Downstream and Upstream Delay
respectively, as defined in [DRAFT-OSPF-TE-METRIC]. respectively, as defined in RFC 7471 [RFC7471].
Reserved: These fields are reserved for future use. They MUST Reserved: These fields are reserved for future use. They MUST
be set to 0 when sent and MUST be ignored when received. be set to 0 when sent and MUST be ignored when received.
Downstream Delay: Delay of the local link along the route of Delay: Delay of the local TE link along the route of the LSP,
the LSP in the direction of the tail-end node, encoded as 24- encoded as 24-bit integer, as defined in RFC 7471 [RFC7471].
bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set When set to the maximum value 16,777,215 (16.777215 sec), the
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt delay is at least that value and may be larger.
to the maximum value 16,777,215 (16.777215 sec), the delay is
at least that value and may be larger.
Upstream Delay: Delay of the local link along the route of
the LSP in the direction of the head-end node, encoded as 24-
bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set
to the maximum value 16,777,215 (16.777215 sec), the delay is
at least that value and may be larger.
3.4. Latency Variation Subobject 3.4. Delay Variation Subobject
The Latency Variation subobject is a new RRO sub-object to This document defines a new RRO sub-object (ROUTE_RECORD sub-
record the Latency Variation information of the LSP. Its format object) to record the delay variation information of the LSP.
is similar to the other RRO subobjects defined in [RFC3209]. Its format is modeled on the RRO sub-objects defined in RFC 3209
[RFC3209].
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 (must be zero) | | Type | Length | Reserved (must be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Downstream Delay Variation | |A| Reserved | Delay Variation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Upstream Delay Variation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBA3 - Latency Variation subobject (to be assigned by Type: The type of the sub-object (value to be assigned by
IANA). IANA).
Length: 8 or 12 depending on the presence of Upstream Latency Length: The Length field contains the total length of the
Variation information. sub-object in bytes, including the Type and Length fields.
The Length value is set to 8.
A-bit: These fields represent the Anomalous (A) bit A-bit: These fields represent the Anomalous (A) bit
associated with the Downstream and Upstream Delay Variation associated with the Downstream and Upstream Delay Variation
respectively, as defined in [DRAFT-OSPF-TE-METRIC]. respectively, as defined in RFC 7471 [RFC7471].
Reserved: These fields are reserved for future use. It SHOULD Reserved: These fields are reserved for future use. It SHOULD
be set to 0 when sent and MUST be ignored when received. be set to 0 when sent and MUST be ignored when received.
Downstream Delay Variation: Delay Variation of the local link Delay Variation: Delay Variation of the local TE link along
along the route of the LSP in the direction of the tail-end the route of the LSP, encoded as 24-bit integer, as defined
node, encoded as 24-bit integer, as defined in [DRAFT-OSPF- in RFC 7471 [RFC7471]. When set to the maximum value
TE-METRIC]. When set to the maximum value 16,777,215 Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
(16.777215 sec), the delay is at least that value and may be
larger.
Upstream Delay Variation: Delay Variation of the local link
along the route of the LSP in the direction of the head-end
node, encoded as 24-bit integer. When set to 0, it has not
been measured. When set to the maximum value 16,777,215
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt
(16.777215 sec), the delay is at least that value and may be 16,777,215 (16.777215 sec), the delay variation is at least
larger. that value and may be larger.
4. Signaling Procedures 4. Signaling Procedures
The rules for processing the LSP_ATTRIBUTES and The rules of the processing of the LSP_REQUIRED_ATTRIBUTES,
LSP_REQUIRED_ATTRIBUTES Objects and RRO defined in [RFC5420] are LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed.
not changed.
4.1. Collection request
Typically, the ingress node learns the route of an LSP by adding
a RRO in the Path message. If an ingress node also desires cost,
latency and/or latency variation recording, it MUST set the
appropriate flag(s) in the Attribute Flags TLV of the
LSP_ATTRIBUTES (if recording is desired but not mandatory) or
LSP_REQUIRED_ATTRIBUTES (if recording in mandatory) Object.
None, all or any of the Cost Collection, Latency Collection or
Latency Variation Collection flags MAY be set in the Attribute
Flags TLV of the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES
Object. These flags affect both Path and Resv RRO processing, as
described below.
The Cost Collection, Latency Collection or Latency Variation
Collection flags SHOULD NOT be set in an Attribute Flags TLV in
a Resv message. If any of these flags is set in a received
Attribute Flags TLV in a Resv message, it MUST be ignored.
The Cost Collection, Latency Collection or Latency Variation
Collection flags SHOULD NOT be set in an Attribute Flags TLV in
a RRO. If any of these flags is set in a received Attribute
Flags TLV in a RRO, it MUST be ignored.
4.2. Path and Resv message processing
4.2.1. Cost
If a node receives a Path message containing a
LSP_REQUIRED_ATTRIBUTES Object with the Cost Collection Flag set
in the Attribute Flags TLV:
. If local policy disallows providing the requested
information to the endpoints, the node MUST return a Path
Error message with error code "Policy Control Failure" (2)
and subcode "Cost Recording Rejected" (value to be assigned
by IANA, suggested value 105).
. It SHOULD add a Cost subobject to the Path and Resv RROs
for the LSP. It SHOULD supply only downstream information
for a unidirectional LSP, and SHOULD provide both upstream
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt
and downstream information if a bidirectional LSP is being
signaled.
. If Cost information is not known, a Cost subobject SHOULD
NOT be added to either the Path or Resv RRO.
If a node receives a Path message containing a LSP_ATTRIBUTES
Object with the Cost Collection Flag set in the Attribute Flags
TLV:
. If local policy disallows providing the requested
information to the endpoints, the Path message SHOULD NOT
be rejected. A Cost subobject is not added to the Path or
Resv RRO.
. If local policy permits, it SHOULD add a Cost subobject to
the Path and Resv RROs for the LSP. It SHOULD supply only
downstream information for a unidirectional LSP, and SHOULD
provide both upstream and downstream information if a
bidirectional LSP is being signaled.
. If Cost information is not known, a Cost subobject SHOULD
NOT be added to either the Path or Resv RRO.
When adding a Cost subobject to a Path or Resv RRO:
. The Downstream Cost is set to the cost of the local link
used by the LSP in the direction of the egress node. It
SHOULD be set to zero by the egress node.
. The Upstream Cost, if set, is set to the cost of the local
link used by the LSP in the direction of the ingress node.
It SHOULD be set to zero by the ingress node.
. The cost of a local link is the Interior Gateway Protocol
(IGP) metric or TE metric of the link in question,
depending on the policy of the processing node.
4.2.2. Latency
If a node receives a Path message containing a
LSP_REQUIRED_ATTRIBUTES Object with the Latency Collection Flag
set in the Attribute Flags TLV:
. If local policy disallows providing the requested
information to the endpoints, the node MUST return a Path
Error message with error code "Policy Control Failure" (2)
and subcode "Latency Recording Rejected" (value to be
assigned by IANA, suggested value 106).
. It SHOULD add a Latency subobject to the Path and Resv
RROs for the LSP. It SHOULD supply only downstream
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt
information for a unidirectional LSP, and SHOULD provide
both upstream and downstream information if a bidirectional
LSP is being signaled.
. If Latency information is not known, a Latency subobject
SHOULD NOT be added to either the Path or Resv RRO.
If a node receives a Path message containing a LSP_ATTRIBUTES
Object with the Latency Collection Flag set in the Attribute
Flags TLV:
. If local policy disallows providing the requested
information to the endpoints, the Path message SHOULD NOT
be rejected. A Latency subobject is not added to the Path
or Resv RRO.
. If local policy permits, it SHOULD add a Latency subobject As signaling procedure for cost, delay and delay variation
to the Path and Resv RROs for the LSP. It SHOULD supply collection is similar, many parts of this section are written
only downstream information for a unidirectional LSP, and such that they apply equally to cost, delay and delay variation
SHOULD provide both upstream and downstream information if collection. There is also very strong similarity of these
a bidirectional LSP is being signaled. procedures with SRLG recording [DRAFT-SRLG-RECORDING].
. If Latency information is not known, a Latency subobject 4.1. Cost, Delay and Delay Variation Collection Request
SHOULD NOT be added to either the Path or Resv RRO.
When adding a Latency subobject to a Path or Resv RRO: Per RFC 3209 [RFC3209], an ingress node initiates the recording
of the route information of an LSP by adding a RRO to a Path
message. If an ingress node also desires Cost and/or Delay
and/or Delay Variation recording, it MUST set the appropriate
flag(s) in the Attribute Flags TLV which MAY be carried either
in an LSP_REQUIRED_ATTRIBUTES Object when the collection is
mandatory, or in an LSP_ATTRIBUTES Object when the collection is
desired, but not mandatory.
. The Downstream Delay is set to the delay of the local link 4.2. Cost, Delay and Delay Variation Recoding
used by the LSP in the direction of the egress node. It
SHOULD be set to zero by the egress node.
. The Upstream Delay, if set, is set to the delay of the When a node receives a Path message which carries an
local link used by the LSP in the direction of the ingress LSP_REQUIRED_ATTRIBUTES Object and the Cost Collection Flag set,
node. It SHOULD be set to zero by the ingress node. if local policy determines that the cost information is not to
be provided to the endpoints or the information is not known, it
MUST return a PathErr message with error code 2 (policy) and
error subcode "Cost Recording Rejected" (value to be assigned by
IANA) to reject the Path message. Similarly, when a node
receives a Path message which carries an LSP_REQUIRED_ATTRIBUTES
Object and the Delay Collection Flag set, if local policy
determines that the Delay information is not to be provided to
the endpoints or the information is not known, it MUST return a
PathErr message with error code 2 (policy) and error subcode
"Delay Recording Rejected" (value to be assigned by IANA) to
reject the Path message. Likewise, when a node receives a Path
message which carries an LSP_REQUIRED_ATTRIBUTES Object and the
Delay Variation Collection Flag set, if local policy determines
that the Delay Variation information is not to be provided to
the endpoints or the information is not known, it MUST return a
PathErr message with error code 2 (policy) and error subcode
"Delay Variation Recording Rejected" (value to be assigned by
IANA) to reject the Path message.
. The A-bit for the downstream and upstream latency SHOULD When a node receives a Path message which carries an
be set as described in [DRAFT-OSPF-TE-METRIC]. LSP_ATTRIBUTES Object and the Cost and/or Delay and/or Delay
Variation Collection Flag set, if local policy determines that
Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
4.2.3. Latency Variation the corresponding information is not to be provided to the
endpoints, or the information is not known, the Path message
SHOULD NOT be rejected due to the recording restriction and the
Path message SHOULD be forwarded without any Cost and/or Delay
and/or Delay Variation sub-object(s) in the RRO of the
corresponding outgoing Path message.
If a node receives a Path message containing a If local policy permits the recording of the Cost and/or Delay
LSP_REQUIRED_ATTRIBUTES Object with the Latency Variation and/or Delay Variation information, the processing node SHOULD
Collection Flag set in the Attribute Flags TLV: add corresponding information for the local TE link, as defined
below, to the RRO of the corresponding outgoing Path message.
The A-bit for the Delay MUST be set as described in RFC 7471
[RFC7471]. Similarly, the A-bit for the Delay Variation MUST be
set as described in RFC 7471 [RFC7471]. It then forwards the
Path message to the next node in the downstream direction.
. If local policy disallows providing the requested If the addition of Cost and/or Delay and/or Delay Variation
information to the endpoints, the node MUST return a Path information to the RRO would result in the RRO exceeding its
Error message with error code "Policy Control Failure" (2) maximum possible size or becoming too large for the Path message
and subcode "Latency Variation Recording Rejected" (value to contain it, the requested information MUST NOT be added. If
to be assigned by IANA, suggested value 107). the Cost and/or Delay and/or Delay Variation collection request
was contained in an LSP_REQUIRED_ATTRIBUTES Object, the
processing node MUST behave as specified by RFC 3209 [RFC3209]
and drop the RRO from the Path message entirely. If the Cost
and/or Delay and/or Delay Variation collection request was
contained in an LSP_ATTRIBUTES Object, the processing node MAY
omit some or all of the corresponding information from the RRO;
otherwise it MUST behave as specified by RFC 3209 [RFC3209] and
drop the RRO from the Path message entirely.
. It SHOULD add a Latency Variation subobject to the Path Following the steps described above, the intermediate nodes of
and Resv RROs for the LSP. It SHOULD supply only downstream the LSP can collect the Cost and/or Delay and/or Delay Variation
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt information in the RRO during the processing of the Path message
hop by hop. When the Path message arrives at the egress node,
the egress node receives the corresponding information in the
RRO.
information for a unidirectional LSP, and SHOULD provide Per RFC 3209 [RFC3209], when issuing a Resv message for a Path
both upstream and downstream information if a bidirectional message, which contains an RRO, an egress node initiates the RRO
LSP is being signaled. process by adding an RRO to the outgoing Resv message. The
processing for RROs contained in Resv messages then mirrors that
of the Path messages.
. If Latency Variation information is not known, a Latency When a node receives a Resv message for an LSP for which Cost
subobject SHOULD NOT be added to either the Path or Resv and/or Delay and/or Delay Variation Collection is requested,
RRO. then when local policy allows recording of the requested
information, the node SHOULD add corresponding information, to
the RRO of the outgoing Resv message, as specified below. The
A-bit for the Delay MUST be set as described in RFC 7471
[RFC7471]. Similarly, the A-bit for the Delay Variation MUST be
set as described in RFC 7471 [RFC7471]. When the Resv message
arrives at the ingress node, the ingress node can extract the
Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
If a node receives a Path message containing a LSP_ATTRIBUTES requested information from the RRO in the same way as the egress
Object with the Latency Variation Collection Flag set in the node.
Attribute Flags TLV:
. If local policy disallows providing the requested A node MUST NOT push a Cost, Delay or Delay Variation sub-object
information to the endpoints, the Path message SHOULD NOT in the RECORD_ROUTE without also pushing an IPv4 sub-object, an
be rejected. A Latency Variation subobject is not added to IPv6 sub-object, an Unnumbered Interface ID sub-object or a Path
the Path or Resv RRO. Key sub-object.
. If local policy permits, it SHOULD add a Latency Variation Note that a link's Cost and/or Delay and/or Delay Variation
subobject to the Path and Resv RROs for the LSP. It SHOULD information for the upstream direction cannot be assumed to be
supply only downstream information for a unidirectional the same as that in the downstream.
LSP, and SHOULD provide both upstream and downstream
information if a bidirectional LSP is being signaled.
. If Latency Variation information is not known, a Latency . For Path and Resv messages for a unidirectional LSP, a node
subobject SHOULD NOT be added to either the Path or Resv SHOULD include Cost and/or Delay and/or Delay Variation sub-
RRO. objects in the RRO for the downstream data link only.
When adding a Latency Variation subobject to a Path or Resv RRO: . For Path and Resv messages for a bidirectional LSP, a node
SHOULD include Cost and/or Delay and/or Delay Variation sub-
objects in the RRO for both the upstream data link and the
downstream data link from the local node. In this case, the
node MUST include the information in the same order for both
Path messages and Resv messages. That is, the Cost and/or
Delay and/or Delay Variation sub- object for the upstream link
is added to the RRO before the corresponding sub-object for
the downstream link.
. The Downstream Latency Variation is set to the latency of 4.3. Metric Update
the local link used by the LSP in the direction of the
egress node. It SHOULD be set to zero by the egress node.
. The Upstream Latency Variation, if set, is set to the When the Cost and/or Delay and/or Delay Variation information of
latency of the local link used by the LSP in the direction a link is changed, the LSPs using that link need to be aware of
of the ingress node. It SHOULD be set to zero by the egress the changes. The procedures defined in Section 4.4.3 of RFC
node. 3209 [RFC3209] MUST be used to refresh the Cost and/or Delay
and/or Delay Variation information if the corresponding change
is to be communicated to other nodes according to the local
node's policy. If local policy is that the Cost and/or Delay
and/or Delay Variation change SHOULD be suppressed or would
result in no change to the previously signaled information, the
node SHOULD NOT send an update.
. The A-bit for the downstream and upstream latency SHOULD 4.4. Compatibility
be set as described in [DRAFT-OSPF-TE-METRIC].
4.3. Metric Update A node that does not recognize the Cost and/or Delay and/or
Delay Variation Collection Flag in the Attribute Flags TLV is
expected to proceed as specified in RFC 5420 [RFC5420]. It is
expected to pass the TLV on unaltered if it appears in a
LSP_ATTRIBUTES object, or reject the Path message with the
appropriate Error Code and Value if it appears in a
LSP_REQUIRED_ATTRIBUTES object.
When the cost, latency and/or latency variation information of a Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
link is changed, the corresponding metric values for the LSPs
using that link should also be updated. If node has added Cost,
Latency and/or Latency Variation subobjects to the Path or Resv
RRO, the procedures defined in Section 4.4.3 of RFC 3209
[RFC3209] MUST be used to communicate any changes to relevant
information to the other nodes on the LSP's path. The node need
not send an update for changes to information which has not been
added to the RRO.
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt A node that does not recognize the Cost and/or Delay and/or
Delay Variation RRO sub-object is expected to behave as
specified in RFC 3209 [RFC3209]: unrecognized subobjects are to
be ignored and passed on unchanged.
5. Endpoint processing 5. Endpoint processing
Based on the procedures mentioned in Section 4, the endpoints
can get the Cost and/or Delay and/or Delay Variation information
automatically. Then the endpoints can for instance advertise it
as a TE link to the routing instance based on the procedure
described in [RFC6107]. How the end point uses the collected
information is outside the scope of this document.
The ingress and egress nodes of a LSP may calculate the end-to- The ingress and egress nodes of a LSP may calculate the end-to-
end cost, latency and/or latency variation properties of the LSP end cost, Delay and/or Delay variation properties of the LSP
from the supplied values in the Resv or Path RRO respectively. from the supplied values in the Resv or Path RRO respectively.
Typically, cost and latency are additive metrics, but latency Typically, cost and Delay are additive metrics, but Delay
variation is not an additive metric. The means by which the variation is not an additive metric. The means by which the
ingress and egress nodes compute the end-to-end cost, latency ingress and egress nodes compute the end-to-end cost, Delay and
and latency variation metric from information recorded in the Delay variation metric from information recorded in the RRO is a
RRO is a local decision and is beyond the scope of this local decision and is beyond the scope of this document.
document.
Based on the local policy, the ingress and egress nodes can Based on the local policy, the ingress and egress nodes can
advertise the calculated end-to-end cost, latency and/or latency advertise the calculated end-to-end cost, Delay and/or Delay
variation properties of the FA or RA LSP in TE link variation properties of the FA or RA LSP in TE link
advertisement to the routing instance based on the procedure advertisement to the routing instance based on the procedure
described in [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. described in RFC 7471 [RFC7471], [DRAFT-ISIS-TE-METRIC].
Based on the local policy, a transit node (e.g. the edge node of Based on the local policy, a transit node (e.g. the edge node of
a domain) may edit a Path or Resv RRO to remove route a domain) may edit a Path or Resv RRO to remove route
information (e.g. node or interface identifier information) information (e.g. node or interface identifier information)
before forwarding it. A node that does this SHOULD summarize the before forwarding it. A node that does this SHOULD summarize the
cost, latency and latency variation data and SHOULD follow cost, Delay and Delay Variation data. How a node that performs
procedure defined in [DRAFT-RRO-EDIT]. How a node that performs the RRO edit operation calculates the cost, Delay o and/or Delay
the RRO edit operation calculates the cost, latency o and/or variation metric is beyond the scope of this document.
latency variation metric is beyond the scope of this document.
6. Security Considerations
This document does not introduce any additional security issues 6. Manageability Considerations
above those identified in [RFC5920], [RFC5420], [RFC2205],
[RFC3209], and [RFC3473].
7. IANA Considerations 6.1. Policy Configuration
7.1. RSVP Attribute Bit Flags In a border node of inter-domain or inter-layer network, the
following Cost and/or Delay and/or Delay Variation processing
policy SHOULD be capable of being configured:
The IANA has created a registry and manages the space of Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
attributes bit flags of Attribute Flags TLV as described in
section 11.3 of [RFC5420]. It is requested that the IANA makes
assignments from the Attribute Bit Flags defined in this
document.
This document introduces the following three new Attribute o Whether the Cost and/or Delay and/or Delay Variation of the
Bit Flag: domain or specific layer network can be exposed to the nodes
outside the domain or layer network, or whether they SHOULD be
summarized, mapped to values that are comprehensible to nodes
outside the domain or layer network, or removed entirely.
- Bit number: TBD (recommended bit position 11) A node using RFC 5553 [RFC5553] and PKS MAY apply the same
policy.
- Defining RFC: this I-D 7. Security Considerations
- Name of bit: Cost Collection Flag This document builds on the mechanisms defined in [RFC3473],
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt which also discusses related security measures. In addition,
[RFC5920] provides an overview of security vulnerabilities and
protection mechanisms for the GMPLS control plane. The
procedures defined in this document permit the transfer of Cost
and/or Delay and/or Delay Variation data between layers or
domains during the signaling of LSPs, subject to policy at the
layer or domain boundary. It is recommended that domain/layer
boundary policies take the implications of releasing Cost and/or
Delay and/or Delay Variation information into consideration and
behave accordingly during LSP signaling.
- Bit number: TBD (recommended bit position 12) 8. IANA Considerations
- Defining RFC: this I-D 8.1. RSVP Attribute Bit Flags
- Name of bit: Latency Collection Flag IANA has created a registry and manages the space of the
Attribute bit flags of the Attribute Flags TLV, as described in
section 11.3 of RFC 5420 [RFC5420], in the "Attribute Flags"
section of the "Resource Reservation Protocol-Traffic
Engineering (RSVP-TE) Parameters" registry located in
http://www.iana.org/assignments/rsvp-te- parameters".
- Bit number: TBD (recommended bit position 13) This document introduces the following three new Attribute Bit
Flags:
- Defining RFC: this I-D Bit No Name Attribute Attribute RRO Reference
- Name of bit: Latency Variation Flag Flags Path Flags Resv
5.2. ROUTE_RECORD subobject ----------- ---------- ---------- ----------- --- -------
This document introduces the following three new RRO TBA by Cost Yes Yes Yes This I-D
subobject: IANA Collection
Flag
Type Name Reference TBA by Delay Yes Yes Yes This I-D
IANA Collection
Flag
Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
--------- ---------------------- --------- TBA by Delay Yes Yes Yes This I-D
IANA Variation
Collection
Flag
TBD (35) Cost subobject This I-D 5.2. ROUTE_RECORD subobject
TBD (36) Latency subobject This I-D IANA manages the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters. This document
introduces the following three new RRO subobject:
TBD (37) Latency Variation subobject This I-D Type Name Reference
7.2. New RSVP error sub-code --------- ---------------------- ---------
For Error Code = 2 "Policy Control Failure" (see [RFC2205]) the TBA by IANA Cost subobject This I-D
following sub-code is defined.
Sub-code Value TBA by IANA Delay subobject This I-D
-------- -----
Cost Recoding Rejected To be assigned by IANA. TBA by IANA Delay Variation subobject This I-D
Suggested Value: 105.
Latency Recoding Rejected To be assigned by IANA. 8.2. Policy Control Failure Error subcodes
Suggested Value: 106.
Latency Variation Recoding Rejected To be assigned by IANA. IANA manages the assignments in the "Error Codes and Globally-
Suggested Value: 107. Defined Error Value Sub-Codes" section of the "RSVP PARAMETERS"
registry located at http://www.iana.org/assignments/rsvp-
parameters. This document introduces the following three new
Policy Control Failure Error sub-code:
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt Value Description Reference
----- ----------- ---------
TBA by IANA Cost Recoding Rejected This I-D
TBA by IANA Delay Recoding Rejected This I-D
TBA by IANA Delay Variation Recoding Rejected This I-D
8. Acknowledgments 9. Acknowledgments
Authors would like to thank Ori Gerstel, Gabriele Maria Authors would like to thank Ori Gerstel, Gabriele Maria
Galimberti, Luyuan Fang and Walid Wakim for their review Galimberti, Luyuan Fang and Walid Wakim for their review
comments. comments.
9. References Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
9.1. Normative References 10. References
10.1. Normative References
[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.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001. LSP Tunnels", RFC 3209, December 2001.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and
A. Ayyangarps, "Encoding of Attributes for MPLS LSP A. Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Establishment Using Resource Reservation Protocol
Traffic Engineering (RSVP-TE)", RFC 5420, February Traffic Engineering (RSVP-TE)", RFC 5420, February
2009. 2009.
[DRAFT-OSPF-TE-METRIC] S. Giacalone, D. Ward, J. Drake, A. [RFC7471] S. Giacalone, D. Ward, J. Drake, A. Atlas, S.
Atlas, S. Previdi, "OSPF Traffic Engineering (TE) Previdi., "OSPF Traffic Engineering (TE) Metric
Metric Extensions", draft-ietf-ospf-te-metric- Extensions", RFC 7471, March 2015.
extensions, work in progress.
[DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. [DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J.
Drake, A. Atlas, C. Filsfils, "IS-IS Traffic Drake, A. Atlas, C. Filsfils, "IS-IS Traffic
Engineering (TE) Metric Extensions", draft-ietf-isis- Engineering (TE) Metric Extensions", draft-ietf-isis-
te-metric-extensions, work in progress. te-metric-extensions, work in progress.
9.2. Informative References 10.2. Informative References
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) "Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005. Overlay Model", RFC 4208, October 2005.
[RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1 Message Processing Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997. Rules", RFC 2209, September 1997.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
Internet-Draft draft-ietf-teas-te-metric-recording-01.txt [DRAFT-SRLG-RECORDING] F. Zhang, O. Gonzalez de Dios, M.
Hartley, Z. Ali, C. Margaria, "RSVP-TE Extensions for
[DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. Collecting SRLG Information", draft-ietf-teas-rsvp-te-
Margaria,, "RSVP-TE Extensions for Collecting SRLG srlg-collect.txt, work in progress.
Information", draft-ietf-ccamp-rsvp-te-srlg-
collect.txt, work in progress.
Authors' Addresses Authors' Addresses
Internet-Draft draft-ietf-teas-te-metric-recording-02.txt
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
Email: zali@cisco.com Email: zali@cisco.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
swallow@cisco.com swallow@cisco.com
Clarence Filsfils Clarence Filsfils
 End of changes. 120 change blocks. 
433 lines changed or deleted 417 lines changed or added

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