draft-ietf-ccamp-inter-domain-rsvp-te-05.txt   draft-ietf-ccamp-inter-domain-rsvp-te-06.txt 
INTERNET-DRAFT A. Farrel (Editor) INTERNET-DRAFT A. Farrel (Editor)
Network Working Group Old Dog Consulting Network Working Group Old Dog Consulting
Intended Status: Standards Track Intended Status: Standards Track
Updates: RFC 3209, RFC 3473 A. Ayyangar Updates: RFC 3209, RFC 3473 A. Ayyangar
Expires: August 2007 Nuova Systems Expires: October 2007 Nuova Systems
JP. Vasseur JP. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
February 2007
Inter domain Multiprotocol Label Switching (MPLS) and Inter domain Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions
draft-ietf-ccamp-inter-domain-rsvp-te-05.txt draft-ietf-ccamp-inter-domain-rsvp-te-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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 11, line 41 skipping to change at page 11, line 41
the ERO may comprise of strict or loose hops, and will depend on the the ERO may comprise of strict or loose hops, and will depend on the
TE visibility of the computation point into the subsequent domain. TE visibility of the computation point into the subsequent domain.
If loose hops are required created in the path of the backup LSP, ERO If loose hops are required created in the path of the backup LSP, ERO
expansion will be required at some point along the path: probably at expansion will be required at some point along the path: probably at
a domain border node. In order that the backup path remains disjoint a domain border node. In order that the backup path remains disjoint
from the protected LSP(s) the node performing the ERO expansion must from the protected LSP(s) the node performing the ERO expansion must
be provided with the path of the protected LSPs between the PLR and be provided with the path of the protected LSPs between the PLR and
the MP. This information can be gathered from the RROs of the the MP. This information can be gathered from the RROs of the
protected LSPs and is signaled in the DETOUR object for Fast Reroute protected LSPs and is signaled in the DETOUR object for Fast Reroute
[RFC4090], and using route exclusion [EXCLUDE-ROUTE] for other [RFC4090], and using route exclusion [RFC4874] for other protection
protection schemes. schemes.
5.1. Fast Recovery Support Using MPLS-TE Fast Reroute (FRR) 5.1. Fast Recovery Support Using MPLS-TE Fast Reroute (FRR)
[RFC4090] describes two methods for local protection for a [RFC4090] describes two methods for local protection for a
packet TE LSP in case of link, SRLG, or node failure. This section packet TE LSP in case of link, SRLG, or node failure. This section
describes how these mechanisms work with the proposed signaling describes how these mechanisms work with the proposed signaling
solutions for inter-domain TE LSP setup. solutions for inter-domain TE LSP setup.
5.1.1. Failure Within a Domain (Link or Node Failure) 5.1.1. Failure Within a Domain (Link or Node Failure)
skipping to change at page 12, line 39 skipping to change at page 12, line 39
To protect an inter-domain link with MPLS-TE Fast Reroute, a set of To protect an inter-domain link with MPLS-TE Fast Reroute, a set of
backup tunnels must be configured or dynamically computed between the backup tunnels must be configured or dynamically computed between the
PLR and MP such that they are diversely routed from the protected PLR and MP such that they are diversely routed from the protected
inter-domain link and the protected inter-domain LSPs. inter-domain link and the protected inter-domain LSPs.
Each protected inter-domain LSP using the protected inter-domain TE Each protected inter-domain LSP using the protected inter-domain TE
link must be assigned to an NHOP bypass tunnel that is diverse from link must be assigned to an NHOP bypass tunnel that is diverse from
the protected LSP. Such an NHOP bypass tunnel can be selected by the protected LSP. Such an NHOP bypass tunnel can be selected by
analyzing the RROs in the Resv messages of the available bypass analyzing the RROs in the Resv messages of the available bypass
tunnels and the protected TE LSP. It may be helpful to this process tunnels and the protected TE LSP. It may be helpful to this process
if the extensions defined in [NODE-ID] are used to clearly if the extensions defined in [RFC4561] are used to clearly
distinguish nodes and links in the RROs. distinguish nodes and links in the RROs.
5.1.3. Failure of a Border Node 5.1.3. Failure of a Border Node
Two border node failure cases exist. If the domain border falls on a Two border node failure cases exist. If the domain border falls on a
link as described in the previous section, the border node at either link as described in the previous section, the border node at either
end of the link may fail. Alternatively, if the border falls on a end of the link may fail. Alternatively, if the border falls on a
border node (as is the case with IGP areas) that single border node border node (as is the case with IGP areas) that single border node
may fail. may fail.
skipping to change at page 13, line 36 skipping to change at page 13, line 36
over any particular portion of a network used by an LSP. over any particular portion of a network used by an LSP.
The domain border failure cases described in Section 5.1 may also The domain border failure cases described in Section 5.1 may also
occur in GMPLS networks (including packet networks) and can be occur in GMPLS networks (including packet networks) and can be
protected against using segment protection without any additional protected against using segment protection without any additional
protocol extensions. protocol extensions.
Note that if loose hops are used in the construction of the working Note that if loose hops are used in the construction of the working
and protection paths signaled for segment protection then care is and protection paths signaled for segment protection then care is
required to keep these paths disjoint. If the paths are signaled required to keep these paths disjoint. If the paths are signaled
incrementally then route exclusion [EXCLUDE-ROUTE] may be used to incrementally then route exclusion [RFC4874] may be used to ensure
ensure that the paths are disjoint. Otherwise a coordinated path that the paths are disjoint. Otherwise a coordinated path computation
computation technique such as that offered by cooperating Path technique such as that offered by cooperating Path Computation
Computation Elements [RFC4655] can provide suitable paths. Elements [RFC4655] can provide suitable paths.
6. Re-Optimization of Inter-Domain TE LSPs 6. Re-Optimization of Inter-Domain TE LSPs
Re-optimization of a TE LSP is the process of moving the LSP from the Re-optimization of a TE LSP is the process of moving the LSP from the
current path to a more prefered path. This involves the determination current path to a more prefered path. This involves the determination
of the preferred path and make-before-break signaling procedures of the preferred path and make-before-break signaling procedures
[RFC3209] to minimize traffic disruption. [RFC3209] to minimize traffic disruption.
Re-optimization of an inter-domain TE LSP may require a new path in Re-optimization of an inter-domain TE LSP may require a new path in
more than one domain. more than one domain.
skipping to change at page 16, line 29 skipping to change at page 16, line 29
or error notifications from a particular domain. or error notifications from a particular domain.
3) A mechanism to allow policy-based outbound RSVP message 3) A mechanism to allow policy-based outbound RSVP message
processing at the domain border node, which may involve processing at the domain border node, which may involve
filtering or modification of certain addresses in RSVP filtering or modification of certain addresses in RSVP
objects and messages. objects and messages.
Additionally, an operator may wish to reduce the signaling Additionally, an operator may wish to reduce the signaling
interactions between domains to improve security. For example, the interactions between domains to improve security. For example, the
operator might not trust the neighboring domain to supply correct or operator might not trust the neighboring domain to supply correct or
trustable restart information [RSVP-RETSART] and might ensure that trustable restart information [RSVP-RESTART] and might ensure that
the availablity of restart function is not configured in the Hello the availablity of restart function is not configured in the Hello
message exchange across the domain border. Thus, suitable message exchange across the domain border. Thus, suitable
configuration MUST be provided in an RSVP-TE implementation to configuration MUST be provided in an RSVP-TE implementation to
enable the operator to control optional protocol features that may be enable the operator to control optional protocol features that may be
considered a security risk. considered a security risk.
Some examples of the policies described above are as follows: Some examples of the policies described above are as follows:
A) An operator may choose to implement some kind of ERO filtering A) An operator may choose to implement some kind of ERO filtering
policy on the domain border node to disallow or ignore hops policy on the domain border node to disallow or ignore hops
skipping to change at page 17, line 10 skipping to change at page 17, line 10
domain in the RRO or may choose to filter out certain recorded domain in the RRO or may choose to filter out certain recorded
RRO addresses at the domain border node. RRO addresses at the domain border node.
C) An operator may require the border node to modify the addresses C) An operator may require the border node to modify the addresses
of certain messages like PathErr or Notify originated from hops of certain messages like PathErr or Notify originated from hops
within the domain. within the domain.
Note that the detailed specification of such policies and their Note that the detailed specification of such policies and their
implementation are outside the scope of this document. implementation are outside the scope of this document.
OAM mechanisms including [BFD-MPLS] and [LSP-PING] are commonly used OAM mechanisms including [BFD-MPLS] and [RFC4379] are commonly used
to verify he connectivity of end-to-end LSPs and to trace their to verify he connectivity of end-to-end LSPs and to trace their
paths. Where the LSPs are inter-domain LSPs, such OAM techniques MAY paths. Where the LSPs are inter-domain LSPs, such OAM techniques MAY
require to be intercepted or modified at domain borders, or to be require to be intercepted or modified at domain borders, or to be
passed transparently across domains. Further discussion of this topic passed transparently across domains. Further discussion of this topic
can be found in [INTERAS-PING] and [MPLS-GMPLS-SEC]. can be found in [INTERAS-PING] and [MPLS-GMPLS-SEC].
9. IANA Considerations 9. IANA Considerations
IANA is requested to make the codepoint allocations described in the IANA is requested to make the codepoint allocations described in the
following sections. following sections.
skipping to change at page 18, line 18 skipping to change at page 18, line 18
from Kireeti Kompella on various aspects discussed in the document. from Kireeti Kompella on various aspects discussed in the document.
Deborah Brungard and Dimitri Papdimitriou provided thorough reviews. Deborah Brungard and Dimitri Papdimitriou provided thorough reviews.
11. References 11. References
11.1. Normative References 11.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.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1,
Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., et al, "Extensions to RSVP for LSP Tunnels", [RFC3209] Awduche, D., et al, "Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001. RFC 3209, December 2001.
[RFC3473] Berger, L., et al, "Generalized Multi-Protocol Label [RFC3473] Berger, L., et al, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol - Switching (GMPLS) Signaling Resource ReserVation Protocol -
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003. January 2003.
[RFC4206] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized [RFC4206] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized
MPLS TE", RFC 4206, October 2005. MPLS TE", RFC 4206, October 2005.
skipping to change at page 19, line 12 skipping to change at page 19, line 16
for Inter-Area MPLS Traffic Engineering", RFC 4105, June for Inter-Area MPLS Traffic Engineering", RFC 4105, June
2005. 2005.
[RFC4208] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the [RFC4208] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the
Overlay Model", RFC 4208, October 2005. Overlay Model", RFC 4208, October 2005.
[RFC4216] Zhang, R., et al, "MPLS Inter-Autonomous System (AS) [RFC4216] Zhang, R., et al, "MPLS Inter-Autonomous System (AS)
Traffic Engineering (TE) Requirements", RFC 4216, November Traffic Engineering (TE) Requirements", RFC 4216, November
2005. 2005.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC4561] Vasseur, JP., Ali, Z., and Sivabalan, S., "Definition of a
Record Route Object (RRO) Node-Id Sub-Object", RFC 4561,
June 2006.
[RFC4655] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation [RFC4655] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, Arthi, "A [RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, Arthi, "A
Framework for Inter-Domain Multiprotocol Label Switching Framework for Inter-Domain Multiprotocol Label Switching
Traffic Engineering", RFC 4726, November 2006. Traffic Engineering", RFC 4726, November 2006.
[RFC4736] Vasseur, JP., et al, "Reoptimization of Multiprotocol Label [RFC4736] Vasseur, JP., et al, "Reoptimization of Multiprotocol Label
Switching (MPLS) Traffic Engineering (TE) Loosely Routed Switching (MPLS) Traffic Engineering (TE) Loosely Routed
Label Switched Path (LSP)", RFC 4736, November 2006. Label Switched Path (LSP)", RFC 4736, November 2006.
[RFC4874] Lee, CY., Farrel, A., and De Cnodder, S., "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007.
[BFD-MPLS] Aggarwal, R., et al, "BFD For MPLS LSPs", [BFD-MPLS] Aggarwal, R., et al, "BFD For MPLS LSPs",
draft-ietf-bfd-mpls, (work in progress). draft-ietf-bfd-mpls, (work in progress).
[CRANKBACK] Farrel, A., et al, "Crankback Signaling Extensions for [CRANKBACK] Farrel, A., et al, "Crankback Signaling Extensions for
MPLS and GMPLS RSVP-TE", draft-ietf-ccamp-crankback, (work MPLS and GMPLS RSVP-TE", draft-ietf-ccamp-crankback, (work
in progress). in progress).
[EXCLUDE-ROUTE] Lee, CY., Farrel, A., and De Cnodder, S., "Exclude
Routes - Extension to RSVP-TE",
draft-ietf-ccamp-rsvp-te-exclude-route, (work in progress).
[INTERAS-PING] Nadeau, T., and Swallow, G., "Detecting MPLS Data [INTERAS-PING] Nadeau, T., and Swallow, G., "Detecting MPLS Data
Plane Failures in Inter-AS and inter-provider Scenarios", Plane Failures in Inter-AS and inter-provider Scenarios",
draft-nadeau-mpls-interas-lspping, work in progress. draft-nadeau-mpls-interas-lspping, work in progress.
[INTER-DOMAIN-PD-PATH-COMP] Vasseur, JP., Ayyangar, A., and [INTER-DOMAIN-PD-PATH-COMP] Vasseur, JP., Ayyangar, A., and
Zhang, R., "A Per-domain path computation method for Zhang, R., "A Per-domain path computation method for
computing Inter-domain Traffic Engineering (TE) Label computing Inter-domain Traffic Engineering (TE) Label
Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd- Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-
path-comp, (work in progress). path-comp, (work in progress).
[MPLS-GMPLS-SEC] Luyuan Fang, et al., "Security Framework for MPLS [MPLS-GMPLS-SEC] Luyuan Fang, et al., "Security Framework for MPLS
and GMPLS Networks", draft-fang-mpls-gmpls-security- and GMPLS Networks", draft-fang-mpls-gmpls-security-
framework, work in progress. framework, work in progress.
[NODE-ID] Vasseur, JP., Ali, Z., and Sivabalan, S., "Definition of an
RRO node-id subobject", draft-ietf-mpls-nodeid-subobject,
(work in progress).
[RSVP-RESTART] Satyanarayana, A., and Rahman, R., "Extensions to [RSVP-RESTART] Satyanarayana, A., and Rahman, R., "Extensions to
GMPLS RSVP Graceful Restart", draft-ietf-ccamp-rsvp- GMPLS RSVP Graceful Restart", draft-ietf-ccamp-rsvp-
restart-ext, work in progress. restart-ext, work in progress.
[SEGMENT-PROTECTION] Berger, L., et al, "GMPLS Based Segment [SEGMENT-PROTECTION] Berger, L., et al, "GMPLS Based Segment
Recovery", draft-ietf-ccamp-gmpls-segment-recovery, (work Recovery", draft-ietf-ccamp-gmpls-segment-recovery, (work
in progress). in progress).
12. Authors' Addresses 12. Authors' Addresses
 End of changes. 13 change blocks. 
21 lines changed or deleted 27 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/