draft-ietf-ccamp-crankback-05.txt   draft-ietf-ccamp-crankback-06.txt 
Network Working Group A. Farrel (Editor)
Network Working Group Adrian Farrel (editor)
Internet Draft Old Dog Consulting Internet Draft Old Dog Consulting
Category: Standards Track Category: Standards Track
Expires: November 2005 Arun Satyanarayana Expires: July 2007 A. Satyanarayana
Cisco Systems, Inc. Cisco Systems, Inc.
Atsushi Iwata A. Iwata
Norihito Fujita N. Fujita
NEC Corporation NEC Corporation
Gerald R. Ash G. Ash
AT&T AT&T
Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
<draft-ietf-ccamp-crankback-05.txt> January 2007
Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
<draft-ietf-ccamp-crankback-06.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be The list of Internet-Draft Shadow Directories can be accessed at
accessed at http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
In a distributed, constraint-based routing environment, the In a distributed, constraint-based routing environment, the
information used to compute a path may be out of date. This means information used to compute a path may be out of date. This means
that Multiprotocol Label Switching (MPLS) and Generalized MPLS that Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
requests may be blocked by links or nodes without sufficient requests may be blocked by links or nodes without sufficient
resources. Crankback is a scheme whereby setup failure information is resources. Crankback is a scheme whereby setup failure information is
returned from the point of failure to allow new setup attempts to be returned from the point of failure to allow new setup attempts to be
skipping to change at line 76 skipping to change at line 78
1. Terminology......................................................3 1. Terminology......................................................3
1.1. Control Plane and Data Plane Separation........................3 1.1. Control Plane and Data Plane Separation........................3
2. Introduction and Framework.......................................4 2. Introduction and Framework.......................................4
2.1. Background.....................................................4 2.1. Background.....................................................4
2.2. Repair and Recovery............................................5 2.2. Repair and Recovery............................................5
2.3. Interaction with TE Flooding Mechanisms .......................6 2.3. Interaction with TE Flooding Mechanisms .......................6
3. Discussion: Explicit Versus Implicit Re-routing Indications......6 3. Discussion: Explicit Versus Implicit Re-routing Indications......6
4. Required Operation...............................................7 4. Required Operation...............................................7
4.1. Resource Failure or Unavailability.............................7 4.1. Resource Failure or Unavailability.............................7
4.2. Computation of an Alternate Path...............................7 4.2. Computation of an Alternate Path...............................8
4.2.1 Information Required for Re-routing...........................8 4.2.1 Information Required for Re-routing...........................8
4.2.2 Signaling a New Route.........................................8 4.2.2 Signaling a New Route.........................................9
4.3. Persistence of Error Information...............................9 4.3. Persistence of Error Information...............................9
4.4. Handling Re-route Failure......................................9 4.4. Handling Re-route Failure.....................................10
4.5. Limiting Re-routing Attempts..................................10 4.5. Limiting Re-routing Attempts..................................10
5. Existing Protocol Support for Crankback Re-routing..............10 5. Existing Protocol Support for Crankback Re-routing..............11
5.1. RSVP-TE ......................................................11 5.1. RSVP-TE ......................................................11
5.2. GMPLS-RSVP-TE ................................................11 5.2. GMPLS-RSVP-TE ................................................12
Section B : Solution Section B : Solution
6. Control of Crankback Operation..................................12 6. Control of Crankback Operation..................................12
6.1. Requesting Crankback and Controlling In-Network Re-routing....12 6.1. Requesting Crankback and Controlling In-Network Re-routing....12
6.2. Action on Detecting a Failure.................................13 6.2. Action on Detecting a Failure.................................13
6.3. Limiting Re-routing Attempts..................................13 6.3. Limiting Re-routing Attempts..................................13
6.3.1 New Status Codes for Re-routing..............................13 6.3.1 New Status Codes for Re-routing..............................13
6.4. Protocol Control of Re-routing Behavior.......................13 6.4. Protocol Control of Re-routing Behavior.......................14
7. Reporting Crankback Information.................................14 7. Reporting Crankback Information.................................14
7.1. Required Information..........................................14 7.1. Required Information..........................................14
7.2. Protocol Extensions...........................................14 7.2. Protocol Extensions...........................................14
7.3 Guidance for Use of IF_ID Error Spec TLVs......................18 7.3 Guidance for Use of IF_ID Error Spec TLVs......................18
7.3.1 General Principles...........................................18 7.3.1 General Principles...........................................18
7.3.2 Error Report TLVs............................................19 7.3.2 Error Report TLVs............................................19
7.3.3 Fundamental Crankback TLVs...................................19 7.3.3 Fundamental Crankback TLVs...................................19
7.3.4 Additional Crankback TLVs....................................20 7.3.4 Additional Crankback TLVs....................................20
7.3.5 Grouping TLVs by Failure Location............................21 7.3.5 Grouping TLVs by Failure Location............................21
7.3.6 Alternate Path identification................................22 7.3.6 Alternate Path identification................................22
7.4. Action on Receiving Crankback Information.....................22 7.4. Action on Receiving Crankback Information.....................22
7.4.1 Re-route Attempts............................................22 7.4.1 Re-route Attempts............................................22
7.4.2 Location Identifiers of Blocked Links or Nodes...............22 7.4.2 Location Identifiers of Blocked Links or Nodes...............23
7.4.3 Locating Errors within Loose or Abstract Nodes...............23 7.4.3 Locating Errors within Loose or Abstract Nodes...............23
7.4.4 When Re-routing Fails........................................23 7.4.4 When Re-routing Fails........................................23
7.4.5 Aggregation of Crankback Information.........................23 7.4.5 Aggregation of Crankback Information.........................24
7.5. Notification of Errors........................................24 7.5. Notification of Errors........................................24
7.5.1 ResvErr Processing...........................................24 7.5.1 ResvErr Processing...........................................24
7.5.2 Notify Message Processing....................................24 7.5.2 Notify Message Processing....................................25
7.6. Error Values..................................................25 7.6. Error Values..................................................25
7.7. Backward Compatibility........................................25 7.7. Backward Compatibility........................................25
8. LSP Recovery Considerations.....................................25 8. LSP Recovery Considerations.....................................26
8.1. Upstream of the Fault.........................................26 8.1. Upstream of the Fault.........................................26
8.2. Downstream of the Fault.......................................26 8.2. Downstream of the Fault.......................................27
9. IANA Considerations.............................................27 9. IANA Considerations.............................................27
9.1. Error Codes...................................................27 9.1. Error Codes...................................................27
9.2. IF_ID_ERROR_SPEC TLVs.........................................27 9.2. IF_ID_ERROR_SPEC TLVs.........................................27
9.3. LSP_ATTRIBUTES Object.........................................27 9.3. LSP_ATTRIBUTES Object.........................................28
10. Security Considerations........................................27 10. Security Considerations........................................28
11. Acknowledgments................................................28 11. Acknowledgments................................................29
12. Intellectual Property Considerations...........................28 12. Normative References...........................................30
13. Normative References...........................................28 13. Informational References.......................................30
14. Informational References.......................................29 14. Authors' Addresses.............................................31
15. Authors' Addresses.............................................30 A. Experience of Crankback in TDM-based Networks..................34
16. Disclaimer of Validity.........................................30
17. Full Copyright Statement.......................................31
A. Experience of Crankback in TDM-based Networks..................32
Section A : Problem Statement Section A : Problem Statement
1. Terminology 1. Terminology
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 this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.1. Control Plane and Data Plane Separation 1.1. Control Plane and Data Plane Separation
skipping to change at line 345 skipping to change at line 344
error message response with the location identifier of the blockage error message response with the location identifier of the blockage
should be returned to the LSR initiating the LSP setup (ingress LSR), should be returned to the LSR initiating the LSP setup (ingress LSR),
the area border LSR, the AS border LSR, or to some other repair the area border LSR, the AS border LSR, or to some other repair
point. point.
This error message carries an error specification according to This error message carries an error specification according to
[RFC3209] - this indicates the cause of the error and the node/link [RFC3209] - this indicates the cause of the error and the node/link
on which the error occurred. Crankback operation may require further on which the error occurred. Crankback operation may require further
information as detailed in sections 4.2.1 and 7. information as detailed in sections 4.2.1 and 7.
A repair point (for example, an ingress LSR) that receives crankback
information resulting from the failure of an established LSP may
apply local policy to govern how it attempts repair of the LSP. For
example, it may prioritise repair attempts between multiple LSPs that
have failed, and it may consider LSPs that have been locally repaired
([RFC4090]) to be less urgent candidates for end-to-end repair.
Further, there is a likelihood that other LSRs are also attempting
LSP repair for LSPs affected by the same fault which may give rise to
resource contention within the network, so an LSR may stagger its
repair attempts in order to reduce the chance of resource contention.
4.2. Computation of an Alternate Path 4.2. Computation of an Alternate Path
In a flat network without partitioning of the routing topology, when In a flat network without partitioning of the routing topology, when
the ingress LSR receives the error message it computes an alternate the ingress LSR receives the error message it computes an alternate
path around the blocked link or node to satisfy QoS guarantees using path around the blocked link or node to satisfy QoS guarantees using
link state information about the network. If an alternate path is link state information about the network. If an alternate path is
found, a new LSP setup request is sent over this path. found, a new LSP setup request is sent over this path.
On the other hand, in a network partitioned into areas such as with On the other hand, in a network partitioned into areas such as with
OSPF, the area border LSR may intercept and terminate the error OSPF, the area border LSR may intercept and terminate the error
skipping to change at line 368 skipping to change at line 378
In a third scenario, any node within an area may act as a repair In a third scenario, any node within an area may act as a repair
point. In this case, each LSR behaves much as an area border LSR as point. In this case, each LSR behaves much as an area border LSR as
described above. It can intercept and terminate the error response, described above. It can intercept and terminate the error response,
and perform alternate routing. This may be particularly useful where and perform alternate routing. This may be particularly useful where
domains of computation are applied within the (partitioned) network, domains of computation are applied within the (partitioned) network,
where such domains are not coincident on the routing partition where such domains are not coincident on the routing partition
boundaries. However if, all nodes in the network perform re-routing boundaries. However if, all nodes in the network perform re-routing
it is possible to spend excessive network and CPU resources on it is possible to spend excessive network and CPU resources on
re-routing attempts that would be better made only at designated re-routing attempts that would be better made only at designated
re-routing nodes. This scenario is somewhat like 'MPLS fast re-route' re-routing nodes. This scenario is somewhat like 'MPLS fast re-route'
[FASTRR], in which any node in the MPLS domain can establish 'local [RFC4090], in which any node in the MPLS domain can establish 'local
repair' LSPs upon failure notification. repair' LSPs upon failure notification.
4.2.1 Information Required for Re-routing 4.2.1 Information Required for Re-routing
In order to correctly compute a route that avoids the blocking In order to correctly compute a route that avoids the blocking
problem, a repair point LSR must gather as much crankback information problem, a repair point LSR must gather as much crankback information
as possible. Ideally, the repair node will be given the node, link as possible. Ideally, the repair node will be given the node, link
and reason for the failure. and reason for the failure.
The reason for the failure may provide an important discriminator to The reason for the failure may provide an important discriminator to
skipping to change at line 648 skipping to change at line 658
An error code/value of "Routing Problem"/"Re-routing limit exceeded" An error code/value of "Routing Problem"/"Re-routing limit exceeded"
(24/TBD) is used to identify that a node has abandoned crankback (24/TBD) is used to identify that a node has abandoned crankback
re-routing because it has reached a threshold for retry attempts. re-routing because it has reached a threshold for retry attempts.
A node receiving an error response with this status code MAY also A node receiving an error response with this status code MAY also
attempt crankback re-routing, but it is RECOMMENDED that such attempt crankback re-routing, but it is RECOMMENDED that such
attempts be limited to the ingress LSR. attempts be limited to the ingress LSR.
6.4. Protocol Control of Re-routing Behavior 6.4. Protocol Control of Re-routing Behavior
The LSP_ATTRIBUTES object defined in [LSP-ATTRIB] is used on Path The LSP_ATTRIBUTES object defined in [RFC4420] is used on Path
messages to convey the Re-Routing Flag described in section 5.1. messages to convey the Re-Routing Flag described in section 5.1.
Three bits are defined for inclusion in the LSP Attributes TLV as Three bits are defined for inclusion in the LSP Attributes TLV as
follows. The bit numbers below are suggested and actual values are follows. The bit numbers below are suggested and actual values are
TBD by IETF consensus. to be assigned by IANA.
Bit Name and Usage Bit Name and Usage
Number Number
1 End-to-end re-routing desired. 1 End-to-end re-routing desired.
This flag indicates the end-to-end re-routing behavior for an This flag indicates the end-to-end re-routing behavior for an
LSP under establishment. This MAY also be used for specifying LSP under establishment. This MAY also be used for specifying
the behavior of end-to-end LSP recovery for established LSPs. the behavior of end-to-end LSP recovery for established LSPs.
2 Boundary re-routing desired. 2 Boundary re-routing desired.
skipping to change at line 714 skipping to change at line 725
node. node.
Type Length Format Description Type Length Format Description
-------------------------------------------------------------------- --------------------------------------------------------------------
1 8 IPv4 Addr. IPv4 (Interface address) 1 8 IPv4 Addr. IPv4 (Interface address)
2 20 IPv6 Addr. IPv6 (Interface address) 2 20 IPv6 Addr. IPv6 (Interface address)
3 12 Compound IF_INDEX (Interface index) 3 12 Compound IF_INDEX (Interface index)
4 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface) 4 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 Compound COMPONENT_IF_UPSTREAM (Component interface) 5 12 Compound COMPONENT_IF_UPSTREAM (Component interface)
Note that TLVs 4 and 5 are obsoleted by [BUNDLE] and SHOULD NOT be Note that TLVs 4 and 5 are obsoleted by [RFC4201] and SHOULD NOT be
used to identify component interfaces in IF_ID ERROR_SPEC objects. used to identify component interfaces in IF_ID ERROR_SPEC objects.
In order to facilitate reporting of crankback information, the In order to facilitate reporting of crankback information, the
following additional TLVs are defined. Note that the Type values following additional TLVs are defined. Note that the Type values
shown here are only suggested values - final values are TBD and to be shown here are only suggested values - final values are TBD and to be
determined by IETF consensus. determined by IETF consensus.
Type Length Format Description Type Length Format Description
-------------------------------------------------------------------- --------------------------------------------------------------------
6 var See below DOWNSTREAM_LABEL (GMPLS label) 6 var See below DOWNSTREAM_LABEL (GMPLS label)
skipping to change at line 842 skipping to change at line 853
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ERO Subobjects ~ ~ ERO Subobjects ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ERO Subobjects: ERO Subobjects:
A sequence of ERO subobjects. Any ERO subobjects are allowed A sequence of ERO subobjects. Any ERO subobjects are allowed
whether defined in [RFC3209], [RFC3473] or other documents. whether defined in [RFC3209], [RFC3473] or other documents.
Note that ERO subobjects contain their own type and length Note that ERO subobjects contain their own types and lengths.
fields.
For type 26 the Value field has the format: For type 26 the Value field has the format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Node Identifiers ~ ~ Node Identifiers ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 886 skipping to change at line 896
1, 2 or 3 TLVs that indicate incoming interfaces at downstream 1, 2 or 3 TLVs that indicate incoming interfaces at downstream
nodes that have already participated in crankback attempts and nodes that have already participated in crankback attempts and
have been declared unusable for the current LSP setup attempt. have been declared unusable for the current LSP setup attempt.
7.3 Guidance for Use of IF_ID ERROR_SPEC TLVs 7.3 Guidance for Use of IF_ID ERROR_SPEC TLVs
7.3.1 General Principles 7.3.1 General Principles
If crankback is not being used, inclusion of an IF-ID ERROR_SPEC If crankback is not being used, inclusion of an IF-ID ERROR_SPEC
object in PathErr, ResvErr and Notify messages follows the processing object in PathErr, ResvErr and Notify messages follows the processing
rules defined in [RFC3473] and [BUNDLE]. A sender MAY include rules defined in [RFC3473] and [RFC4201]. A sender MAY include
additional TLVs of types 6 through 27 to report crankback information additional TLVs of types 6 through 27 to report crankback information
for informational/monitoring purposes. for informational/monitoring purposes.
If crankback is being used, the sender of a PathErr, ResvErr or If crankback is being used, the sender of a PathErr, ResvErr or
Notify message MUST use the IF_ID ERROR_SPEC object and MUST include Notify message MUST use the IF_ID ERROR_SPEC object and MUST include
at least one of the TLVs in the range 1 through 3 as described in at least one of the TLVs in the range 1 through 3 as described in
[RFC3473], [BUNDLE], and the previous paragraph. Additional TLVs [RFC3473], [RFC4201], and the previous paragraph. Additional TLVs
SHOULD also be included to report further information. The following SHOULD also be included to report further information. The following
section gives advice on which TLVs should be used under different section gives advice on which TLVs should be used under different
circumstances, and which TLVs must be supported by LSRs. circumstances, and which TLVs must be supported by LSRs.
Note that all such additional TLVs are optional and MAY be omitted. Note that all such additional TLVs are optional and MAY be omitted.
Inclusion of the optional TLVs SHOULD be performed where doing so Inclusion of the optional TLVs SHOULD be performed where doing so
helps to facilitate error reporting and crankback. The TLVs fall into helps to facilitate error reporting and crankback. The TLVs fall into
three categories: those that are essential to report the error, those three categories: those that are essential to report the error, those
that provide additional information that is or may be fundamental to that provide additional information that is or may be fundamental to
the utility of crankback, and those that provide additional the utility of crankback, and those that provide additional
information that may be useful for crankback in some circumstances. information that may be useful for crankback in some circumstances.
Note that all LSRs MUST be prepared to receive and forward any TLV as Note that all LSRs MUST be prepared to receive and forward any TLV as
per [RFC3473]. This includes TLVs of type 4 or 5 as defined in per [RFC3473]. This includes TLVs of type 4 or 5 as defined in
[RFC3473] and obsoleted by [BUNDLE]. There is, however, no [RFC3473] and obsoleted by [RFC4201]. There is, however, no
requirement for an LSR to actively process any but the TLVs defined requirement for an LSR to actively process any but the TLVs defined
in [RFC3473]. An LSR that proposes to perform crankback re-routing in [RFC3473]. An LSR that proposes to perform crankback re-routing
SHOULD support receipt and processing of all of the fundamental SHOULD support receipt and processing of all of the fundamental
crankback TLVs, and is RECOMMENDED to support the receipt and crankback TLVs, and is RECOMMENDED to support the receipt and
processing of the additional crankback TLVs. processing of the additional crankback TLVs.
It should be noted, however, that some assumptions about the TLVs It should be noted, however, that some assumptions about the TLVs
that will be used MAY be made based on the deployment scenarios. For that will be used MAY be made based on the deployment scenarios. For
example, a router that is deployed in a single-area network does not example, a router that is deployed in a single-area network does not
need to support the receipt and processing of TLV types 22 and 23. need to support the receipt and processing of TLV types 22 and 23.
skipping to change at line 1323 skipping to change at line 1333
might also be made so as to better facilitate make-before-break might also be made so as to better facilitate make-before-break
repair. In this case a received PathTear might be 'absorbed' and not repair. In this case a received PathTear might be 'absorbed' and not
propagated further downstream for an LSP that has SE reservation propagated further downstream for an LSP that has SE reservation
style. Note, however, that this is a divergence from the protocol and style. Note, however, that this is a divergence from the protocol and
might severely impact normal tear-down of LSPs. might severely impact normal tear-down of LSPs.
9. IANA Considerations 9. IANA Considerations
9.1 Error Codes 9.1 Error Codes
A new error value is defined for the RSVP-TE "Routing Problem" error IANA maintains a registry called "RSVP Parameters" with a subregistry
code that is defined in [RFC3209]. called "Error Codes and Globally-Defined Error Value Sub-Codes". This
subregistry includes the RSVP-TE "Routing Problem" error code that is
defined in [RFC3209].
TBD Re-routing limit exceeded. IANA is requested to assign a new error value for the "Routing
Problem" error code as follows:
17 Re-routing limit exceeded.
The value of 17 is suggested and is for confirmation by IANA.
9.2 IF_ID_ERROR_SPEC TLVs 9.2 IF_ID_ERROR_SPEC TLVs
Note that the IF_ID_ERROR_SPEC TLV type values defined in [RFC3471] The IF_ID_ERROR_SPEC TLV type values defined in [RFC3471]
are not currently tracked by IANA. IANA is requested to form a are maintained by IANA in the "Interface_ID Types" sub-registry of
registry of these values. The new values proposed by this document the "GMPLS Signaling Parameters" registry.
are found in section 7.2.
IANA is requested to make new assignments from this subregistry for
the new TLV types defined in Section 7.2 of this document.
The text 'see below' may be replaced by 'see RFC' within the
subregistry to give a clear reference to the location of the
definition of the TLV format.
9.3 LSP_ATTRIBUTES Object 9.3 LSP_ATTRIBUTES Object
Three bits are defined for inclusion in the LSP Attributes TLV of IANA maintains an "RSVP TE Parameters" registry with an "Attributes
the LSP_ATTRIBUTES object in section 6.4. Suggested values are Flags" subregistry. IANA is requested to make three new allocations
supplied. IANA is requested to assign those bits. from this registry as listed in Section 6.4.
These bits are defined for inclusion in the LSP Attributes TLV of
the LSP_ATTRIBUTES. The values shown are suggested and are for
confirmation by IANA.
10. Security Considerations 10. Security Considerations
It should be noted that while the extensions in this document The RSVP-TE trust model assumes that RSVP-TE neighbors and peers
introduce no new security holes in the protocols, should a malicious trust each other to exchange ligitimate and non-malicious messages.
user gain protocol access to the network, the crankback information This assumption is necessary in order that the signaling protocol can
might be used to prevent establishment of valid LSPs. function.
The implementation of re-routing attempt thresholds are particularly Note that this trust model is assumed to cascade. That is, if an LSR
important in this context. trusts its neighbors, it extends this trust to all LSRs that its
The crankback routing extensions and procedures for LSP recovery neighbor trusts. This means that the trust model is usually applied
as applied to RSVP-TE introduce no further new security across the whole network to create a trust domain.
considerations. Refer to [RFC2205], [RFC3209] and [RFC3473] for a
description of applicable security considerations. Authentication of neighbor identity is already a standard provision
of RSVP-TE, as is the protection of messages against tampering and
spoofing. Refer to [RFC2205], [RFC3209], and [RFC3473] for a
description of applicable security considerations. These
considerations and mechanisms are applicable to hop-by-hop message
exchanges (such as used for crankback propagation on PathErr
messages) and directed message exchanges (such as used for crankback
propagation on Notify messages).
Key management may also be used with RSVP-TE to help to protect
against impersonation and also against message content falsification.
This requires the maintenance, exchange, and configuration of keys on
each LSR. Note that such maintenance may be especially onerous to
operators, hence it is important to limit the number of keys while
ensuring the required level of security.
This document does not introduce any protocol elements or message
exchanges that change the operation of RSVP-TE security.
However, it should be noted that crankback is envisaged as an
inter-domain mechanism, and as such it is likely that crankback
information is exchanged over trust domain borders. In these cases
it is expected that the information from within a neighboring
domain would be of little or no value to the node performing
crankback re-routing and would be ignored. In any case, it is highly
likely that the reporting domain will have applied some form of
information aggregation in order to preserve the confirentiality of
its network topology.
The issue of a direct attack by one domain upon another domain is
possible and domain administrators should apply policies to protect
their domains against the results of another domain attempting to
thrash LSPs by allowing them to set up before reporting them as
failed. On the whole, it is expected that commercial contracts
between trust domains will provide a degree of protection.
A more serious threat might arise if a domain reports that neither it
nor its downstream neighbor can provide a path to the destination.
Such a report could be bogus in that the reporting domain might not
have allowed the downstream domain the chance to attempt to provide a
path. (Note that the same problem does not arise for nodes within a
domain because of the trust model.) This type of malicious behavior
is hard to overcome, but may be detected by use of indirect path
computation requests send direct to the falsely reported domain using
mechanisms such as the Path Computation Element [RFC4655].
Note that a separate document describing inter-domain MPLS and GMPLS
security considerations will be produced.
Finally, it should be noted that while the extensions in this
document introduce no new security holes in the protocols, should a
malicious user gain protocol access to the network, the crankback
information might be used to prevent establishment of valid LSPs.
Thus, the existing security features available in RSVP-TE should be
carefully considered by all deployers and SHOULD be made available by
all implementations that offer cranback. Note that the implementation
of re-routing attempt thresholds are also particularly useful in this
context.
11. Acknowledgments 11. Acknowledgments
We would like to thank Juha Heinanen and Srinivas Makam for their We would like to thank Juha Heinanen and Srinivas Makam for their
review and comments, and Zhi-Wei Lin for his considered opinions. review and comments, and Zhi-Wei Lin for his considered opinions.
Thanks, too, to John Drake for encouraging us to resurrect this Thanks, too, to John Drake for encouraging us to resurrect this
document and consider the use of the IF_ID ERROR SPEC object. Thanks document and consider the use of the IF_ID ERROR SPEC object. Thanks
for a welcome and very thorough review by Dimitri Papadimitriou. for a welcome and very thorough review by Dimitri Papadimitriou.
Stephen Shew made useful comments for clarification through the Stephen Shew made useful comments for clarification through the
ITU-T liaison process. ITU-T liaison process.
Simon Marshall-Unitt made contributions to this draft. Simon Marshall-Unitt made contributions to this draft.
12. Intellectual Property Considerations SecDir review was provided by Tero Kivinen. Thanks to Ross Callon for
useful discussions of prioritization of crankback re-routing
The IETF takes no position regarding the validity or scope of any attempts.
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
13. Normative References 12. 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.
[RFC2205] R. Braden, et al., "Resource ReSerVation Protocol (RSVP) [RFC2205] R. Braden, et al., "Resource ReSerVation Protocol (RSVP)
Version 1 Functional Specification", RFC2205, September Version 1 Functional Specification", RFC2205, September
1997. 1997.
[RFC3209] D. Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP [RFC3209] D. Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209, December 2001. Tunnels", RFC3209, December 2001.
[RFC3471] P. Ashwood-Smith and L. Berger, et al., "Generalized [RFC3471] P. Ashwood-Smith and L. Berger, et al., "Generalized
MPLS - Signaling Functional Description", RFC 3471, MPLS - Signaling Functional Description", RFC 3471,
January 2003. January 2003.
[RFC3473] L. Berger, et al., "Generalized MPLS Signaling - RSVP-TE [RFC3473] L. Berger, et al., "Generalized MPLS Signaling - RSVP-TE
Extensions", RFC 3473, January 2003. Extensions", RFC 3473, January 2003.
[LSP-ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of [RFC4420] Farrel, A., et al, "Encoding of Attributes for
Attributes for Multiprotocol Label Switching (MPLS) Multiprotocol Label Switching (MPLS) Label Switched Path
Label Switched Path (LSP) Establishment Using RSVP-TE", (LSP) Establishment Using RSVP-TE", RFC 4420, February
draft-ietf-mpls-rsvpte-attributes, work in progress. 2006.
14. Informational References 13. Informational References
[ASH1] G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS [ASH1] G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS
Routing & Related Traffic Engineering Methods for IP-, Routing & Related Traffic Engineering Methods for IP-,
ATM-, & TDM-Based Multiservice Networks", May, 2002. ATM-, & TDM-Based Multiservice Networks", May, 2002.
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link [RFC2702] D. Awduche, et al., "Requirements for Traffic
Bundling in MPLS Traffic Engineering", Engineering Over MPLS", RFC2702, September 1999.
draft-ietf-mpls-bundle, work in progress.
[FASTRR] Ping Pan, et al., "Fast Reroute Extensions to RSVP-TE [RFC3469] V. Sharma, et al., "Framework for MPLS-based Recovery",
for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute, RFC 3469, February 2003.
work in progress.
[RFC4090] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels", RFC 4090, May 2005.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[G8080] ITU-T Recommendation G.808/Y.1304, Architecture for the [G8080] ITU-T Recommendation G.808/Y.1304, Architecture for the
Automatically Switched Optical Network (ASON), November Automatically Switched Optical Network (ASON), November
2001. For information on the availability of this 2001. For information on the availability of this
document, please see http://www.itu.int. document, please see http://www.itu.int.
[EXCLUDE] C-Y. Lee, A. Farrel and S De Cnodder, "Exclude Routes - [EXCLUDE] C-Y. Lee, A. Farrel and S. De Cnodder, "Exclude Routes -
Extension to RSVP-TE", Extension to RSVP-TE",
draft-ietf-ccamp-rsvp-te-exclude-route, work in draft-ietf-ccamp-rsvp-te-exclude-route, work in
progress. progress.
[PNNI] ATM Forum, "Private Network-Network Interface [PNNI] ATM Forum, "Private Network-Network Interface
Specification Version 1.0 (PNNI 1.0)", Specification Version 1.0 (PNNI 1.0)",
<af-pnni-0055.000>, May 1996. <af-pnni-0055.000>, May 1996.
[RFC2702] D. Awduche, et al., "Requirements for Traffic 14. Authors' Addresses
Engineering Over MPLS", RFC2702, September 1999.
[RFC3469] V. Sharma, et al., "Framework for MPLS-based Recovery",
RFC 3469, February 2003.
15. Authors' Addresses
Adrian Farrel (editor) Adrian Farrel (Editor)
Old Dog Consulting Old Dog Consulting
Phone: +44 (0) 1978 860944 Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Arun Satyanarayana Arun Satyanarayana
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
Phone: +1 408 853-3206 Phone: +1 408 853-3206
Email: asatyana@cisco.com Email: asatyana@cisco.com
skipping to change at line 1482 skipping to change at line 1545
E-Mail: a-iwata@ah.jp.nec.com E-Mail: a-iwata@ah.jp.nec.com
Norihito Fujita Norihito Fujita
NEC Corporation NEC Corporation
System Platforms Research Laboratories System Platforms Research Laboratories
1753 Shimonumabe Nakahara-ku, 1753 Shimonumabe Nakahara-ku,
Kawasaki, Kanagawa, 211-8666, JAPAN Kawasaki, Kanagawa, 211-8666, JAPAN
Phone: +81-(44)-396-2091 Phone: +81-(44)-396-2091
Fax: +81-(44)-431-7644 Fax: +81-(44)-431-7644
E-Mail: n-fujita@bk.jp.nec.com E-Mail: n-fujita@bk.jp.nec.com
Gerald R. Ash Gerald R. Ash
AT&T AT&T
Room MT D5-2A01 Room MT D5-2A01
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: (+1) 732-420-4578 Phone: (+1) 732-420-4578
Fax: (+1) 732-368-8659 Fax: (+1) 732-368-8659
EMail: gash@att.com EMail: gash@att.com
16. Disclaimer of Validity Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
17. Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The IETF Trust (2007).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Appendix A. Experience of Crankback in TDM-based Networks Appendix A. Experience of Crankback in TDM-based Networks
Experience of using release messages in TDM-based networks for Experience of using release messages in TDM-based networks for
analogous repair and re-routing purposes provides some guidance. analogous repair and re-routing purposes provides some guidance.
One can use the receipt of a release message with a cause value (CV) One can use the receipt of a release message with a cause value (CV)
indicating "link congestion" to trigger a re-routing attempt at the indicating "link congestion" to trigger a re-routing attempt at the
originating node. However, this sometimes leads to problems. originating node. However, this sometimes leads to problems.
 End of changes. 52 change blocks. 
117 lines changed or deleted 205 lines changed or added

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