draft-ietf-ccamp-te-metric-recording-01.txt   draft-ietf-ccamp-te-metric-recording-02.txt 
CCAMP Working Group Zafar Ali CCAMP 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 24, 2013 Matt Hartley Expires: January 13, 2014 Matt Hartley
Cisco Systems Cisco Systems
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Ruediger Kunze Ruediger Kunze
Deutsche Telekom AG Deutsche Telekom AG
July 14, 2013
February 25, 2013
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-ccamp-te-metric-recording-01.txt draft-ietf-ccamp-te-metric-recording-02.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of this Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This Internet-Draft is submitted in full conformance with the
Task Force (IETF). Note that other groups may also distribute provisions of BCP 78 and BCP 79.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are working documents of the Internet Engineering
months and may be updated, replaced, or obsoleted by other Task Force (IETF). Note that other groups may also distribute
documents at any time. It is inappropriate to use Internet-Drafts working documents as Internet-Drafts. The list of current Internet-
as reference material or to cite them other than as "work in Drafts is at http://datatracker.ietf.org/drafts/current/.
progress."
This Internet-Draft will expire on August 24, 2013. Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice This Internet-Draft will expire on January 13, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document Copyright Notice
authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Copyright (c) 2013 IETF Trust and the persons identified as the
Relating to IETF Documents (http://trustee.ietf.org/license-info) in document authors. All rights reserved.
effect on the date of publication of this document. Please review these
documents carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this document
must include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as described
in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document is subject to BCP 78 and the IETF Trust's Legal
Contributions published or made publicly available before November 10, Provisions Relating to IETF Documents
2008. The person(s) controlling the copyright in some of this material (http://trustee.ietf.org/license-info) in effect on the date of
may not have granted the IETF Trust the right to allow modifications of publication of this document. Please review these documents
Internet-Draft draft-ietf-ccamp-te-metric-recording-01.txt carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
such material outside the IETF Standards Process. Without obtaining an Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
adequate license from the person(s) controlling the copyright in such
materials, this document may not be modified outside the IETF Standards
Process, and derivative 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 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, latency and latency variation associated with a such as cost, latency and latency variation associated with a
Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched
Path (LSP) are not available to the ingress and egress nodes. This Path (LSP) are not available to the ingress and egress nodes. This
draft provides extensions for the Resource ReserVation Protocol- draft provides extensions for the Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) for the support of the discovery of Traffic Engineering (RSVP-TE) for the support of the discovery of
cost, latency and latency variation of an LSP. cost, latency and latency variation of an LSP.
skipping to change at page 2, line 35 skipping to change at page 2, line 29
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 Copyright Notice..................................................1
1. Introduction...................................................3 1. Introduction...................................................3
2. RSVP-TE Requirement............................................3 2. RSVP-TE Requirement............................................3
2.1. Cost, Latency and Latency Variation Collection Indication.......4 2.1. Cost, Latency and Latency Variation Collection Indication....4
2.2. Cost, Latency and Latency Variation Collection..................4 2.2. Cost, Latency and Latency Variation Collection...............4
2.3. Cost, Latency and Latency Variation Update......................4 2.3. Cost, Latency and Latency Variation Update...................4
3. RSVP-TE signaling extensions...................................4 3. RSVP-TE signaling extensions...................................4
3.1. Cost Collection Flag............................................4 3.1. Cost, Latency and Latency Variation Collection Flags.........4
3.2. Latency Collection Flag.........................................5 3.2. Cost Subobject...............................................5
3.3. Latency Variation Collection Flag...............................5 3.3. Latency Subobject............................................6
3.4. Cost subobject..................................................5 3.4. Latency Variation Subobject..................................7
3.5. Latency subobject...............................................6 3.5. Signaling Procedures.........................................8
3.6. Latency Variation subobject.....................................7
3.7. Signaling Procedures............................................7
4. Security Considerations........................................9 4. Security Considerations........................................9
Internet-Draft draft-ietf-ccamp-te-metric-recording-01.txt
5. IANA Considerations............................................9 5. IANA Considerations............................................9
5.1. RSVP Attribute Bit Flags........................................9 5.1. RSVP Attribute Bit Flags.....................................9
5.2. New RSVP error sub-code........................................10 Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
6. Acknowledgments...............................................10
5.2. New RSVP error sub-code.....................................10
6. Acknowledgments...............................................11
7. References....................................................11 7. References....................................................11
7.1. Normative References...........................................11 7.1. Normative References........................................11
7.2. Informative References.........................................11 7.2. Informative References......................................12
1. Introduction 1. Introduction
There are many scenarios in packet and optical networks where There are many scenarios in packet and optical networks where
the route information of an LSP may not be provided to the the route information of an LSP may not be provided to the
ingress node for confidentiality reasons and/ or the ingress ingress node for confidentiality reasons and/or the ingress node
node may not run the same routing instance as the intermediate may not run the same routing instance as the intermediate nodes
nodes traversed by the path. In such scenarios, the ingress node traversed by the path. In such scenarios, the ingress node
cannot determine the cost, latency and latency variation cannot determine the cost, latency and latency variation
properties of the LSP's route. Similarly, in Generalized Multi- properties of the LSP's route. Similarly, in Generalized Multi-
Protocol Label Switching (GMPLS) networks signaling Protocol Label Switching (GMPLS) networks signaling
bidirectional LSP, the egress node cannot determine the cost, bidirectional LSP, the egress node cannot determine the cost,
latency and latency variation properties of the LSP route. A latency and latency variation properties of the LSP route. A
multi-domain or multi-layer network is an example of such multi-domain or multi-layer network is an example of such
networks. Similarly, a GMPLS User-Network Interface (UNI) networks. Similarly, a GMPLS User-Network Interface (UNI)
[RFC4208] is also an example of such networks. [RFC4208] is also an example of such networks.
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. latency, latency
variation) is becoming as critical to data path selection as variation) is becoming as critical to data path selection as
other metrics [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. If other metrics [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. If
cost, latency or latency variation associated with an FA or an cost, latency or latency variation associated with an FA or an
RA LSP is not available to the ingress or egress node, it cannot RA LSP is not available to the ingress or egress node, it cannot
be advertised as an attribute of the FA or RA. One possible way be advertised as an attribute of the FA or RA. One possible way
to address this issue is to configure cost, latency and latency to address this issue is to configure cost, latency and latency
variation values manually. However, in the event of an LSP being variation values manually. However, in the event of an LSP being
rerouted (e.g. due to re-optimization), such configuration rerouted (e.g. due to re-optimization), such configuration
information may become invalid. Consequently, in case where that information may become invalid. Consequently, in case where that
an LSP is advertised as a TE-Link, the ingress and/ or egress an LSP is advertised as a TE-Link, the ingress and/or egress
nodes cannot provide the correct latency, latency variation and nodes cannot provide the correct latency, latency variation and
cost attribute associated with the TE-Link automatically. cost attribute associated with the TE-Link 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, latency and latency variation
attributes of an FA or RA LSP. This draft provides extensions to attributes of an FA or RA LSP. This draft provides extensions to
the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
for the support of the automatic discovery of these attributes. for the support of the automatic discovery of these attributes.
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, latency and latency variation the automatic discovery of cost, latency and latency variation
attributes of an LSP. These requirements are very similar to the attributes of an LSP. These requirements are very similar to the
requirement of discovering the Shared Risk Link Groups (SRLGs) requirement of discovering the Shared Risk Link Groups (SRLGs)
Internet-Draft draft-ietf-ccamp-te-metric-recording-01.txt
associated with the route taken by an LSP [DRAFT-SRLG- associated with the route taken by an LSP [DRAFT-SRLG-
RECORDING]. RECORDING].
Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
2.1. Cost, Latency and Latency Variation Collection Indication 2.1. Cost, Latency and Latency Variation Collection Indication
The ingress node of the LSP must be capable of indicating The ingress node of the LSP must be capable of indicating
whether the cost, latency and latency variation attributes of whether the cost, latency and latency variation attributes of
the LSP should be collected during the signaling procedure of the LSP should be collected during the signaling procedure of
setting up the LSP. No cost, latency or latency variation setting up the LSP. No cost, latency or latency variation
information is collected without an explicit request being made information is collected without an explicit request being made
by the ingress node. by the ingress node.
2.2. Cost, Latency and Latency Variation Collection 2.2. Cost, Latency and Latency Variation Collection
skipping to change at page 4, line 42 skipping to change at page 4, line 40
of the path and signaling this to the end-points. Similarly, if of the path and signaling this to the end-points. Similarly, if
a path segment of the LSP is rerouted, the endpoints of the re- a path segment of the LSP is rerouted, the endpoints of the re-
routed segment need to be capable of updating the cost, latency routed segment need to be capable of updating the cost, latency
and latency variation information of the path. Any node, which and latency variation information of the path. Any node, which
adds cost, latency or latency variation information to an LSP adds cost, latency or latency variation information to an LSP
during initial setup, needs to signal changes to these values to during initial setup, needs to signal changes to these values to
both endpoints. both endpoints.
3. RSVP-TE signaling extensions 3. RSVP-TE signaling extensions
3.1. Cost Collection Flag 3.1. Cost, Latency and Latency Variation Collection Flags
In order to indicate that cost collection is desired, a new
flag in the Attribute Flags TLV, which can be carried in an
LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Objects, is required:
- Cost Collection flag (to be assigned by IANA, recommended bit Three Attribute flags are defined in the Attribute Flags TLV,
position 11) which can be set and carried in either the LSP_ATTRIBUTES or
LSP_REQUIRED_ATTRIBUTES Objects.
The Cost Collection flag is meaningful in a Path message. If - Cost Collection flag (to be assigned by IANA)
the Cost Collection flag is set to 1, the transit nodes SHOULD
report the cost information in the Path Record Route Object
(RRO) and the Resv RRO.
The procedure for processing the Attribute Flags TLV follows - Latency Collection flag (to be assigned by IANA)
[RFC5420].
Internet-Draft draft-ietf-ccamp-te-metric-recording-01.txt - Latency Variation Collection flag (to be assigned by IANA)
3.2. Latency Collection Flag These flags are meaningful in a Path message. If the Cost
Collection flag is set to 1, the transit nodes SHOULD report the
cost information in the Record Route Objects (RRO) of both the
Path and Resv messages.
In order to indicate that latency collection is desired, a Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
new flag in the Attribute Flags TLV, which can be carried in an
LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Object, is required:
- Latency Collection flag (to be assigned by IANA, recommended If the Cost Collection flag is set to 1, the transit nodes
bit position 12) SHOULD report latency variation information in the Record Route
Objects (RRO) of both the Path and Resv messages.
The Latency Collection flag is meaningful in a Path message.
If the Latency Collection flag is set to 1, the transit nodes If the Latency Collection flag is set to 1, the transit nodes
SHOULD report the latency information in the Path RRO SHOULD report latency variation information in the Record Route
(ROUTE_RECORD Object) and the Resv RRO. Objects (RRO) of both the Path and Resv messages.
The procedure for the processing the Attribute Flags TLV follows
[RFC5420].
3.3. Latency Variation Collection Flag
In order to indicate that latency variation collection is
desired, a new flag in the Attribute Flags TLV, which can be
carried in an LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Object,
is required:
Latency Variation Collection flag (to be assigned by IANA,
recommended bit position 13)
The Latency Variation Collection flag is meaningful in a Path If the Latency Variation Collection flag is set to 1, the
message. If the Latency Variation Collection flag is set to 1, transit nodes SHOULD report latency variation information in the
the transit nodes SHOULD report the latency variation Record Route Objects (RRO) of both the Path and Resv messages.
information in the Path RRO and the Resv RRO.
The procedure for the processing the Attribute Flags TLV follows The procedure for the processing the Attribute Flags TLV follows
[RFC5420]. [RFC5420].
3.4. Cost Subobject 3.2. Cost Subobject
A new cost subobject is defined for the RRO to record the The cost subobject is defined for the RRO to record the cost
cost information of the LSP. Its format is similar to the RRO information of the LSP. Its format is similar to the RRO
subobjects (ROUTE_RECORD sub-object) defined in [RFC3209]. subobjects (ROUTE_RECORD sub-object) defined in [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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| COST Value | | Downstream Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the subobject, to be assigned by IANA Type: TBA1 - Cost subobject (to be assigned by IANA).
(recommended value 35).
Internet-Draft draft-ietf-ccamp-te-metric-recording-01.txt
Length: The Length value is set to 8. Length: The Length value is set to 8 or 12 depending on the
presence of Upstream Cost information.
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 when sent and MUST be ignored when received. set to 0 when sent and MUST be ignored when received.
Cost Value: Cost of the link along the route of the LSP. Downstream Cost: Cost of the local link along the route of
Based on the policy at the recording node, the cost value can the LSP in the direction of the tail-end node, encoded as a
be set to the Interior Gateway Protocol (IGP) metric or TE 32-bit integer. Based on the policy at the recording node,
metric of the link in question. This approach has been taken the cost value can be set to the Interior Gateway Protocol
to avoid defining a flag for each cost type in the Attribute- (IGP) metric or TE metric of the link in question. This
Flags TLV. It is assumed that, based on policy, all nodes approach has been taken to avoid defining a flag for each
report the same cost-type and that the ingress and egress cost type in the Attribute-Flags TLV. It is assumed that,
nodes know the cost type reported in the RRO. based on policy, all nodes report the same cost-type and that
Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
The rules for processing the LSP_ATTRIBUTES and the ingress and egress nodes know the cost type reported in
LSP_REQUIRED_ATTRIBUTES Objects and RRO are not changed. the RRO.
3.5. Latency Subobject 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. Based on the policy at the recording node, the
cost value can be set to the Interior Gateway Protocol (IGP)
metric or TE metric of the link in question. This approach
has been taken to avoid defining a flag for each cost type in
the Attribute-Flags TLV. It is assumed that, based on policy,
all nodes report the same cost-type and that the ingress and
egress nodes know the cost type reported in the RRO.
A new Latency subobject is defined for RRO to record the latency 3.3. Latency Subobject
The Latency subobject is defined for RRO to record the latency
information of the LSP. Its format is similar the RRO subobjects information of the LSP. Its format is similar the RRO subobjects
defined in [RFC3209]. defined in [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 | Delay | |A| Reserved | Downstream Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Upstream Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the subobject, to be assigned by IANA Type: TBA2 - Latency subobject (to be assigned by IANA).
(recommended value 36).
Length: The Length value is set to 8. Length: 8 or 12 depending on the presence of Upstream Cost
information.
A-bit: This field represents the Anomalous (A) bit, as A-bit: These fields represent the Anomalous (A) bit
defined in [DRAFT-OSPF-TE-METRIC]. associated with the Downstream and Upstream Delay
respectively, as defined in [DRAFT-OSPF-TE-METRIC].
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 Value: This 24-bit field carries the average link delay Downstream Delay: Delay of the local link along the route of
over a configurable interval in microseconds, encoded as an the LSP in the direction of the tail-end node, encoded as 24-
integer value. When set to 0, it has not been measured. When bit integer. When set to 0, it has not been measured. When
set to the maximum value 16,777,215 (16.777215 sec), the 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.
Internet-Draft draft-ietf-ccamp-te-metric-recording-01.txt Upstream Delay: Delay of the local link along the route of
the LSP in the direction of the head-end node, encoded as 24-
Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
The rules for processing the LSP_ATTRIBUTES and bit integer. When set to 0, it has not been measured. When
LSP_REQUIRED_ATTRIBUTES Objects and RRO are not changed. set to the maximum value 16,777,215 (16.777215 sec), the
delay is at least that value and may be larger.
3.6. Latency Variation Subobject 3.4. Latency Variation Subobject
A new Latency Variation subobject is defined for RRO to The Latency Variation subobject is defined for RRO to record the
record the Latency Variation information of the LSP. Its format Latency Variation information of the LSP. Its format is similar
is similar to the RRO subobjects defined in [RFC3209]. to the RRO subobjects defined in [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 | Delay Variation | |A| Reserved | Downstream Delay Variation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Upstream Delay Variation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the subobject, to be assigned by IANA Type: TBA3 - Latency Variation subobject (to be assigned by
(recommended value 37). IANA).
Length: The Length value is set to 8. Length: 8 or 12 depending on the presence of Upstream Latency
Variation information.
A-bit: This field represents the Anomalous (A) bit, as A-bit: These fields represent the Anomalous (A) bit
defined in [DRAFT-OSPF-TE-METRIC]. associated with the Downstream and Upstream Delay
respectively, as defined in [DRAFT-OSPF-TE-METRIC].
Reserved: These fields are reserved for future use. It MUST Reserved: These fields are reserved for future use. It 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 Variation Value: This 24-bit field carries the average Downstream Delay Variation: Delay Variation of the local link
link delay variation over a configurable interval in micro- along the route of the LSP in the direction of the tail-end
seconds, encoded as an integer value. When set to 0, it has node, encoded as 24-bit integer. When set to 0, it has not
not been measured. When set to the maximum value 16,777,215 been measured. When set to the maximum value 16,777,215
(16.777215 sec), then the delay is at least that value and (16.777215 sec), the delay is at least that value and may be
may be larger. larger.
The rules for processing the LSP_ATTRIBUTES and Upstream Delay Variation: Delay Variation of the local link
LSP_REQUIRED_ATTRIBUTES Objects and RRO are not changed. 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
(16.777215 sec), the delay is at least that value and may be
larger.
3.7. Signaling Procedures Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
Typically, the ingress node learns the route of an LSP by 3.5. Signaling Procedures
adding a RRO in the Path message. If an ingress node also
desires cost, latency and/or latency variation recording, it Typically, the ingress node learns the route of an LSP by adding
sets the appropriate flag(s) in the Attribute Flags TLV of the a RRO in the Path message. If an ingress node also desires cost,
latency and/or latency variation recording, it sets the
appropriate flag(s) in the Attribute Flags TLV of the
LSP_ATTRIBUTES (if recording is desired but not mandatory) or LSP_ATTRIBUTES (if recording is desired but not mandatory) or
LSP_REQUIRED_ATTRIBUTES (if recording in mandatory) Object. LSP_REQUIRED_ATTRIBUTES (if recording in mandatory) Object.
None, all or any of the Cost Collection, Latency Collection or None, all or any of the Cost Collection, Latency Collection or
Latency Variation Collection flags may be set in the Attribute Latency Variation Collection flags may be set in the Attribute
Flags TLV of the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Flags TLV of the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES
Object. Object. The rules for processing the LSP_ATTRIBUTES and
LSP_REQUIRED_ATTRIBUTES Objects and RRO are not changed. The
Internet-Draft draft-ietf-ccamp-te-metric-recording-01.txt corresponding sub-objects MUST be included in the RRO, with the
Downstream (only) information filled in.
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, Latency and/or LSP_REQUIRED_ATTRIBUTES Object and the Cost, Latency and/or
Latency Variation Collection Flag(s) is (are) set, if local Latency Variation Collection Flag(s) is (are) set, if local
policy disallows providing the requested information to the policy disallows providing the requested information to the
endpoints, the node MUST return a Path Error message with error endpoints, the node MUST return a Path Error message with error
code "Policy Control Failure (2)" and one of the following error code "Policy Control Failure (2)" and one of the following error
subcodes: subcodes:
. "Cost Recoding Rejected" (value to be assigned by IANA, . "Cost Recoding Rejected" (value to be assigned by IANA,
suggest value 105) if Cost Collection Flag is set. suggested value 105) if Cost Collection Flag is set.
. "Latency Recording Rejected" (value to be assigned by IANA, . "Latency Recording Rejected" (value to be assigned by IANA,
suggest value 106) if Latency Collection Flag is set. suggested value 106) if Latency Collection Flag is set.
. "Latency Variation Recording Rejected" (value to be assigned . "Latency Variation Recording Rejected" (value to be assigned
by IANA, suggest value 107) if Latency Variation Collection by IANA, suggested value 107) if Latency Variation Collection
Flag is set. Flag is set.
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, Latency and/or Latency LSP_ATTRIBUTES Object and the Cost, Latency and/or Latency
Variation Collection Flag(s) is (are) set, if local policy Variation Collection Flag(s) is (are) set, if local policy
disallows providing the requested information to the endpoints, disallows providing the requested information to the endpoints,
the Path message SHOULD NOT rejected due to Metric recording the Path message SHOULD NOT rejected due to Metric recording
restriction and the Path message is forwarded without the restriction and the Path message is forwarded without the
appropriate sub-object(s) in the Path RRO. appropriate sub-object(s) in the Path RRO.
If local policy permits the recording of the requested If local policy permits the recording of the requested
information, the processing node SHOULD add the requested information, the processing node SHOULD add the requested
subobject(s) with the cost, latency or/ and latency variation subobject(s) with the cost, latency and/or latency variation
metric value(s) associated with the local hop to the Path RRO. metric value(s) associated with the local hop to the Path RRO.
It then forwards the Path message to the next node in the If the LSP being setup is bidirectional, both Downstream and
downstream direction. Upstream information SHOULD be included. If the LSP is
unidirectional, only Downstream information SHOULD be included.
Following the steps described above, the intermediate nodes of
the LSP provide the requested metric value(s) associated with
Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
Following the steps described above, the intermediate nodes
of the LSP provide the requested metric value(s) associated with
the local hop in the Path RRO. When the egress node receives the the local hop in the Path RRO. When the egress node receives the
Path message, it can calculate the end-to-end cost, latency Path message, it can calculate the end-to-end cost, latency
and/or latency variation properties of the LSP. and/or latency variation properties of the LSP.
Before the Resv message is sent to the upstream node, the Before the Resv message is sent to the upstream node, the egress
egress node adds the requested subobject(s) with the cost, node adds the requested subobject(s) with the downstream cost,
latency or/ and latency variation metric value(s) associated latency and/or latency variation metric value(s) associated with
with the local hop to the Resv RRO in a similar manner to that the local hop to the Resv RRO in a similar manner to that
specified above for the addition of Path RRO sub-objects by specified above for the addition of Path RRO sub-objects by
transit nodes. transit nodes.
Similarly, the intermediate nodes of the LSP provide the Similarly, the intermediate nodes of the LSP provide the
requested metric value(s) associated with the local hop in the requested metric value(s) associated with the local hop in the
Resv RRO. When the ingress node receives the Resv message, it can Resv RRO. When the ingress node receives the Resv message, it can
calculate the end-to-end cost, latency or/ and latency variation calculate the end-to-end cost, latency and/or latency variation
properties of the LSP. properties of the LSP.
Internet-Draft draft-ietf-ccamp-te-metric-recording-01.txt
Typically, cost and latency are additive metrics, but latency Typically, cost and latency are additive metrics, but latency
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, latency
and latency variation metric from information recorded in the and latency variation metric from information recorded in the
RRO is beyond the scope of this document. RRO 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, latency and/or latency advertise the calculated end-to-end cost, latency and/or latency
variation properties of the FA/ RA LSP in TE link advertisement variation properties of the FA or RA LSP in TE link
to the routing instance based on the procedure described in advertisement to the routing instance based on the procedure
[DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. described in [DRAFT-OSPF-TE-METRIC], [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 removed as a single cost, latency and latency variation data removed as a single
value for each for the loose hop that is summarized by the value for each for the loose hop that is summarized by the
transit node. How a transit node calculates the cost, latency transit node. How a transit node calculates the cost, latency o
or/ and latency variation metric for the segment summarized by and/or latency variation metric for the segment summarized by
the transit node is beyond the scope of this document. the transit node is beyond the scope of this document.
4. Security Considerations 4. Security Considerations
This document does not introduce any additional security issues This document does not introduce any additional security issues
above those identified in [RFC5920], [RFC5420], [RFC2205], above those identified in [RFC5920], [RFC5420], [RFC2205],
[RFC3209], and [RFC3473]. [RFC3209], and [RFC3473].
5. IANA Considerations 5. IANA Considerations
5.1. RSVP Attribute Bit Flags 5.1. RSVP Attribute Bit Flags
The IANA has created a registry and manages the space of The IANA has created a registry and manages the space of
attributes bit flags of Attribute Flags TLV as described in attributes bit flags of Attribute Flags TLV as described in
section 11.3 of [RFC5420]. It is requested that the IANA makes section 11.3 of [RFC5420]. It is requested that the IANA makes
Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
assignments from the Attribute Bit Flags defined in this assignments from the Attribute Bit Flags defined in this
document. document.
This document introduces the following three new Attribute This document introduces the following three new Attribute
Bit Flag: Bit Flag:
- Bit number: TBD (recommended bit position 11) - Bit number: TBD (recommended bit position 11)
- Defining RFC: this I-D - Defining RFC: this I-D
- Name of bit: Cost Collection Flag - Name of bit: Cost Collection Flag
- Bit number: TBD (recommended bit position 12) - Bit number: TBD (recommended bit position 12)
- Defining RFC: this I-D - Defining RFC: this I-D
Internet-Draft draft-ietf-ccamp-te-metric-recording-01.txt
- Name of bit: Latency Collection Flag - Name of bit: Latency Collection Flag
- Bit number: TBD (recommended bit position 13) - Bit number: TBD (recommended bit position 13)
- Defining RFC: this I-D - Defining RFC: this I-D
- Name of bit: Latency Variation Flag - Name of bit: Latency Variation Flag
5.2. ROUTE_RECORD subobject 5.2. ROUTE_RECORD subobject
skipping to change at page 10, line 36 skipping to change at page 11, line 4
TBD (37) Latency Variation subobject This I-D TBD (37) Latency Variation subobject This I-D
5.2. New RSVP error sub-code 5.2. New RSVP error sub-code
For Error Code = 2 "Policy Control Failure" (see [RFC2205]) the For Error Code = 2 "Policy Control Failure" (see [RFC2205]) the
following sub-code is defined. following sub-code is defined.
Sub-code Value Sub-code Value
-------- ----- -------- -----
Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
Cost Recoding Rejected To be assigned by IANA. Cost Recoding Rejected To be assigned by IANA.
Suggested Value: 105. Suggested Value: 105.
Latency Recoding Rejected To be assigned by IANA. Latency Recoding Rejected To be assigned by IANA.
Suggested Value: 106. Suggested Value: 106.
Latency Variation Recoding Rejected To be assigned by IANA. Latency Variation Recoding Rejected To be assigned by
IANA.
Suggested Value: 107. Suggested Value: 107.
6. Acknowledgments 6. 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-ccamp-te-metric-recording-01.txt
7. References 7. References
7.1. Normative References 7.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.
skipping to change at page 11, line 31 skipping to change at page 11, line 46
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. [DRAFT-OSPF-TE-METRIC] S. Giacalone, D. Ward, J. Drake, A.
Atlas, S. Previdi, "OSPF Traffic Engineering (TE) Atlas, S. Previdi, "OSPF Traffic Engineering (TE)
Metric Extensions", draft-ietf-ospf-te-metric- Metric Extensions", draft-ietf-ospf-te-metric-
extensions, work in progress. 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-previdi- Engineering (TE) Metric Extensions", draft-ietf-isis-
isis-te-metric-extensions, work in progress. te-metric-extensions, work in progress.
[DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C.
Margaria,, "RSVP-TE Extensions for Collecting SRLG Margaria,, "RSVP-TE Extensions for Collecting SRLG
Information", draft-ietf-ccamp-rsvp-te-srlg- Information", draft-ietf-ccamp-rsvp-te-srlg-
collect.txt, work in progress. collect.txt, work in progress.
Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
7.2. Informative References 7.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.
Authors' Addresses Authors' Addresses
Internet-Draft draft-ietf-ccamp-te-metric-recording-01.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. 82 change blocks. 
194 lines changed or deleted 193 lines changed or added

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