draft-ietf-ccamp-crankback-02.txt   draft-ietf-ccamp-crankback-03.txt 
Network Working Group Adrian 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: January 2005 Arun Satyanarayana Expires: April 2005 Arun Satyanarayana
Movaz Networks, Inc. Movaz Networks, Inc.
Atsushi Iwata Atsushi Iwata
Norihito Fujita Norihito Fujita
NEC Corporation NEC Corporation
Gerald R. Ash (AT&T) Gerald R. Ash (AT&T)
Simon Marshall-Unitt October 2004
Data Connection Ltd.
July 2004
Crankback Signaling Extensions for MPLS Signaling Crankback Signaling Extensions for MPLS Signaling
<draft-ietf-ccamp-crankback-02.txt> <draft-ietf-ccamp-crankback-03.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
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 other
skipping to change at line 74 skipping to change at line 72
Section A : Problem Statement Section A : Problem Statement
1. Terminology......................................................3 1. Terminology......................................................3
2. Introduction and Framework.......................................3 2. Introduction and Framework.......................................3
2.1. Background.....................................................3 2.1. Background.....................................................3
2.2. Repair and Restoration.........................................4 2.2. Repair and Restoration.........................................4
3. Discussion: Explicit Versus Implicit Re-routing Indications......5 3. Discussion: Explicit Versus Implicit Re-routing Indications......5
4. Required Operation...............................................6 4. Required Operation...............................................6
4.1. Resource Failure or Unavailability.............................6 4.1. Resource Failure or Unavailability.............................6
4.2. Computation of an Alternate Path...............................6 4.2. Computation of an Alternate Path...............................6
4.2.1 Information Required for Re-routing...........................6 4.2.1 Information Required for Re-routing...........................7
4.2.2 Signaling a New Route.........................................7 4.2.2 Signaling a New Route.........................................7
4.3. Persistence of Error Information...............................7 4.3. Persistence of Error Information...............................7
4.4. Handling Re-route Failure......................................7 4.4. Handling Re-route Failure......................................7
4.5. Limiting Re-routing Attempts...................................8 4.5. Limiting Re-routing Attempts...................................8
5. Existing Protocol Support for Crankback Re-routing...............8 5. Existing Protocol Support for Crankback Re-routing...............8
5.1. RSVP-TE [RFC 3209].............................................9 5.1. RSVP-TE [RFC 3209].............................................9
5.2. GMPLS-RSVP-TE [RFC 3473].......................................9 5.2. GMPLS-RSVP-TE [RFC 3473].......................................9
Section B : Solution Section B : Solution
6. Control of Crankback Operation..................................10 6. Control of Crankback Operation..................................10
6.1. Requesting Crankback and Controlling In-Network Re-routing....10 6.1. Requesting Crankback and Controlling In-Network Re-routing....10
6.2. Action on Detecting a Failure.................................10 6.2. Action on Detecting a Failure.................................11
6.3. Limiting Re-routing Attempts..................................11 6.3. Limiting Re-routing Attempts..................................11
6.3.1 New Status Codes for Re-routing..............................11 6.3.1 New Status Codes for Re-routing..............................11
6.4. Protocol Control of Re-routing Behavior.......................11 6.4. Protocol Control of Re-routing Behavior.......................11
7. Reporting Crankback Information.................................12 7. Reporting Crankback Information.................................12
7.1. Required Information..........................................12 7.1. Required Information..........................................12
7.2. Protocol Extensions...........................................12 7.2. Protocol Extensions...........................................12
7.3 Guidance for Use of IF_ID Error Spec TLVs......................16 7.3 Guidance for Use of IF_ID Error Spec TLVs......................16
7.3.1 General Principles...........................................16 7.3.1 General Principles...........................................16
7.3.2 Error Report TLVs............................................16 7.3.2 Error Report TLVs............................................17
7.3.3 Fundamental Crankback TLVs...................................17 7.3.3 Fundamental Crankback TLVs...................................17
7.3.4 Additional Crankback TLVs....................................17 7.3.4 Additional Crankback TLVs....................................18
7.3.5 Grouping TLVs by Failure Location............................18 7.3.5 Grouping TLVs by Failure Location............................19
7.3.6 Alternate Path identification................................19 7.3.6 Alternate Path identification................................20
7.4. Action on Receiving Crankback Information.....................19 7.4. Action on Receiving Crankback Information.....................20
7.4.1 Re-route Attempts............................................19 7.4.1 Re-route Attempts............................................20
7.4.2 Location Identifiers of Blocked Links or Nodes...............20 7.4.2 Location Identifiers of Blocked Links or Nodes...............20
7.4.3 Locating Errors within Loose or Abstract Nodes...............20 7.4.3 Locating Errors within Loose or Abstract Nodes...............21
7.4.4 When Re-routing Fails........................................20 7.4.4 When Re-routing Fails........................................21
7.4.5 Aggregation of Crankback Information.........................21 7.4.5 Aggregation of Crankback Information.........................21
7.5. Notification of Errors........................................21 7.5. Notification of Errors........................................22
7.5.1 ResvErr Processing...........................................21 7.5.1 ResvErr Processing...........................................22
7.5.2 Notify Message Processing....................................22 7.5.2 Notify Message Processing....................................22
7.6. Error Values..................................................22 7.6. Error Values..................................................23
7.7. Backward Compatibility........................................22 7.7. Backward Compatibility........................................23
8. Routing Protocol Interactions...................................22 8. Routing Protocol Interactions...................................23
9. LSP Restoration Considerations..................................23 9. LSP Restoration Considerations..................................24
9.1. Upstream of the Fault.........................................23 9.1. Upstream of the Fault.........................................24
9.2. Downstream of the Fault.......................................24 9.2. Downstream of the Fault.......................................25
10. IANA Considerations............................................24 10. IANA Considerations............................................25
10.1. Error Codes..................................................24 10.1. Error Codes..................................................25
10.2. IF_ID_ERROR_SPEC TLVs........................................24 10.2. IF_ID_ERROR_SPEC TLVs........................................25
10.3. LSP_ATTRIBUTES Object........................................24 10.3. LSP_ATTRIBUTES Object........................................25
11. Security Considerations........................................25 11. Security Considerations........................................26
12. Acknowledgments................................................25 12. Acknowledgments................................................26
13. Intellectual Property Considerations...........................25 13. Intellectual Property Considerations...........................26
14. Normative References...........................................25 14. Normative References...........................................26
15. Informational References.......................................26 15. Informational References.......................................27
16. Authors' Addresses.............................................27 16. Authors' Addresses.............................................28
17. Disclaimer of Validity.........................................27 17. Disclaimer of Validity.........................................29
18. Full Copyright Statement.......................................28 18. Full Copyright Statement.......................................29
A. Experience of Crankback in TDM-based Networks..................29 A. Experience of Crankback in TDM-based Networks..................30
Section A : Problem Statement Section A : Problem Statement
0. Changes 0. Changes
(This section to be removed before publication as an RFC.) (This section to be removed before publication as an RFC.)
0.1 Changes from 01 to 02 Versions 0.1 Changes from 01 to 02, and 02 to 03 Versions
- Update IPR and copyright - Update IPR and copyright
- Update references - Update references
0.2 Changes from 00 to 01 Versions 0.2 Changes from 00 to 01 Versions
- Removal of background descriptive material pertaining to TDM - Removal of background descriptive material pertaining to TDM
network experience from section 3 to an Appendix. network experience from section 3 to an Appendix.
- Removal of definition of Error Spec TLVs for unnumbered bundled - Removal of definition of Error Spec TLVs for unnumbered bundled
links from section 7.2 to a separate document. links from section 7.2 to a separate document.
skipping to change at line 249 skipping to change at line 247
allocated at each Optical Cross-Connect on an end-to-end allocated at each Optical Cross-Connect on an end-to-end
explicit path. Furthermore, end-to-end restoration is the explicit path. Furthermore, end-to-end restoration is the
only way to recover LSP failures. This implies that only way to recover LSP failures. This implies that
crankback routing would also be useful in a GMPLS crankback routing would also be useful in a GMPLS
network, in particular in dynamic LSP re-routing cases network, in particular in dynamic LSP re-routing cases
(no backup LSP pre-establishment). (no backup LSP pre-establishment).
3. Discussion: Explicit Versus Implicit Re-routing Indications 3. Discussion: Explicit Versus Implicit Re-routing Indications
There have been problems in service provider networks There have been problems in service provider networks
when "inferring" from indirect information that re- when "inferring" from indirect information that re-routing
routing is allowed. This document proposes the use of an is allowed. This document proposes the use of an explicit
explicit re-routing indication that explicitly authorizes re-routing indication that explicitly authorizes re-routing.
re-routing.
Various existing protocol options and exchanges including Various existing protocol options and exchanges including
the error values of PathErr message [RFC2205, RFC3209] the error values of PathErr message [RFC2205, RFC3209]
and the Notify message [RFC3473] allow an implementation and the Notify message [RFC3473] allow an implementation
to infer a situation where re-routing can be done. This to infer a situation where re-routing can be done. This
allows for recovery from network errors or resource allows for recovery from network errors or resource
contention. contention.
However, such inference of recovery signaling is not always However, such inference of recovery signaling is not always
desirable since it may be doomed to failure. For example, desirable since it may be doomed to failure. For example,
skipping to change at line 278 skipping to change at line 275
It is certainly the case that with topology exchange, It is certainly the case that with topology exchange,
such as OSPF, the ingress LSR could infer the re-routing such as OSPF, the ingress LSR could infer the re-routing
condition. However, convergence of routing information is condition. However, convergence of routing information is
typically slower than the expected LSP setup times. One of typically slower than the expected LSP setup times. One of
the reasons for crankback is to avoid the overhead of the reasons for crankback is to avoid the overhead of
available-link-bandwidth flooding, and to more efficiently available-link-bandwidth flooding, and to more efficiently
use local state information to direct alternate routing use local state information to direct alternate routing
at the ingress-LSR. at the ingress-LSR.
[ASH1] shows how event-dependent-routing can just use crankback, [ASH1] shows how event-dependent-routing can just use crankback,
and not available-link-bandwidth flooding, to decide on the re- and not available-link-bandwidth flooding, to decide on the
route path in the network through "learning models". Reducing re-route path in the network through "learning models". Reducing
this flooding reduces overhead and can lead to the ability to this flooding reduces overhead and can lead to the ability to
support much larger AS sizes. support much larger AS sizes.
Therefore, the alternate routing should be indicated based on Therefore, the alternate routing should be indicated based on
an explicit indication, and it is best to know the following an explicit indication, and it is best to know the following
information separately: information separately:
- where blockage/congestion occurred - where blockage/congestion occurred
- whether alternate routing "should" be attempted. - whether alternate routing "should" be attempted.
skipping to change at line 374 skipping to change at line 371
node. In this case, Route Exclusions [EXCLUDE] may be node. In this case, Route Exclusions [EXCLUDE] may be
particularly helpful. To achieve this, [EXCLUDE] allows particularly helpful. To achieve this, [EXCLUDE] allows
the crankback information to be presented as route exclusions the crankback information to be presented as route exclusions
to force avoidance of the failed node, link or resource. to force avoidance of the failed node, link or resource.
4.3. Persistence of Error Information 4.3. Persistence of Error Information
The repair point LSR that computes the alternate path The repair point LSR that computes the alternate path
should store the location identifiers of the blockages should store the location identifiers of the blockages
indicated in the error message until the LSP is indicated in the error message until the LSP is
successfully established or until the LSR abandons re- successfully established or until the LSR abandons re-routing
routing attempts. Since crankback routing may happen more attempts. Since crankback routing may happen more than once
than once while establishing a specific LSP, a history while establishing a specific LSP, a history table of all
table of all experienced blockages for this LSP SHOULD be experienced blockages for this LSP SHOULD be maintained (at
maintained (at least until the routing protocol updates least until the routing protocol updates the state of this
the state of this information) to perform an accurate information) to perform an accurate path computation to
path computation to detour all blockages. detour all blockages.
If a second error response is received by a repair point If a second error response is received by a repair point (while
(while it is performing crankback re-routing) it should it is performing crankback re-routing) it should update the
update the history table that lists all experienced history table that lists all experienced blockages, and use the
blockages, and use the entire gathered information when entire gathered information when making a further re-routing attempt.
making a further re-routing attempt.
4.4. Handling Re-route Failure 4.4. Handling Re-route Failure
Multiple blockages (for the same LSP) may occur, and successive Multiple blockages (for the same LSP) may occur, and successive
setup retry attempts may fail. Retaining error information from setup retry attempts may fail. Retaining error information from
previous attempts ensures that there is no thrashing of setup previous attempts ensures that there is no thrashing of setup
attempts, and knowledge of the blockages increases with each attempts, and knowledge of the blockages increases with each
attempt. attempt.
It may be that after several retries, a given repair point is It may be that after several retries, a given repair point is
skipping to change at line 438 skipping to change at line 434
report will also mean that no further re-routing attempts report will also mean that no further re-routing attempts
can possibly succeed - for example, when the egress node can possibly succeed - for example, when the egress node
is within the failed area. is within the failed area.
When the maximum number of retries for a specific LSP has When the maximum number of retries for a specific LSP has
been exceeded, the LSR handling the current failure been exceeded, the LSR handling the current failure
should send an error message upstream indicating "Maximum should send an error message upstream indicating "Maximum
number of re-routings exceeded". This error will be number of re-routings exceeded". This error will be
passed back to the ingress LSR with no further re-routing passed back to the ingress LSR with no further re-routing
attempts. The ingress LSR may choose to retry the LSP attempts. The ingress LSR may choose to retry the LSP
setup according to local policy and might choose to re- setup according to local policy and might choose to re-use
use its original path or seek to compute a path that its original path or seek to compute a path that avoids
avoids the blocked resources. In the latter case, it may the blocked resources. In the latter case, it may be
be useful to indicate the blocked resource in this error useful to indicate the blocked resource in this error
message. message.
5. Existing Protocol Support for Crankback Re-routing 5. Existing Protocol Support for Crankback Re-routing
Crankback re-routing is appropriate for use with RSVP-TE. Crankback re-routing is appropriate for use with RSVP-TE.
1) LSP establishment may fail because of an inability to 1) LSP establishment may fail because of an inability to
route, perhaps because links are down. In this case a route, perhaps because links are down. In this case a
PathErr message is returned to the initiator. PathErr message is returned to the initiator.
skipping to change at line 900 skipping to change at line 895
Note that all LSRs MUST be prepared to receive and forward any Note that all LSRs MUST be prepared to receive and forward any
TLV as per [RFC3473]. There is, however, no requirement for an TLV as per [RFC3473]. There is, however, no requirement for an
LSR to actively process any but the error report TLVs. An LSR LSR to actively process any but the error report TLVs. An LSR
that proposes to perform crankback re-routing SHOULD support that proposes to perform crankback re-routing SHOULD support
receipt and processing of all of the fundamental crankback TLVs, receipt and processing of all of the fundamental crankback TLVs,
and is RECOMMENDED to support the receipt and processing of and is RECOMMENDED to support the receipt and processing of
the additional crankback TLVs. the additional crankback TLVs.
It should be noted, however, that some assumptions about the It should be noted, however, that some assumptions about the
TLVs that will be used MAY be made based on the deployment TLVs that will be used MAY be made based on the deployment
scenarios. For example, a router that is deployed in a single- scenarios. For example, a router that is deployed in a
area network does not need to support the receipt and processing single-area network does not need to support the receipt and
of TLV types 28 and 29. Those TLVs might be inserted in an IF_ID processing of TLV types 28 and 29. Those TLVs might be inserted
ERROR_SPEC object, but would not need to be processed by the in an IF_ID ERROR_SPEC object, but would not need to be processed
receiver of a PathErr message. by the receiver of a PathErr message.
7.3.2 Error Report TLVs 7.3.2 Error Report TLVs
Error Report TLVs are those in the range 1 through 7. Error Report TLVs are those in the range 1 through 7.
As stated above, when crankback information is reported, As stated above, when crankback information is reported,
the IF_ID ERROR_SPEC object MUST be used. When the IF_ID the IF_ID ERROR_SPEC object MUST be used. When the IF_ID
ERROR_SPEC object is used, at least one of the TLVs in ERROR_SPEC object is used, at least one of the TLVs in
the range 1 through 7 MUST be present. The choice of which the range 1 through 7 MUST be present. The choice of which
TLV to use will be dependent on the circumstance of the error TLV to use will be dependent on the circumstance of the error
skipping to change at line 1086 skipping to change at line 1081
established or until the node abandons its attempts to re-route established or until the node abandons its attempts to re-route
the LSP. This allows the combination of crankback information the LSP. This allows the combination of crankback information
from multiple failures when computing an alternate path. from multiple failures when computing an alternate path.
It is an implementation decision whether the crankback It is an implementation decision whether the crankback
information is discarded immediately upon successful LSP information is discarded immediately upon successful LSP
establishment or retained for a period in case the LSP fails. establishment or retained for a period in case the LSP fails.
7.4.2 Location Identifiers of Blocked Links or Nodes 7.4.2 Location Identifiers of Blocked Links or Nodes
In order to compute an alternate path by crankback re- In order to compute an alternate path by crankback re-routing,
routing, it is necessary to identify the blocked links or it is necessary to identify the blocked links or nodes and
nodes and their locations. The common identifier of each their locations. The common identifier of each link or node
link or node in an MPLS network should be specified. Both in an MPLS network should be specified. Both
protocol-independent and protocol- dependent identifiers protocol-independent and protocol- dependent identifiers
may be specified. Although a general identifier that is may be specified. Although a general identifier that is
independent of other protocols is preferable, there are a independent of other protocols is preferable, there are a
couple of restrictions on its use as described in the couple of restrictions on its use as described in the
following subsection. following subsection.
In link state protocols such as OSPF and IS-IS , each In link state protocols such as OSPF and IS-IS , each
link and node in a network can be uniquely identified. link and node in a network can be uniquely identified.
For example, by the context of a Router ID and the Link For example, by the context of a Router ID and the Link
ID. If the topology and resource information obtained by ID. If the topology and resource information obtained by
skipping to change at line 1135 skipping to change at line 1130
route between which the error/blockage occurred. route between which the error/blockage occurred.
To assist this, the crankback information reports the top To assist this, the crankback information reports the top
two hops of the explicit route as received at the two hops of the explicit route as received at the
reporting node. The first hop will likely identify the reporting node. The first hop will likely identify the
node or the link, the second hop will identify a 'next' node or the link, the second hop will identify a 'next'
hop from the original explicit route. hop from the original explicit route.
7.4.4 When Re-routing Fails 7.4.4 When Re-routing Fails
When a node cannot or chooses not to perform crankback re- When a node cannot or chooses not to perform crankback
routing it must forward the PathErr message further upstream. re-routing it must forward the PathErr message further upstream.
However, when a node was responsible for expanding or However, when a node was responsible for expanding or
replacing the explicit route as the LSP setup was replacing the explicit route as the LSP setup was
processed it MUST update the crankback information with processed it MUST update the crankback information with
regard to the explicit route that it received. Only if regard to the explicit route that it received. Only if
this is done will the upstream nodes stand a chance of this is done will the upstream nodes stand a chance of
successfully routing around the problem. successfully routing around the problem.
7.4.5 Aggregation of Crankback Information 7.4.5 Aggregation of Crankback Information
skipping to change at line 1228 skipping to change at line 1223
error to the ingress/egress LSRs. error to the ingress/egress LSRs.
7.6. Error Values 7.6. Error Values
Error values for the Error Code "Admission Control Error values for the Error Code "Admission Control
Failure" are defined in [RFC2205]. Error values for the Failure" are defined in [RFC2205]. Error values for the
error code "Routing Problem" are defined in [RFC 3209] error code "Routing Problem" are defined in [RFC 3209]
and [RFC 3473]. and [RFC 3473].
A new error value is defined for the error code "Routing A new error value is defined for the error code "Routing
Problem". "Re-routing limit exceeded" indicates that re- Problem". "Re-routing limit exceeded" indicates that re-routing
routing has failed because the number of crankback re- has failed because the number of crankback re-routing attempts
routing attempts has gone beyond the predetermined has gone beyond the predetermined threshold at an individual LSR.
threshold at an individual LSR.
7.7. Backward Compatibility 7.7. Backward Compatibility
It is recognized that not all nodes in an RSVP-TE network It is recognized that not all nodes in an RSVP-TE network
will support the extensions defined in this document. It will support the extensions defined in this document. It
is important that an LSR that does not support these is important that an LSR that does not support these
extensions can continue to process a PathErr, ResvErr or extensions can continue to process a PathErr, ResvErr or
Notify message even if it carries the newly defined IF_ID Notify message even if it carries the newly defined IF_ID
ERROR_SPEC information (TLVs). ERROR_SPEC information (TLVs).
skipping to change at line 1396 skipping to change at line 1390
12. Acknowledgments 12. Acknowledgments
We would like to thank Juha Heinanen and Srinivas Makam We would like to thank Juha Heinanen and Srinivas Makam
for their review and comments, and Zhi-Wei Lin for his for their review and comments, and Zhi-Wei Lin for his
considered opinions. Thanks, too, to John Drake for considered opinions. Thanks, too, to John Drake for
encouraging us to resurrect this document and consider encouraging us to resurrect this document and consider
the use of the IF-ID ERROR SPEC object. Thanks for a the use of the IF-ID ERROR SPEC object. Thanks for a
welcome and very thorough review by Dimitri Papadimitriou. welcome and very thorough review by Dimitri Papadimitriou.
Simon Marshall-Unitt made contributions to this draft.
13. Intellectual Property Considerations 13. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at line 1442 skipping to change at line 1438
[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 [LSP-ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of
Attributes for Multiprotocol Label Switching (MPLS) Attributes for Multiprotocol Label Switching (MPLS)
Label Switched Path (LSP) Establishment Using RSVP-TE", Label Switched Path (LSP) Establishment Using RSVP-TE",
draft-ietf-mpls-rsvpte-attributes-03.txt, March 2003, draft-ietf-mpls-rsvpte-attributes-04.txt, July 2004,
work in progress. work in progress.
[ASON-REQ] D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong, [ASON-REQ] D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong,
"Requirements for Generalized MPLS (GMPLS) Signaling "Requirements for Generalized MPLS (GMPLS) Signaling
Usage and Extensions for Automatically Switched Optical Usage and Extensions for Automatically Switched Optical
Network (ASON)", daft-ietf-ccamp-gmpls-ason-reqts-06.txt Network (ASON)", daft-ietf-ccamp-gmpls-ason-reqts-07.txt
April 2004, work in progress. October 2004, work in progress.
15. Informational References 15. 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.
[FASTRR] Ping Pan, et al., "Fast Reroute Extensions to RSVP-TE [FASTRR] Ping Pan, et al., "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute- for LSP Tunnels",
06.txt, November 2003 (work in progress). draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt, May 2004
(work in progress).
[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. 2001. For information on the availability of this
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", draft-ietf-ccamp-rsvp-te-exclude- Extension to RSVP-TE",
route-02.txt, July 2004 (work in progress). draft-ietf-ccamp-rsvp-te-exclude-route-02.txt, July 2004
(work in progress).
[PNNI] ATM Forum, "Private Network-Network Interface [PNNI] ATM Forum, "Private Network-Network Interface
Specification Version 1.0 (PNNI 1.0)", <af-pnni- Specification Version 1.0 (PNNI 1.0)",
0055.000>, May 1996. <af-pnni-0055.000>, May 1996.
[RFC2702] D. Awduche, et al., "Requirements for Traffic [RFC2702] D. Awduche, et al., "Requirements for Traffic
Engineering Over MPLS", RFC2702, September 1999. Engineering Over MPLS", RFC2702, September 1999.
[RFC3469] V. Sharma, et al., "Framework for MPLS-based Recovery", [RFC3469] V. Sharma, et al., "Framework for MPLS-based Recovery",
RFC 3469, February 2003. RFC 3469, February 2003.
[TE-BUNDLE] Z. Ali, A. Farrel, D. Papadimitriou, A. Satyanarayana, [TE-BUNDLE] Z. Ali, A. Farrel, D. Papadimitriou, A. Satyanarayana,
and A. Zamfir, "Generalized Multi-Protocol Label and A. Zamfir, "Generalized Multi-Protocol Label
Switching (GMPLS) RSVP-TE signaling using Bundled Switching (GMPLS) RSVP-TE signaling using Bundled
Traffic Engineering (TE) Links", draft-dimitri-ccamp- Traffic Engineering (TE) Links",
gmpls-rsvp-te-bundled-links-00.txt, May 2004, work in draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt,
progress. May 2004, work in progress.
16. Authors' Addresses 16. 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
Movaz Networks, Inc. Movaz Networks, Inc.
skipping to change at line 1527 skipping to change at line 1526
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
Simon Marshall-Unitt
Data Connection Ltd.
100 Church Street
Enfield, Middlesex, EN2 6BQ, UK
Phone: (+44) (0)-208-366-1177
EMail: smu@dataconnection.com
17. Disclaimer of Validity 17. 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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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.
skipping to change at line 1634 skipping to change at line 1626
It is certainly the case that with topology exchange, such as OSPF, It is certainly the case that with topology exchange, such as OSPF,
the ingress LSR could infer the re-routing condition. However, the ingress LSR could infer the re-routing condition. However,
convergence of routing information is typically slower than the convergence of routing information is typically slower than the
expected LSP setup times. One of the reasons for crankback is to expected LSP setup times. One of the reasons for crankback is to
avoid the overhead of available-link-bandwidth flooding, and to more avoid the overhead of available-link-bandwidth flooding, and to more
efficiently use local state information to direct alternate routing efficiently use local state information to direct alternate routing
at the ingress-LSR. at the ingress-LSR.
[ASH1] shows how event-dependent-routing can just use crankback, [ASH1] shows how event-dependent-routing can just use crankback,
and not available-link-bandwidth flooding, to decide on the re- and not available-link-bandwidth flooding, to decide on the
route path in the network through "learning models". Reducing re-route path in the network through "learning models". Reducing
this flooding reduces overhead and can lead to the ability to this flooding reduces overhead and can lead to the ability to
support much larger AS sizes. support much larger AS sizes.
Therefore, the alternate routing should be indicated based on Therefore, the alternate routing should be indicated based on
an explicit indication (as in examples 3 and 4), and it is best an explicit indication (as in examples 3 and 4), and it is best
to know the following information separately: to know the following information separately:
a) where blockage/congestion occurred (as in examples 1-2), a) where blockage/congestion occurred (as in examples 1-2),
and and
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/