draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt   draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt 
Network Working Group T. Takeda, Ed. Network Working Group T. Takeda, Ed.
Internet Draft NTT Internet Draft NTT
Intended Status: Informational A. Farrel, Ed. Intended Status: Informational A. Farrel, Ed.
Created April 13, 2008 Old Dog Consulting Created April 16, 2008 Old Dog Consulting
Expires: October 13, 2008 Y. Ikejiri Expires: October 16, 2008 Y. Ikejiri
NTT Communications NTT Communications
JP. Vasseur JP. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
Analysis of Inter-domain Label Switched Path (LSP) Recovery Analysis of Inter-domain Label Switched Path (LSP) Recovery
draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt draft-ietf-ccamp-inter-domain-recovery-analysis-05.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 1, line 40 skipping to change at page 1, line 40
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 accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Protection and recovery are important features of service provision Protection and recovery are important features of service offerings
in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
networks. Increasingly, MPLS and GMPLS networking is being widened networks. Increasingly, MPLS and GMPLS networks are being extended
from single domain scope to operate in multi-domain environments. from single domain scope to multi-domain environments.
Various schemes and processes have been developed to establish Label Various schemes and processes have been developed to establish Label
Switched Paths (LSPs) in multi-domain environments. These are Switched Paths (LSPs) in multi-domain environments. These are
discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol
Label Switching Traffic Engineering. Label Switching Traffic Engineering.
This document analyzes the application of these techniques to This document analyzes the application of these techniques to
protection and recovery in multi-domain networks. The main focus for protection and recovery in multi-domain networks. The main focus for
this document is on establishing end-to-end diverse Traffic this document is on establishing end-to-end diverse Traffic
Engineering (TE) LSPs in multi-domain networks. Engineering (TE) LSPs in multi-domain networks.
skipping to change at page 3, line 12 skipping to change at page 3, line 12
12. Acknowledgments..............................................24 12. Acknowledgments..............................................24
13. Authors' Addresses...........................................24 13. Authors' Addresses...........................................24
1. Introduction 1. Introduction
Protection and recovery in Multiprotocol Label Switching (MPLS) and Protection and recovery in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks are described in [RFC4428]. These Generalized MPLS (GMPLS) networks are described in [RFC4428]. These
are important features for service delivery in MPLS and GMPLS are important features for service delivery in MPLS and GMPLS
networks. networks.
MPLS and GMPLS networking was originally limited to single domain MPLS and GMPLS networks were originally limited to single domain
environments. Increasingly, multi-domain MPLS and GMPLS networks are environments. Increasingly, multi-domain MPLS and GMPLS networks are
being considered, where a domain is considered to be any collection being considered, where a domain is considered to be any collection
of network elements within a common sphere of address management or of network elements within a common sphere of address management or
path computational responsibility. Examples of such domains include path computational responsibility. Examples of such domains include
Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes).
[RFC4726] provides a framework for inter-domain MPLS and GMPLS [RFC4726] provides a framework for inter-domain MPLS and GMPLS
traffic engineering. It introduces and discusses the various schemes traffic engineering. It introduces and discusses the various schemes
and processes to establish Label Switched Paths (LSPs) in multi- and processes to establish Label Switched Paths (LSPs) in multi-
domain environments. domain environments.
However, protection and recovery introduce additional complexities to However, protection and recovery introduce additional complexities to
LSP establishment. Protection LSPs are generally required to path LSP establishment. Protection LSPs are generally required to be path
diverse from the working LSPs that they protect. Achieving this is diverse from the working LSPs that they protect. Achieving this is
particularly challenging in multi-domain environments because no particularly challenging in multi-domain environments because no
single path computation or planning point is capable of determining single path computation or planning point is capable of determining
both paths from one end to the other. path diversity for both paths from one end to the other.
This document analyzes various schemes to realize MPLS and GMPLS This document analyzes various schemes to realize MPLS and GMPLS
LSP recovery in multi-domain networks. The main focus for this LSP recovery in multi-domain networks. The main focus for this
document is on establishing end-to-end diverse Traffic Engineering document is on establishing end-to-end diverse Traffic Engineering
(TE) LSPs in multi-domain networks. (TE) LSPs in multi-domain networks.
1.1 Terminology 1.1 Terminology
The reader is assumed to be familiar with the terminology for LSP The reader is assumed to be familiar with the terminology for LSP
recovery set out in [RFC4427], and with the terms introduced in recovery set out in [RFC4427], and with the terms introduced in
[RFC4726] that provides a framework for inter-domain Label Switched [RFC4726] that provides a framework for inter-domain Label Switched
Path (LSP) setup. Key terminology may also be found in [RFC4216] Path (LSP) setup. Key terminology may also be found in [RFC4216]
where requirements for MPLS traffic engineering inter-AS are set out. that sets out requirements for inter-AS MPLS traffic engineering.
The following key terms from those sources are used within this The following key terms from those sources are used within this
document. document.
- Domain: See [RFC4726]. A domain is considered to be any - Domain: See [RFC4726]. A domain is considered to be any
collection of network elements within a common sphere of address collection of network elements within a common sphere of address
management or path computational responsibility. Note that nested management or path computational responsibility. Note that nested
domains continue to be out of scope. Section 1.2 provides domains continue to be out of scope. Section 1.2 provides
additional details. additional details.
skipping to change at page 4, line 39 skipping to change at page 4, line 39
that domain. that domain.
1.2 Domain 1.2 Domain
In order to fully understand the issues addressed in this document, In order to fully understand the issues addressed in this document,
it is necessary to carefully define and scope the term "domain". it is necessary to carefully define and scope the term "domain".
As defined in [RFC4726], a domain is considered to be any collection As defined in [RFC4726], a domain is considered to be any collection
of network elements within a common sphere of address management or of network elements within a common sphere of address management or
path computational responsibility. Examples of such domains include path computational responsibility. Examples of such domains include
IGP areas and Autonomous Systems. A network accessed over the GMPLS IGP areas and Autonomous Systems. Networks accessed over the GMPLS
User-to-Network Interface (UNI) [RFC4208] and a Layer One Virtual User-to-Network Interface (UNI) [RFC4208], and Layer One Virtual
Private Network (L1VPN) [RFC4847] are special cases of multi-domain Private Networks (L1VPNs) [RFC4847] are special cases of multi-domain
networks. networks.
Example motivations for using more than one domain include Example motivations for using more than one domain include
administrative separation, scalability, and the construction of administrative separation, scalability, and the construction of
domains for the purpose of providing protection. These latter domains for the purpose of providing protection. These latter
"protection domains" offer edge-to-edge protection facilities for "protection domains" offer edge-to-edge protection facilities for
spans or segments of end-to-end LSPs. spans or segments of end-to-end LSPs.
As described in [RFC4726], there could be TE parameters (such as As described in [RFC4726], there could be TE parameters (such as
color and priority) whose meanings are specific to each domain. In color and priority) whose meanings are specific to each domain. In
skipping to change at page 5, line 14 skipping to change at page 5, line 14
functions may be needed to transform the TE parameters based on functions may be needed to transform the TE parameters based on
policy agreements between domain administrators. policy agreements between domain administrators.
1.3 Document Scope 1.3 Document Scope
This document analyzes various schemes to realize MPLS and GMPLS LSP This document analyzes various schemes to realize MPLS and GMPLS LSP
recovery in multi-domain networks. It is based on the existing recovery in multi-domain networks. It is based on the existing
framework for multi-domain LSP setup [RFC4726]. Note that this framework for multi-domain LSP setup [RFC4726]. Note that this
document does not prevent the development of additional techniques document does not prevent the development of additional techniques
where appropriate (i.e., additional to the ones described in this where appropriate (i.e., additional to the ones described in this
document). In other words, this shows how the existing techniques can document). In other words, this document shows how the existing
be applied. techniques can be applied.
There are various recovery techniques for LSPs. For TE LSPs, the There are various recovery techniques for LSPs. For TE LSPs, the
major techniques are end-to-end recovery [RFC4872], local protection major techniques are end-to-end recovery [RFC4872], local protection
such as Fast Reroute (FRR) [RFC4090] (in packet switching such as Fast Reroute (FRR) [RFC4090] (in packet switching
environments), and segment recovery [RFC4873] (in GMPLS). environments), and segment recovery [RFC4873] (in GMPLS).
The main focus of this document is the analysis of diverse TE LSP The main focus of this document is the analysis of diverse TE LSP
setup schemes that can be used in the context of end-to-end recovery. setup schemes that can be used in the context of end-to-end recovery.
The methodology is to show different combinations of functional The methodology is to show different combinations of functional
elements such as path computation and signaling techniques. elements such as path computation and signaling techniques.
[RFC4105] and [RFC4216] describe requirements for diverse LSPs. There [RFC4105] and [RFC4216] describe requirements for diverse LSPs. There
are various types of diversity, and this document focuses on node, are various types of diversity, and this document focuses on node,
link, and shared risk link group (SRLG) diversity. link, and shared risk link group (SRLG) diversity.
Recovery LSPs may be used for 1+1 protection, 1:1 protection, or Recovery LSPs may be used for 1+1 protection, 1:1 protection, or
shared mesh restoration. However, the requirements for path shared mesh restoration. However, the requirements for path
diversity, the ways to compute diverse paths, and the signaling of diversity, the ways to compute diverse paths, and the signaling of
these TE LSPs are common across all uses, and these topics are the these TE LSPs are common across all uses. These topics are the main
main scope of this document. scope of this document.
Note that diverse LSPs may be used for various purposes in addition Note that diverse LSPs may be used for various purposes in addition
to recovery. An example is for load-balancing, so as to limit the to recovery. An example is for load-balancing, so as to limit the
traffic disruption to a portion of the traffic flow in case of a traffic disruption to a portion of the traffic flow in case of a
single network element failure. This document does not preclude use single node failure. This document does not preclude use of diverse
of diverse LSP setup schemes for those purposes. LSP setup schemes for other purposes.
The following are beyond the scope of this document. The following are beyond the scope of this document.
- Analysis of recovery techniques other than the use of link, node, - Analysis of recovery techniques other than the use of link, node,
or SRLG diverse LSPs (see Section 1.4). or SRLG diverse LSPs (see Section 1.4).
- Details of maintenance of diverse LSPs, such as re-optimization and - Details of maintenance of diverse LSPs, such as re-optimization and
OAM. OAM.
- Comparative evaluation of LSP setup schemes. - Comparative evaluation of LSP setup schemes.
skipping to change at page 6, line 15 skipping to change at page 6, line 15
1.4 Note on Other Recovery Techniques 1.4 Note on Other Recovery Techniques
Fast Reroute and segment recovery in multi-domain networks are Fast Reroute and segment recovery in multi-domain networks are
described in Section 5.4 of [RFC4726], and a more detailed analysis described in Section 5.4 of [RFC4726], and a more detailed analysis
is provided in Section 5 of [RFC5151]. This document does not cover is provided in Section 5 of [RFC5151]. This document does not cover
any additional analysis for Fast ReRoute and segment recovery in any additional analysis for Fast ReRoute and segment recovery in
multi-domain networks. multi-domain networks.
The recovery type of an LSP or service may change at a domain The recovery type of an LSP or service may change at a domain
boundary. That is, the recovery type could remain the same within one boundary. That is, the recovery type could remain the same within one
domain, but might be different in the next domain. This may be due to domain, but might be different in the next domain or on the
the capabilities of each domain, administrative policies, or to connections between domains. This may be due to the capabilities of
topology limitations. An example is where protection at the domain each domain, administrative policies, or to topology limitations. An
boundary is provided by link protection on the inter-domain links, example is where protection at the domain boundary is provided by
but where protection within each domain is achieved through segment link protection on the inter-domain links, but where protection
recovery. This mixture of protection techniques is beyond the scope within each domain is achieved through segment recovery. This mixture
of this document. of protection techniques is beyond the scope of this document.
Domain diversity (that is, the selection of paths that have only the Domain diversity (that is, the selection of paths that have only the
ingress and egress domains in common) may be considered as one form ingress and egress domains in common) may be considered as one form
of diversity in multi-domain networks, but this is beyond the scope of diversity in multi-domain networks, but this is beyond the scope
of this document (see Section 2.2). of this document (see Section 2.2).
1.5 Signaling Options 1.5 Signaling Options
There are three signaling options for establishing inter-domain TE There are three signaling options for establishing inter-domain TE
LSPs: nesting, contiguous LSPs, and stitching [RFC4726]. The LSPs: nesting, contiguous LSPs, and stitching [RFC4726]. The
skipping to change at page 6, line 45 skipping to change at page 6, line 45
Note that signaling option considerations for Fast Reroute and Note that signaling option considerations for Fast Reroute and
segment recovery are described in [RFC5151]. segment recovery are described in [RFC5151].
2. Diversity in Multi-Domain Networks 2. Diversity in Multi-Domain Networks
This section describes some assumptions about achieving path This section describes some assumptions about achieving path
diversity in multi-domain networks. diversity in multi-domain networks.
2.1 Multi-Domain Network Topology 2.1 Multi-Domain Network Topology
Figures 1 and 2 show example multi-domain network topologies. In Figures 1 and 2 show examples of multi-domain network topologies. In
Figure 1, domains are connected in a linear topology. There are Figure 1, domains are connected in a linear topology. There are
multiple paths between nodes A and L, but all of them cross domain#1- multiple paths between nodes A and L, but all of them cross domain#1-
domain#2-domain#3 in that order. domain#2-domain#3 in that order.
+--Domain#1--+ +--Domain#2--+ +--Domain#3--+ +--Domain#1--+ +--Domain#2--+ +--Domain#3--+
| | | | | | | | | | | |
| B------+---+---D-----E--+---+------J | | B------+---+---D-----E--+---+------J |
| / | | \ / | | \ | | / | | \ / | | \ |
| / | | \ / | | \ | | / | | \ / | | \ |
| A | | H | | L | | A | | H | | L |
skipping to change at page 8, line 35 skipping to change at page 8, line 35
- There is no assumption about the multi-domain network topology. For - There is no assumption about the multi-domain network topology. For
example, there could be more than two domain boundary nodes or example, there could be more than two domain boundary nodes or
inter-domain links (links connecting a pair of domain boundary inter-domain links (links connecting a pair of domain boundary
nodes belonging to different domains). nodes belonging to different domains).
- It is assumed that in a multi-domain topology, the sequence of - It is assumed that in a multi-domain topology, the sequence of
domains that the working LSP and the recovery LSP follow must be domains that the working LSP and the recovery LSP follow must be
the same and is pre-configured. the same and is pre-configured.
- Domain re-entry is not considered. - Domain re-entry is out of scope and is not considered further.
2.2 Note on Domain Diversity 2.2 Note on Domain Diversity
As described in Section 1.4, domain diversity means the selection of As described in Section 1.4, domain diversity means the selection of
paths that have only the ingress and egress domains in common. This paths that have only the ingress and egress domains in common. This
may provide enhanced resilience against failures, and is a way to may provide enhanced resilience against failures, and is a way to
ensure path diversity for most of the path of the LSP. ensure path diversity for most of the path of the LSP.
In Section 2.1 we assumed that the working LSP and the recovery LSP In Section 2.1 we assumed that the working LSP and the recovery LSP
follow the same set of domains in the same order. Under this follow the same set of domains in the same order. Under this
assumption, domain diversity cannot be achieved. However, by relaxing assumption, domain diversity cannot be achieved. However, by relaxing
this assumption, domain diversity could be achieved, e.g., by either this assumption, domain diversity could be achieved, e.g., by either
of the following schemes. of the following schemes.
- Consider domain diversity as a special case of SRLG diversity - Consider domain diversity as a special case of SRLG diversity
(i.e., assign an SRLG ID to each domain). (i.e., assign an SRLG ID to each domain).
- Configure domain level routing to provide domain diverse paths - Configure domain level routing to provide domain diverse paths
(e.g., by means of AS_PATH in BGP). (e.g., by means of AS_PATH in BGP).
Details of the operation of domain diversity are beyond the scope of Further details of the operation of domain diversity are beyond the
this document. scope of this document.
3. Factors to Consider 3. Factors to Consider
3.1 Scalability Versus Optimality 3.1 Scalability Versus Optimality
As described in [RFC4726], scalability and optimality are two As described in [RFC4726], scalability and optimality are two
conflicting objectives. Note that the meaning of optimality differs conflicting objectives. Note that the meaning of optimality differs
depending on each network operation. Some examples of optimality in depending on each network operation. Some examples of optimality in
the context of diverse LSPs are: the context of diverse LSPs are:
skipping to change at page 9, line 31 skipping to change at page 9, line 31
- Restricting the difference of their costs (for example, so as to - Restricting the difference of their costs (for example, so as to
minimize the delay difference after switch-over) while maintaining minimize the delay difference after switch-over) while maintaining
diversity. diversity.
By restricting TE information distribution to only within each domain By restricting TE information distribution to only within each domain
(and not across domain boundaries) as required by [RFC4105] and (and not across domain boundaries) as required by [RFC4105] and
[RFC4216], it may not be possible to compute an optimal path. As [RFC4216], it may not be possible to compute an optimal path. As
such, it might not be possible to compute diverse paths, even if they such, it might not be possible to compute diverse paths, even if they
exist. However, if we assume domain level routing is given (as exist. However, if we assume domain level routing is given (as
discussed in Section 2), it is possible to compute diverse paths discussed in Section 2), it would be possible to compute diverse
using specific computation schemes, if such paths exist. This is paths using specific computation schemes, if such paths exist. This
discussed in Section 4. is discussed further in Section 4.
3.2 Key Concepts 3.2 Key Concepts
Three key concepts to classify various diverse LSP computation and Three key concepts to classify various diverse LSP computation and
setup schemes are presented below. setup schemes are presented below.
o With or without confidentiality o With or without confidentiality
- Without confidentiality - Without confidentiality
skipping to change at page 17, line 41 skipping to change at page 17, line 41
5.3.1 Sequential Path Computation 5.3.1 Sequential Path Computation
In sequential path computation, we can assume that the working LSP In sequential path computation, we can assume that the working LSP
has its path computed and is set up using the normal per-domain has its path computed and is set up using the normal per-domain
technique as described in [RFC5152]. However, because of technique as described in [RFC5152]. However, because of
confidentiality issues, the full path of the working LSP is not confidentiality issues, the full path of the working LSP is not
returned in the signaling messages and is not available to the head- returned in the signaling messages and is not available to the head-
end LSR. end LSR.
To compute a disjoint path for the recovery LSP, each domain border To compute a disjoint path for the recovery LSP, each domain border
node needs to know the path of the working LSP within the domain that node needs to know the path of the working LSP within the domain to
it provides entry to. This is easy for the ingress LSR as it has which it provides entry. This is easy for the ingress LSR as it has
access to the RSVP-TE RRO within first domain. In subsequent domains, access to the RSVP-TE RRO within first domain. In subsequent domains,
the process requires that the path of the working LSP is somehow made the process requires that the path of the working LSP is somehow made
available to the domain border router as the recovery LSP is available to the domain border router as the recovery LSP is
signaled. Note that the working and recovery LSPs do not use the same signaled. Note that the working and recovery LSPs do not use the same
border routers if the LSPs are node or SRLG diverse. border routers if the LSPs are node or SRLG diverse.
There are several possible mechanisms to achieve this. There are several possible mechanisms to achieve this.
- Path keys could be used in the RRO for the working LSP. As the - Path keys could be used in the RRO for the working LSP. As the
signaling messages are propagated back towards the head-end LSR, signaling messages are propagated back towards the head-end LSR,
skipping to change at page 21, line 5 skipping to change at page 21, line 5
However, it is possible that nodes or links in different domains However, it is possible that nodes or links in different domains
belong to the same SRLG. That is, an SRLG may span domain boundaries. belong to the same SRLG. That is, an SRLG may span domain boundaries.
In such cases, in order to establish SRLG diverse LSPs, several In such cases, in order to establish SRLG diverse LSPs, several
considerations are needed: considerations are needed:
- Record of the SRLGs used by the working LSP. - Record of the SRLGs used by the working LSP.
- Indication of a set of SRLGs to exclude in the computation of the - Indication of a set of SRLGs to exclude in the computation of the
recovery LSP's path. recovery LSP's path.
In this case, there is tension between any requirement for domain In this case, there is a conflict between any requirement for domain
confidentiality and the requirement for SRLG diversity. One of them confidentiality, and the requirement for SRLG diversity. One of the
must be compromised. requirements must be compromised.
Furthermore, SRLG IDs may be assigned independently in each domain, Furthermore, SRLG IDs may be assigned independently in each domain,
and might not have global meaning. In such a scenario, some mapping and might not have global meaning. In such a scenario, some mapping
functions are necessary, similar to the mapping of other TE functions are necessary, similar to the mapping of other TE
parameters mentioned in Section 1.2. parameters mentioned in Section 1.2.
9. IANA Considerations 9. IANA Considerations
This informational document makes no requests for IANA action. This informational document makes no requests for IANA action.
skipping to change at page 21, line 31 skipping to change at page 21, line 31
document are RSVP-TE and PCEP. These protocols include policy and document are RSVP-TE and PCEP. These protocols include policy and
authentication capabilities as described in [RFC3209] and [PCEP]. authentication capabilities as described in [RFC3209] and [PCEP].
Furthermore, these protocols may be operated using more advanced Furthermore, these protocols may be operated using more advanced
security features such as IPsec [RFC4301] and TLS [RFC4346]. security features such as IPsec [RFC4301] and TLS [RFC4346].
Security may be regarded as particularly important in inter-domain Security may be regarded as particularly important in inter-domain
deployments and serious consideration should be given to applying deployments and serious consideration should be given to applying
the available security techniques as described in the documents the available security techniques as described in the documents
referenced above and as set out in [RFC4726]. referenced above and as set out in [RFC4726].
More discussion on security considerations in MPLG/GMPLS networks is Additional discussion of security considerations for MPLG/GMPLS
found in a specific document [SECURITY-FW]. networks can be found in [SECURITY-FW].
This document does not of itself require additional security measures This document does not of itself require additional security measures
and does not modify the trust model implicit in the protocols used. and does not modify the trust model implicit in the protocols used.
Note, however, that domain confidentiality (that is the Note, however, that domain confidentiality (that is the
confidentiality of the topology and path information from within any confidentiality of the topology and path information from within any
one domain) is an important consideration in this document, and a one domain) is an important consideration in this document, and a
significant number of the mechanisms described in this document are significant number of the mechanisms described in this document are
designed to preserve domain confidentiality. designed to preserve domain confidentiality.
11. References 11. References
11.1 Normative References 11.1 Normative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC 3209, December 2001. to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC4216] Zhang, R., and Vasseur, JP., "MPLS Inter-Autonomous [RFC4216] Zhang, R., and Vasseur, JP., "MPLS Inter-Autonomous
System (AS) Traffic Engineering (TE) Requirements", System (AS) Traffic Engineering (TE) Requirements",
RFC 4216, November 2005 RFC 4216, November 2005.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for (Protection and Restoration) Terminology for
Generalized Multi-Protocol Label Switching (GMPLS)", Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4427, March 2006. RFC 4427, March 2006.
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
Framework for Inter-Domain MPLS Traffic Framework for Inter-Domain MPLS Traffic
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, November 2006.
11.2 Informative References 11.2 Informative References
skipping to change at page 22, line 45 skipping to change at page 22, line 46
(GMPLS) User-Network Interface (UNI): Resource (GMPLS) User-Network Interface (UNI): Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE) ReserVation Protocol-Traffic Engineering (RSVP-TE)
Support for the Overlay Model", RFC 4208, October Support for the Overlay Model", RFC 4208, October
2005. 2005.
[RFC4301] Kent, S., Seo, K., "Security Architecture for the [RFC4301] Kent, S., Seo, K., "Security Architecture for the
Internet Protocol," December 2005. Internet Protocol," December 2005.
[RFC4346] Dierks, T., and Rescorla, E., "The Transport Layer [RFC4346] Dierks, T., and Rescorla, E., "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, Security (TLS) Protocol Version 1.1", RFC 4346,
April 2006.
[RFC4428] D. Papadimitriou, Ed., "Analysis of Generalized [RFC4428] D. Papadimitriou, Ed., "Analysis of Generalized
Multi-Protocol Label Switching (GMPLS)-based Multi-Protocol Label Switching (GMPLS)-based
Recovery Mechanisms (including Protection and Recovery Mechanisms (including Protection and
Restoration)", RFC 4428, March 2006. Restoration)", RFC 4428, March 2006.
[RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "Path [RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "Path
Computation Element (PCE) Architecture", RFC 4655, Computation Element (PCE) Architecture", RFC 4655,
August 2006. August 2006.
[RFC4802] Nadeau, T., and Farrel, A., "Generalized [RFC4802] Nadeau, T., and Farrel, A., "Generalized
 End of changes. 22 change blocks. 
41 lines changed or deleted 44 lines changed or added

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