draft-ietf-teas-te-metric-recording-03.txt   draft-ietf-teas-te-metric-recording-04.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: August 7, 2016 Matt Hartley Expires: September 20, 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
March 21, 2016
February 8, 2016
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-03 draft-ietf-teas-te-metric-recording-04
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 August 7, 2016. This Internet-Draft will expire on September 20, 2016.
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt
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
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
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
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.
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, Delay and Delay variation associated with the TE link such as cost, delay and delay variation associated with the TE link
formed by Label Switched Path (LSP) are not available to the formed by Label Switched Path (LSP) are not available to the
ingress and egress nodes. This draft provides extensions for the ingress and egress nodes. This draft provides extensions for the
Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) to Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) to
support automatic collection of cost, Delay and Delay variation support automatic collection of cost, delay and delay variation
information for the TE link formed by a 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
Copyright Notice............................................1 1. Introduction ......................................... 3
1. Introduction.............................................3 1.1. Use Cases ......................................... 4
1.1. Use Cases..............................................4 1.1.1. GMPLS ...................................... 4
1.1.1. GMPLS..........................................4 1.1.2. Inter-area tunnels with loose-hops ......... 4
1.1.2. Inter-area tunnels with loose-hops.............4 2. RSVP-TE Requirement .................................. 4
2. RSVP-TE Requirement......................................4 2.1. Cost, Delay and Delay Variation Collection
2.1. Cost, Delay and Delay Variation Collection Indication..4 Indication ......................................... 4
2.2. Cost, Delay and Delay Variation Collection.............4 2.2. Cost, Delay and Delay Variation Collection ......... 5
2.3. Cost, Delay and Delay Variation Update.................5 2.3. Cost, Delay and Delay Variation Update ............. 5
2.4. Cost Definition........................................5 2.4. Cost Definition .................................... 5
3. RSVP-TE signaling extensions.............................5 3. Encoding ............................................. 5
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 3.1. Cost, Delay and Delay Variation Collection Flags ... 5
3.2. RRO Cost Subobject ................................. 6
3.3. RRO Delay Subobject ................................ 7
3.4. RRO Delay Variation Subobject ...................... 7
4. Signaling Procedures ................................. 8
4.1. Cost, Delay and Delay Variation Collection ......... 9
4.2. Metric Update ......................................12
4.3. Domain Boundaries ..................................12
4.4. Endpoint processing ................................12
4.5. Compatibility ......................................13
Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
3.1. Cost, Delay and Delay Variation Collection Flags.......5 5. Manageability Considerations .........................13
3.2. Cost Subobject.........................................6 5.1. Policy Configuration ...............................13
3.3. Delay Subobject........................................6 6. Security Considerations ..............................14
3.4. Delay Variation Subobject..............................7 7. IANA Considerations ..................................14
4. Signaling Procedures.....................................8 7.1. RSVP Attribute Bit Flags ...........................14
4.1. Cost, Delay and Delay Variation Collection Request.....8 7.2. ROUTE_RECORD subobject .............................15
4.2. Cost, Delay and Delay Variation Recoding...............8 7.3. Policy Control Failure Error subcodes ..............15
4.3. Metric Update..........................................10 8. Acknowledgments ......................................15
4.4. Compatibility..........................................10 9. References ...........................................16
5. Endpoint processing......................................11 9.1. Normative References ...............................16
6. Manageability Considerations.............................11 9.2. Informative References .............................16
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. Delay, Delay variation) is network performance information (e.g. delay, delay variation) is
becoming as critical to data path selection as other metrics RFC becoming as critical to data path selection as other metrics
7471 [RFC7471], [DRAFT-ISIS-TE-METRIC]. If cost, Delay or Delay [RFC7471], [DRAFT-ISIS-TE-METRIC]. If cost, delay or delay
variation associated with a Forwarding Adjacency (FA) or a variation associated with a Forwarding Adjacency (FA) or a
Routing Adjacency (RA) LSP is not available to the ingress or Routing Adjacency (RA) LSP is not available to the ingress or
egress node, it cannot be advertised as an attribute of the TE egress node, it cannot be advertised as an attribute of the TE
link (FA or RA). There are scenarios in packet and optical link (FA or RA). There are scenarios in packet and optical
networks where the route information of an LSP may not be networks where the route information of an LSP may not be
provided to the ingress node for confidentiality reasons and/or provided to the ingress node for confidentiality reasons and/or
the ingress node may not run the same routing instance as the the ingress node may not run the same routing instance as the
intermediate nodes traversed by the path. Similarly, there are intermediate nodes traversed by the path. Similarly, there are
scenarios in which measuring Delay and/ or Delay variation on a scenarios in which measuring delay and/ or delay variation on a
TE link formed by a LSP is not supported. In such scenarios, the TE link formed by a LSP is not supported. In such scenarios, the
ingress node cannot determine the cost, Delay and Delay 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,
Delay and Delay variation values manually. However, in the event delay and delay variation values manually. However, in the event
of an LSP being rerouted (e.g. due to re-optimization), such of an LSP being rerouted (e.g. due to re-optimization), such
configuration information may become invalid. Consequently, in configuration information may become invalid. Consequently, in
cases where that an LSP is advertised as a TE-Link, the ingress cases where that an LSP is advertised as a TE-Link, the ingress
and/or egress nodes cannot provide the correct Delay, Delay and/or egress nodes cannot provide the correct delay, delay
variation and cost information 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, Delay and Delay variation information nodes to learn the cost, delay and delay variation information
of the TE link formed by a LSP. This document provides a of the TE link formed by a LSP. This document provides a
mechanism to collect the cost, Delay and Delay variation mechanism to collect the cost, delay and delay variation
information of a LSP, which can then be advertised as properties information of a LSP, which can then be advertised as properties
of the TE-link formed by that LSP. Note that specification of of the TE-link formed by that LSP. Note that specification of
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt the use of the collected cost, delay and delay variation
the use of the collected cost, Delay and Delay variation
information is outside the scope of this document. information is outside the scope of this document.
Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
1.1. Use Cases 1.1. Use Cases
This section describes some of the use cases for TE metric This section describes some of the use cases for the TE metric
recording. 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, Delay and Delay variation properties of the LSP path. the cost, delay and delay variation properties of the LSP path.
A multi-domain or multi-layer network is an example of such A multi-domain or multi-layer network is an example of such
networks. A GMPLS User-Network Interface (UNI) [RFC4208] is also networks. A GMPLS User-Network Interface (UNI) [RFC4208] is also
an example of such networks. an example of such networks.
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 may 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, Delay and Delay variation properties of the determine the cost, delay and delay variation properties of the
LSP path. LSP path.
2. RSVP-TE Requirement 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, Delay and Delay variation the automatic collection of cost, delay and delay variation
information of an LSP. information of an LSP.
As RSVP-TE requirements for cost, delay and delay variation
collection are similar, many parts of this section are written
such that they apply equally to cost, delay and delay variation
collection. There is also very strong similarity of these RSVP-
requirements with SRLG recording [DRAFT-SRLG-RECORDING].
2.1. Cost, Delay and Delay Variation Collection Indication 2.1. Cost, Delay and Delay Variation Collection Indication
The ingress node of the LSP SHOULD be capable of indicating The ingress node of the LSP needs be capable of indicating
whether the cost and/or delay and/ or delay variation whether the cost and/or delay and/ or delay variation
information of the LSP is to be collected during the signaling information of the LSP is to be collected during the signaling
procedure of setting up an LSP. A separate collection indication procedure of setting up an LSP. A separate collection indication
flag for each of this attribute is required. Cost, delay and flag for each of these attributes is required. There is no need
delay variation information SHOULD NOT be collected without an for cost and/or delay and/ or delay variation to be collected
explicit request for it being made by the ingress node. without an explicit request for it being made by the ingress
node.
It may be preferable for the cost and/ or delay and/ or delay
variation collection request to be understood by all nodes along
the LSP's path, or it may be more important for the LSP to be
established successfully even if it traverses nodes that cannot
supply the requested information or have not implemented the
procedures specified in this document. It is desirable for the
Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
ingress node to make the cost, delay and delay variation
collection request in a manner that best suits its own policy.
2.2. Cost, Delay and Delay Variation Collection 2.2. Cost, Delay and Delay Variation Collection
If requested, the cost and/or delay and/ or delay variation If requested, the cost and/or delay and/ or delay variation
information SHOULD be collected during the setup of an LSP. Each information is collected during the setup of an LSP. Each of the
of the cost, delay or delay variation can be collected cost, delay or delay variation can be collected independently.
independently. The endpoints of the LSP can use the collected Cost and/ or delay and/ or delay variation information is for
information, for example, for routing, flooding and other each hop is added to the Path RRO during Path message
purposes. processing. The corresponding information is also added to the
Resv RRO during Resv processing at each hop. The endpoints of
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt the LSP can use the collected information, for example, for
routing, sharing and TE link configuration purposes.
2.3. Cost, Delay and Delay Variation Update 2.3. Cost, Delay and Delay Variation Update
When the cost and/or delay and/ or delay variation information When the cost and/or delay and/ or delay variation information
of an existing LSP for which corresponding information was of an existing LSP for which corresponding information was
collected during signaling changes, the relevant nodes of the collected during signaling changes, the relevant nodes of the
LSP SHOULD be capable of updating the associated information of LSP need to be capable of updating the associated information of
the LSP. This means that the signaling procedure SHOULD be the LSP. This means that the signaling procedure needs to be
capable of updating the new cost and/or delay and/ or delay capable of updating the new cost and/or delay and/ or delay
variation information. variation information.
2.4. Cost Definition 2.4. Cost Definition
Although the terms Delay and Delay 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
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. Encoding
3.1. Cost, Delay and Delay Variation Collection Flags 3.1. Cost, Delay and Delay Variation Collection Flags
In order to indicate nodes that cost and/or Delay and/ or Delay In order to indicate nodes that cost and/or Delay and/ or Delay
variation collection is desired, this document defines a new variation collection is desired, this document defines the
flags in the Attribute Flags TLV (see RFC 5420 [RFC5420]), which following new flags in the Attribute Flags TLV (see RFC 5420
MAY be carried in an LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
Object:
[RFC5420]), which MAY be carried in an LSP_REQUIRED_ATTRIBUTES
or LSP_ATTRIBUTES Object:
- Cost Collection flag (Bit number to be assigned by IANA) - Cost Collection flag (Bit number to be assigned by IANA)
- Delay Collection flag (Bit number to be assigned by IANA) - Delay Collection flag (Bit number to be assigned by IANA)
- Delay Variation Collection flag (Bit number to be assigned by - Delay Variation Collection flag (Bit number to be assigned by
IANA) IANA)
The Cost, Delay and Delay Variation Collection flag is The Cost, Delay and Delay Variation Collection flags are
meaningful on a Path message. If the Cost Collection flag is meaningful on a Path message. If the Cost Collection flag is
set to 1, it means that the cost information SHOULD be reported set to 1, it means that the cost information SHOULD be reported
to the ingress and egress node along the setup of the LSP. to the ingress and egress node along the setup of the LSP.
Similarly, if the Delay Collection flag is set to 1, it means Similarly, if the Delay Collection flag is set to 1, it means
that the Delay information SHOULD be reported to the ingress and that the Delay information SHOULD be reported to the ingress and
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt
egress node along the setup of the LSP. Likewise, if the Delay 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 Collection flag is set to 1, it means that the Delay
Variation information SHOULD be reported to the ingress and Variation information SHOULD be reported to the ingress and
egress node along the setup of the LSP. egress node along the setup of the LSP.
The rules of the processing of the Attribute Flags TLV are not The rules of the processing of the Attribute Flags TLV are not
changed. changed.
3.2. Cost Subobject 3.2. RRO Cost Subobject
This document defines a new RRO sub-object (ROUTE_RECORD sub- This document defines a new RRO sub-object (ROUTE_RECORD sub-
object) to record the cost information of the LSP. Its format object) to record the cost information of the LSP. Its format
is modeled on the RRO sub-objects defined in RFC 3209 [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 |D| Reserved (must be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost | | Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the sub-object (value to be assigned by Type: The type of the sub-object (value to be assigned by
IANA). IANA).
Length: The Length field contains the total length of the Length: The Length field contains the total length of the
sub-object in bytes, including the Type and Length fields. sub-object in bytes, including the Type and Length fields.
The Length value is set to 8. The Length value is set to 8.
Direction bit (D-bit)
If not set, the cost contained in this sub-object applies to
the downstream direction. If set, it applies to the upstream
direction.
Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
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.
Cost: Cost of the local TE link along the route of the LSP. Cost: Cost of the local TE link along the route of the LSP.
3.3. Delay Subobject 3.3. RRO Delay Subobject
This document defines a new RRO sub-object (ROUTE_RECORD sub- This document defines a new RRO sub-object (ROUTE_RECORD sub-
object) to record the delay information of the LSP. Its format object) to record the delay information of the LSP. Its format
is modeled on the RRO sub-objects defined in RFC 3209 [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 |D| Reserved (must be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Delay | |A| Reserved | Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt
Type: The type of the sub-object (value to be assigned by Type: The type of the sub-object (value to be assigned by
IANA). IANA).
Length: The Length field contains the total length of the Length: The Length field contains the total length of the
sub-object in bytes, including the Type and Length fields. sub-object in bytes, including the Type and Length fields.
The Length value is set to 8. The Length value is set to 8.
Direction bit (D-bit)
If not set, the Delay contained in this sub-object applies to
the downstream direction. If set, it applies to the upstream
direction.
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 RFC 7471 [RFC7471]. 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.
Delay: Delay of the local TE link along the route of the LSP, Delay: Delay of the local TE link along the route of the LSP,
encoded as 24-bit integer, as defined in RFC 7471 [RFC7471]. encoded as 24-bit integer, as defined in RFC 7471 [RFC7471].
When set to the maximum value 16,777,215 (16.777215 sec), the When set to the maximum value 16,777,215 (16.777215 sec), the
delay is at least that value and may be larger. delay is at least that value and may be larger.
3.4. Delay Variation Subobject 3.4. RRO Delay Variation Subobject
This document defines a new RRO sub-object (ROUTE_RECORD sub- This document defines a new RRO sub-object (ROUTE_RECORD sub-
object) to record the delay variation information of the LSP. object) to record the delay variation information of the LSP.
Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
Its format is modeled on the RRO sub-objects defined in RFC 3209 Its format is modeled on the RRO sub-objects defined in RFC 3209
[RFC3209]. [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 |D| Reserved (must be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Delay Variation | |A| Reserved | Delay Variation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the sub-object (value to be assigned by Type: The type of the sub-object (value to be assigned by
IANA). IANA).
Length: The Length field contains the total length of the Length: The Length field contains the total length of the
sub-object in bytes, including the Type and Length fields. sub-object in bytes, including the Type and Length fields.
The Length value is set to 8. The Length value is set to 8.
Direction bit (D-bit)
If not set, the Delay Variation contained in this sub-object
applies to the downstream direction. If set, it applies to
the upstream direction.
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 RFC 7471 [RFC7471]. 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.
Delay Variation: Delay Variation of the local TE link along Delay Variation: Delay Variation of the local TE link along
the route of the LSP, encoded as 24-bit integer, as defined the route of the LSP, encoded as 24-bit integer, as defined
in RFC 7471 [RFC7471]. When set to the maximum value in RFC 7471 [RFC7471]. When set to the maximum value
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt
16,777,215 (16.777215 sec), the delay variation is at least 16,777,215 (16.777215 sec), the delay variation is at least
that value and may be larger. that value and may be larger.
4. Signaling Procedures 4. Signaling Procedures
The rules of the processing of the LSP_REQUIRED_ATTRIBUTES,
LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed.
As signaling procedure for cost, delay and delay variation As signaling procedure for cost, delay and delay variation
collection is similar, many parts of this section are written collection is similar, many parts of this section are written
such that they apply equally to cost, delay and delay variation such that they apply equally to cost, delay and delay variation
collection. There is also very strong similarity of these collection. There is also very strong similarity of these
procedures with SRLG recording [DRAFT-SRLG-RECORDING]. procedures with SRLG recording [DRAFT-SRLG-RECORDING].
4.1. Cost, Delay and Delay Variation Collection Request The ingress node of the LSP MUST be capable of indicating
whether the Cost and/ or Delay and/ or Delay Variation
information of the LSP is to be collected during the signaling
procedure of setting up an LSP.
Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
A node MUST NOT push Cost and/ or Delay and/ or Delay Variation
sub-object(s) in the RECORD_ROUTE without also pushing either an
IPv4 sub-object, an IPv6 sub-object, an Unnumbered Interface ID
sub-object or a Path Key sub-object or an SRLG sub-object.
As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is
managed as a stack. The Cost and/ or Delay and/ or Delay
Variation sub-object(s) SHOULD be pushed by the node before the
node IP address or link identifier. These sub-object(s) SHOULD
be pushed after the Attribute sub-object, if present, and after
the LABEL sub-object, if requested, and after the SRLG sub-
object, if requested. These sub-object(s) MUST be pushed within
the hop to which it applies.
RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key
Sub-object) in the RRO so as to facilitate confidentiality in
the signaling of inter-domain TE LSPs, and allows the path
segment that needs to be hidden (that is, a Confidential Path
Segment (CPS)) to be replaced in the RRO with a PKS. If the CPS
contains Cost and/ or Delay and/ or Delay Variation Sub-objects,
these MAY be retained in the RRO by adding them again after the
PKS Sub-object in the RRO. The CPS is defined in RFC 5520
[RFC5520].
The rules of the processing of the LSP_REQUIRED_ATTRIBUTES,
LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed.
4.1. Cost, Delay and Delay Variation Collection
Per RFC 3209 [RFC3209], an ingress node initiates the recording Per RFC 3209 [RFC3209], an ingress node initiates the recording
of the route information of an LSP by adding a RRO to a Path 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 message. If an ingress node also desires Cost and/or Delay
and/or Delay Variation recording, it MUST set the appropriate and/or Delay Variation recording, it MUST set the appropriate
flag(s) in the Attribute Flags TLV which MAY be carried either flag(s) in the Attribute Flags TLV which MAY be carried either
in an LSP_REQUIRED_ATTRIBUTES Object when the collection is in an LSP_REQUIRED_ATTRIBUTES Object when the collection is
mandatory, or in an LSP_ATTRIBUTES Object when the collection is mandatory, or in an LSP_ATTRIBUTES Object when the collection is
desired, but not mandatory. desired, but not mandatory.
4.2. Cost, Delay and Delay Variation Recoding
When a node receives a Path message which carries an When a node receives a Path message which carries an
LSP_REQUIRED_ATTRIBUTES Object and the Cost Collection Flag set, LSP_REQUIRED_ATTRIBUTES Object with the Cost Collection Flag
if local policy determines that the cost information is not to set, if local policy determines that the Cost information is not
be provided to the endpoints or the information is not known, it to be provided to the endpoints, it MUST return a PathErr
MUST return a PathErr message with error code 2 (policy) and message with:
error subcode "Cost Recording Rejected" (value to be assigned by
IANA) to reject the Path message. Similarly, when a node o Error Code 2 (policy) and
receives a Path message which carries an LSP_REQUIRED_ATTRIBUTES
Object and the Delay Collection Flag set, if local policy o Error subcode "Cost Recording Rejected" (value to be
determines that the Delay information is not to be provided to assigned by IANA)
the endpoints or the information is not known, it MUST return a
PathErr message with error code 2 (policy) and error subcode to reject the Path message. Similarly, when a node receives a
"Delay Recording Rejected" (value to be assigned by IANA) to Path message which carries an LSP_REQUIRED_ATTRIBUTES Object
reject the Path message. Likewise, when a node receives a Path with the Delay Collection Flag set, if local policy determines
message which carries an LSP_REQUIRED_ATTRIBUTES Object and the Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
Delay Variation Collection Flag set, if local policy determines
that the Delay Variation information is not to be provided to that the Delay information is not to be provided to the
the endpoints or the information is not known, it MUST return a endpoints, it MUST return a PathErr message with:
PathErr message with error code 2 (policy) and error subcode
"Delay Variation Recording Rejected" (value to be assigned by o Error Code 2 (policy) and
IANA) to reject the Path message.
o 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
with the Delay Variation Collection Flag set, if local policy
determines that the Delay Variation information is not to be
provided to the endpoints, it MUST return a PathErr message
with:
o Error Code 2 (policy) and
o Error subcode "Delay Variation Recording Rejected" (value
to be assigned by IANA)
to reject the Path message.
When a node receives a Path message which carries an When a node receives a Path message which carries an
LSP_ATTRIBUTES Object and the Cost and/or Delay and/or Delay LSP_ATTRIBUTES Object and the Cost and/or Delay and/or Delay
Variation Collection Flag set, if local policy determines that Variation Collection Flag set, if local policy determines that
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt
the corresponding information is not to be provided to the the corresponding information is not to be provided to the
endpoints, or the information is not known, the Path message endpoints, or the information is not known, the Path message
SHOULD NOT be rejected due to the recording restriction and the SHOULD NOT be rejected due to the recording restriction and the
Path message SHOULD be forwarded without any Cost and/or Delay Path message SHOULD be forwarded without any Cost and/or Delay
and/or Delay Variation sub-object(s) in the RRO of the and/or Delay Variation sub-object(s) in the RRO of the
corresponding outgoing Path message. corresponding outgoing Path message.
If local policy permits the recording of the Cost and/or Delay If local policy permits the recording of the Cost and/or Delay
and/or Delay Variation information, the processing node SHOULD and/or Delay Variation information, the processing node SHOULD
add corresponding information for the local TE link, as defined add corresponding information for the local TE link, as defined
below, to the RRO of the corresponding outgoing Path message. below, to the RRO of the corresponding outgoing Path message.
The A-bit for the Delay MUST be set as described in RFC 7471 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 [RFC7471]. Similarly, the A-bit for the Delay Variation MUST be
set as described in RFC 7471 [RFC7471]. It then forwards the set as described in RFC 7471 [RFC7471]. It then forwards the
Path message to the next node in the downstream direction. Path message to the next node in the downstream direction. The
processing node MUST retain a record of the Cost and/ or Delay
and/ or Delay Variation Collection request for reference during
Resv processing described below.
If the addition of Cost and/or Delay and/or Delay Variation If the addition of Cost and/or Delay and/or Delay Variation
information to the RRO would result in the RRO exceeding its information to the RRO would result in the RRO exceeding its
maximum possible size or becoming too large for the Path message maximum possible size or becoming too large for the Path message
to contain it, the requested information MUST NOT be added. If to contain it, the requested information MUST NOT be added. If
the Cost and/or Delay and/or Delay Variation collection request the Cost and/or Delay and/or Delay Variation collection request
was contained in an LSP_REQUIRED_ATTRIBUTES Object, the was contained in an LSP_REQUIRED_ATTRIBUTES Object, the
processing node MUST behave as specified by RFC 3209 [RFC3209] processing node MUST behave as specified by RFC 3209 [RFC3209]
and drop the RRO from the Path message entirely. If the Cost and drop the RRO from the Path message entirely. If the Cost
Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
and/or Delay and/or Delay Variation collection request was and/or Delay and/or Delay Variation collection request was
contained in an LSP_ATTRIBUTES Object, the processing node MAY contained in an LSP_ATTRIBUTES Object, the processing node MAY
omit some or all of the corresponding information from the RRO; omit some or all of the corresponding information from the RRO;
otherwise it MUST behave as specified by RFC 3209 [RFC3209] and otherwise it MUST behave as specified by RFC 3209 [RFC3209] and
drop the RRO from the Path message entirely. drop the RRO from the Path message entirely.
Following the steps described above, the intermediate nodes of Following the steps described above, the intermediate nodes of
the LSP can collect the Cost and/or Delay and/or Delay Variation the LSP can collect the Cost and/or Delay and/or Delay Variation
information in the RRO during the processing of the Path message information in the RRO during the processing of the Path message
hop by hop. When the Path message arrives at the egress node, hop by hop. When the Path message arrives at the egress node,
the egress node receives the corresponding information in the the egress node receives the corresponding information in the
RRO. RRO.
Per RFC 3209 [RFC3209], when issuing a Resv message for a Path Per RFC 3209 [RFC3209], when issuing a Resv message for a Path
message, which contains an RRO, an egress node initiates the RRO message, which contains an RRO, an egress node initiates the RRO
process by adding an RRO to the outgoing Resv message. The process by adding an RRO to the outgoing Resv message. The
processing for RROs contained in Resv messages then mirrors that processing for RROs contained in Resv messages then mirrors that
of the Path messages. of the Path messages.
When a node receives a Resv message for an LSP for which Cost When a node receives a Resv message for an LSP for which Cost
and/or Delay and/or Delay Variation Collection is requested, and/or Delay and/or Delay Variation Collection was specified,
then when local policy allows recording of the requested then when local policy allows recording of the requested
information, the node SHOULD add corresponding information, to information, the node SHOULD add corresponding information, to
the RRO of the outgoing Resv message, as specified below. The the RRO of the outgoing Resv message, as specified below. The
A-bit for the Delay MUST be set as described in RFC 7471 A-bit for the Delay MUST be set as described in RFC 7471
[RFC7471]. Similarly, the A-bit for the Delay Variation MUST be [RFC7471]. Similarly, the A-bit for the Delay Variation MUST be
set as described in RFC 7471 [RFC7471]. When the Resv message set as described in RFC 7471 [RFC7471]. When the Resv message
arrives at the ingress node, the ingress node can extract the arrives at the ingress node, the ingress node can extract the
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt
requested information from the RRO in the same way as the egress requested information from the RRO in the same way as the egress
node. node.
A node MUST NOT push a Cost, Delay or Delay Variation sub-object Note that a link's Cost and/ or Delay and/ or Delay Variation
in the RECORD_ROUTE without also pushing an IPv4 sub-object, an
IPv6 sub-object, an Unnumbered Interface ID sub-object or a Path
Key sub-object.
Note that a link's Cost and/or Delay and/or Delay Variation
information for the upstream direction cannot be assumed to be information for the upstream direction cannot be assumed to be
the same as that in the downstream. the same as that in the downstream.
. For Path and Resv messages for a unidirectional LSP, a node o For Path and Resv messages for a unidirectional LSP, a node
SHOULD include Cost and/or Delay and/or Delay Variation sub- SHOULD include Cost and/ or Delay and/ or Delay Variation
objects in the RRO for the downstream data link only. sub-objects in the RRO for the downstream data link only.
. For Path and Resv messages for a bidirectional LSP, a node o For Path and Resv messages for a bidirectional LSP, a node
SHOULD include Cost and/or Delay and/or Delay Variation sub- SHOULD include Cost and/ or Delay and/ or Delay Variation
objects in the RRO for both the upstream data link and the sub-objects in the RRO for both the upstream data link and
downstream data link from the local node. In this case, the the downstream data link from the local node. In this
node MUST include the information in the same order for both case, the node MUST include the metric information in the
Path messages and Resv messages. That is, the Cost and/or same order for both Path messages and Resv messages. That
Delay and/or Delay Variation sub- object for the upstream link is, the Cost and/ or Delay and/ or Delay Variation sub-
is added to the RRO before the corresponding sub-object for object(s) for the upstream link is added to the RRO before
the downstream link. the corresponding sub-object for the downstream link.
4.3. Metric Update If Cost and/ or Delay and/ or Delay Variation data is added
for both the upstream and downstream links, the two sets of
the data MUST be added in separate corresponding sub-
Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
When the Cost and/or Delay and/or Delay Variation information of object(s). A single Cost or Delay or Delay Variation sub-
a link is changed, the LSPs using that link need to be aware of object MUST NOT contain a mixture of the applicable data
the changes. The procedures defined in Section 4.4.3 of RFC for upstream and downstream directions. When adding a Cost
3209 [RFC3209] MUST be used to refresh the Cost and/or Delay or Delay or Delay Variation sub-object to an RRO, the D-bit
and/or Delay Variation information if the corresponding change MUST be set appropriately to indicate the direction of the
is to be communicated to other nodes according to the local TE Link. If the same value applies in both directions, it
node's policy. If local policy is that the Cost and/or Delay SHOULD be added to both the corresponding upstream and
and/or Delay Variation change SHOULD be suppressed or would downstream sub-objects.
result in no change to the previously signaled information, the
node SHOULD NOT send an update.
4.4. Compatibility Based on the local policy, a transit node may edit a Path or
Resv RRO to remove route information (e.g. node or interface
identifier information) before forwarding it. A node that does
this SHOULD summarize the cost, Delay and Delay Variation data.
How a node that performs the RRO edit operation calculates the
Cost and/ or Delay and/or Delay variation metric is beyond the
scope of this document.
A node that does not recognize the Cost and/or Delay and/or A node SHOULD NOT add Cost or Delay or Delay Variation
Delay Variation Collection Flag in the Attribute Flags TLV is information without an explicit request for the corresponding
expected to proceed as specified in RFC 5420 [RFC5420]. It is information being made by the ingress node in the Path message.
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.
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 4.2. Metric Update
A node that does not recognize the Cost and/or Delay and/or When the Cost and/or Delay and/or Delay Variation information of
Delay Variation RRO sub-object is expected to behave as a link is changed, the endpoints of LSPs using that link need to
specified in RFC 3209 [RFC3209]: unrecognized subobjects are to be aware of the changes. When a change to Cost or Delay or
be ignored and passed on unchanged. Delay Variation information associated with a link occurs, the
procedures defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST
be used to refresh the corresponding metric information if the
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.
5. Endpoint processing 4.3. Domain Boundaries
Based on the procedures mentioned in Section 4, the endpoints If mandated by local policy, a node MAY remove Cost and/or Delay
can get the Cost and/or Delay and/or Delay Variation information and/or Delay Variation information from any RRO in a Path or
Resv message being processed. A node that does this SHOULD
summarize the Cost, Delay and Delay Variation data. How a node
that performs the RRO edit operation calculates the Cost, Delay
and/or Delay variation metric is beyond the scope of this
document.
4.4. Endpoint processing
Based on the procedures described above, the endpoints can get
the Cost and/or Delay and/or Delay Variation information
automatically. Then the endpoints can for instance advertise it automatically. Then the endpoints can for instance advertise it
as a TE link to the routing instance based on the procedure as a TE link to the routing instance based on the procedure
described in [RFC6107]. How the end point uses the collected described in [RFC6107] and configure the corresponding TE metric
information is outside the scope of this document. Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
information of the Forwarding Adjacency (FA) or Routing
Adjacency (RA) automatically. 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, Delay and/or Delay 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 Delay are additive metrics, but Delay 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, Delay and ingress and egress nodes compute the end-to-end Cost, Delay and
Delay variation metric from information recorded in the RRO is a Delay variation metric from information recorded in the RRO is a
local decision and is beyond the scope of this document. local decision and is beyond the scope of this 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, Delay and/or Delay 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 RFC 7471 [RFC7471], [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 4.5. Compatibility
a domain) may edit a Path or Resv RRO to remove route
information (e.g. node or interface identifier information)
before forwarding it. A node that does this SHOULD summarize the
cost, Delay and Delay Variation data. How a node that performs
the RRO edit operation calculates the cost, Delay o and/or Delay
variation metric is beyond the scope of this document.
6. Manageability Considerations 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].
Specifically, the node is expected to pass the TLV on unaltered
if it appears in a LSP_ATTRIBUTES object. On the other hand, if
the TLV appears in a LSP_REQUIRED_ATTRIBUTES object, the node is
expected to reject the Path message with the Error Code and
Value defined in RFC 5420 [RFC5420].
6.1. Policy Configuration 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 sub-objects are to
be ignored and passed on unchanged.
5. Manageability Considerations
5.1. Policy Configuration
In a border node of inter-domain or inter-layer network, the In a border node of inter-domain or inter-layer network, the
following Cost and/or Delay and/or Delay Variation processing following Cost and/or Delay and/or Delay Variation processing
policy SHOULD be capable of being configured: policy SHOULD be capable of being configured:
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt o Whether the node is allowed to participate in Cost or Delay
or Delay Variation collection.
o Whether the Cost and/or Delay and/or Delay Variation of the o Whether the node should notify changes to collected Cost
domain or specific layer network can be exposed to the nodes and/ or Delay and/ or Delay Variation information to
outside the domain or layer network, or whether they SHOULD be endpoint nodes as described in section 4.2.
summarized, mapped to values that are comprehensible to nodes
outside the domain or layer network, or removed entirely. Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
o Whether the Cost and/or Delay and/or Delay Variation of the
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.
A node using RFC 5553 [RFC5553] and PKS MAY apply the same A node using RFC 5553 [RFC5553] and PKS MAY apply the same
policy. policy.
7. Security Considerations 6. Security Considerations
This document builds on the mechanisms defined in [RFC3473], This document builds on the mechanisms defined in [RFC3473],
which also discusses related security measures. In addition, which also discusses related security measures. In addition,
[RFC5920] provides an overview of security vulnerabilities and [RFC5920] provides an overview of security vulnerabilities and
protection mechanisms for the GMPLS control plane. The protection mechanisms for the GMPLS control plane. The
procedures defined in this document permit the transfer of Cost procedures defined in this document permit the transfer of Cost
and/or Delay and/or Delay Variation data between layers or and/or Delay and/or Delay Variation data between layers or
domains during the signaling of LSPs, subject to policy at the domains during the signaling of LSPs, subject to policy at the
layer or domain boundary. It is recommended that domain/layer layer or domain boundary. It is recommended that domain/layer
boundary policies take the implications of releasing Cost and/or boundary policies take the implications of releasing Cost and/or
Delay and/or Delay Variation information into consideration and Delay and/or Delay Variation information into consideration and
behave accordingly during LSP signaling. behave accordingly during LSP signaling.
8. IANA Considerations 7. IANA Considerations
8.1. RSVP Attribute Bit Flags 7.1. RSVP Attribute Bit Flags
IANA has created a registry and manages the space of the IANA has created a registry and manages the space of the
Attribute bit flags of the Attribute Flags TLV, as described in Attribute bit flags of the Attribute Flags TLV, as described in
section 11.3 of RFC 5420 [RFC5420], in the "Attribute Flags" section 11.3 of RFC 5420 [RFC5420], in the "Attribute Flags"
section of the "Resource Reservation Protocol-Traffic section of the "Resource Reservation Protocol-Traffic
Engineering (RSVP-TE) Parameters" registry located in Engineering (RSVP-TE) Parameters" registry located in
http://www.iana.org/assignments/rsvp-te- parameters". http://www.iana.org/assignments/rsvp-te- parameters".
This document introduces the following three new Attribute Bit This document introduces the following three new Attribute Bit
Flags: Flags:
Bit No Name Attribute Attribute RRO Reference Bit No Name Attribute Attribute RRO Reference
Flags Path Flags Resv Flags Path Flags Resv
----------- ---------- ---------- ----------- --- ------- ----------- ---------- ---------- ----------- --- -------
TBA by Cost Yes Yes Yes This I-D TBA by Cost Yes No Yes This I-D
IANA Collection IANA Collection
Flag Flag
TBA by Delay Yes Yes Yes This I-D TBA by Delay Yes No Yes This I-D
IANA Collection IANA Collection
Flag Flag
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
TBA by Delay Yes Yes Yes This I-D TBA by Delay Yes No Yes This I-D
IANA Variation IANA Variation
Collection Collection
Flag Flag
5.2. ROUTE_RECORD subobject 7.2. ROUTE_RECORD sub-object
IANA manages the "RSVP PARAMETERS" registry located at IANA manages the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters. This document http://www.iana.org/assignments/rsvp-parameters. This document
introduces the following three new RRO subobject: introduces the following three new RRO sub-object:
Type Name Reference Type Name Reference
--------- ---------------------- --------- --------- ---------------------- ---------
TBA by IANA Cost subobject This I-D TBA by IANA Cost sub-object This I-D
TBA by IANA Delay subobject This I-D TBA by IANA Delay sub-object This I-D
TBA by IANA Delay Variation subobject This I-D TBA by IANA Delay Variation sub-object This I-D
8.2. Policy Control Failure Error subcodes 7.3. Policy Control Failure Error subcodes
IANA manages the assignments in the "Error Codes and Globally- IANA manages the assignments in the "Error Codes and Globally-
Defined Error Value Sub-Codes" section of the "RSVP PARAMETERS" Defined Error Value Sub-Codes" section of the "RSVP PARAMETERS"
registry located at http://www.iana.org/assignments/rsvp- registry located at http://www.iana.org/assignments/rsvp-
parameters. This document introduces the following three new parameters. This document introduces the following three new
Policy Control Failure Error sub-code: Policy Control Failure Error sub-code:
Value Description Reference Value Description Reference
----- ----------- --------- ----- ----------- ---------
TBA by IANA Cost Recoding Rejected This I-D TBA by IANA Cost Recoding Rejected This I-D
TBA by IANA Delay Recoding Rejected This I-D TBA by IANA Delay Recoding Rejected This I-D
TBA by IANA Delay Variation Recoding Rejected This I-D TBA by IANA Delay Variation Recoding Rejected This I-D
9. Acknowledgments 8. 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.
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt Internet-Draft draft-ietf-teas-te-metric-recording-04.txt
10. References 9. References
10.1. Normative References 9.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.
[RFC3473] Berger, L., "Generalized Multi-Protocol Lab Switching
(GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[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.
[RFC7471] S. Giacalone, D. Ward, J. Drake, A. Atlas, S. [RFC7471] S. Giacalone, D. Ward, J. Drake, A. Atlas, S.
Previdi., "OSPF Traffic Engineering (TE) Metric Previdi., "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, March 2015. Extensions", RFC 7471, March 2015.
[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.
10.2. Informative References 9.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.
[DRAFT-SRLG-RECORDING] F. Zhang, O. Gonzalez de Dios, M. [DRAFT-SRLG-RECORDING] F. Zhang, O. Gonzalez de Dios, M.
Hartley, Z. Ali, C. Margaria, "RSVP-TE Extensions for Hartley, Z. Ali, C. Margaria,, "RSVP-TE Extensions for
Collecting SRLG Information", draft-ietf-teas-rsvp-te- Collecting SRLG Information", draft-ietf-teas-rsvp-te-
srlg-collect.txt, work in progress. srlg-collect.txt, work in progress.
Authors' Addresses Authors' Addresses
Internet-Draft draft-ietf-teas-te-metric-recording-03.txt Internet-Draft draft-ietf-teas-te-metric-recording-04.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. 106 change blocks. 
215 lines changed or deleted 341 lines changed or added

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